LBISTArchitect™ Reference Manual

Software Version 2017.3

September 2017

© 1999-2017 Mentor Graphics Corporation

All rights reserved.

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

Note - Viewing PDF files within a web browser causes some links not to function (see MG595892).
Use HTML for full navigation
This document is for information and instruction purposes. Mentor Graphics 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 Mentor Graphics to determine whether any changes have been
made.

The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. 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 Mentor
Graphics whatsoever.

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

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

U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.

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

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.

Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: mentor.com
Support Center: support.mentor.com

Send Feedback on Documentation: support.mentor.com/doc_feedback_form

 Table of Contents

Chapter 1
What is In This Reference Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2
BIST-Ready Command Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Command Line Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Add Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Add Buffer Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Add Cell Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Add Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Add Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Add Mapping Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Add Multi_cycle Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Add Nofaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Add Nonscan Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Add Nonscan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Add Notest Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Add Output Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Add Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Add Pin Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Add Primary Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Add Primary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Add Read Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Add Scan Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Add Scan Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Add Scan Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Add Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Add Scan Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Add Sub Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Add Subchain Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Add Test Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Add Tied Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Add Write Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Analyze Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Analyze Input Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Analyze Output Observe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Analyze Testability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Archive Test_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Delete Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

LBISTArchitect Reference Manual, v2017.3 3

September 2017
 Table of Contents

Delete Buffer Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Delete Cell Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Delete Clock Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Delete Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Delete Mapping Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Delete MTPI Control_point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Delete MTPI Observe_point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Delete Nofaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Delete Nonscan Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Delete Nonscan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Delete Notest Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Delete Output Masks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Delete Pin Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Delete Pin Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Delete Primary Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Delete Primary Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Delete Read Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Delete Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Delete Scan Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Delete Scan Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Delete Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Delete Scan Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Delete Subchain Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Delete Test Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Delete Tied Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Delete Write Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Dofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Echo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Find Design Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Insert Test Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Load Static_timing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Printenv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Read Procfile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Report BIST Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Report Black Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Report Buffer Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Report Cell Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Report Circuit Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Report Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Report Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Report Configuration_data Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Report Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Report Dft Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Report Drc Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Report Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Report Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

4 LBISTArchitect Reference Manual, v2017.3

September 2017
Table of Contents

Report Feedback Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Report Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Report Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Report Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Report Mapping Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Report Nofaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Report Nonscan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Report Notest Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Report Output Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Report Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Report Pin Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Report Primary Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Report Primary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Report Read Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Report Scan Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Report Scan Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Report Scan Enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Report Scan Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Report Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Report Scan Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Report Sequential Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Report Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Report Subchain Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Report Test Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Report Test Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Report Testability Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Report Tied Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Report Timeplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Report Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Report Write Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Reset State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Restore Test_points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Ripup Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Save History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Set Bidi Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Set BIST Enables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Set Clock Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Set Dofile Abort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Set Drc Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Set File Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Set Gate Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Set Gate Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Set Gzip Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Set Identification Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Set Internal Fault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Set Io Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Set Latch Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Set Lockup Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

LBISTArchitect Reference Manual, v2017.3 5

September 2017
 Table of Contents

Set Logfile Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Set Loop Duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Set Net Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Set Nonscan Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Set Scan Enable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Set Scan_enable Sharing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Set Screen Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Set Sensitization Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Set System Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Set Test Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Set Tristate Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Setup Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Setup Output Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Setup Partition Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Setup Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Setup Registered IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Setup Scan Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Setup Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Setup Scan Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Setup Test_point Identification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Setup Test_point Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Setup Tied Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Setup Wrapper Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Setup X_bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Synthesize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Verify Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Write BIST Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Write Formal_verification Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Write Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Write Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Write Primary Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Write Primary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Write Procfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Write Scan Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Write Scan Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Write Scan Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Write Static_timing Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Write Subchain Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Chapter 3
BIST Controller Command Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Command Line Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Add Capture Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Add Cell Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Add Clock Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

6 LBISTArchitect Reference Manual, v2017.3

September 2017
Table of Contents

Add Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Add LFSR Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Add LFSR Taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Add LFSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Add Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Add Pll End_capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Add Pll Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Add Scan Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Add Set_reset Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Add Testprocedure Include. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Add Tristate Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Connect Iscan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Delete Capture Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Delete Cell Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Delete Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Delete LFSR Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Delete LFSR Taps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Delete LFSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Delete Pin Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Delete Pll End_capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Delete Pll Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Delete Scan Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Delete Set_reset Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Delete Testprocedure Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Delete Tristate Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Disconnect Iscan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Dofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Read Procfile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Report Capture Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Report Cell Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Report Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Report Configuration_data Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Report Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Report LFSR Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Report LFSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Report Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Report Pll End_capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Report Pll Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Report Primary Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Report Primary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Report Primitive Polynomials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Report Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Report Scan Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Report Set_reset Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Report Testprocedure Include. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Report Tristate Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

LBISTArchitect Reference Manual, v2017.3 7

September 2017
 Table of Contents

Reset State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Save BIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Save History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Save Sequential Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Set Bist Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Set BIST Enables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Set Capture Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Set Clock Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Set Clock Loading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Set Clock Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Set Core Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Set Dofile Abort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Set Dynamic X_bounding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Set Iscan Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Set Lbist Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Set Logfile Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Set Output Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Set Retiming Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Set RTL Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Set RTL Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Set Scan Enables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Set Scan_enable Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Set Shift_rate Divisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Set Testpoint Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Setup File Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Setup Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Setup Scan Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Setup Sdc Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Setup Synthesis Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500

Chapter 4
Fault Simulation Command Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Command Line Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Add Bist Capture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Add Chain Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Add Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Add Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Add LFSR Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Add LFSR Taps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Add LFSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
Add MTPI Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Add MTPI Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Add Nofaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Add Notest Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

8 LBISTArchitect Reference Manual, v2017.3

September 2017
Table of Contents

Add Output Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Add Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Add Pin Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Add Primary Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Add Primary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Add Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Add Scan Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Add Scan Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Add Tied Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Analyze Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Delete Bist Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
Delete Chain Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Delete Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Delete Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Delete LFSR Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Delete LFSR Taps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Delete LFSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Delete MTPI Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Delete MTPI Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Delete Nofaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
Delete Notest Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Delete Output Masks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Delete Pin Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Delete Pin Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Delete Primary Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
Delete Primary Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Delete Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Delete Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Delete Scan Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Delete Tied Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Dofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Find Design Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Flatten Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Identify Redundant Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Load Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Report Bist Capture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Report Chain Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Report Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Report Drc Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Report Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Report Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Report Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Report Feedback Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Report Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Report LFSR Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628

LBISTArchitect Reference Manual, v2017.3 9

September 2017
 Table of Contents

Report LFSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

Report Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Report MTPI Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Report Nofaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Report Notest Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
Report Output Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Report Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Report Pin Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
Report Primary Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Report Primary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Report Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Report Scan Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Report Scan Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Report Scan Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Report Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Report Tied Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Report Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Report Version Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Reset Di Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Save Flattened Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Save History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Save Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Set BIST Chain_test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Set BIST Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Set BIST Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Set Capture Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Set Contention Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Set Distributed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Set Dofile Abort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Set Drc Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Set Fault Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Set Fault Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Set File Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Set Gate Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Set Gate Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Set Gzip Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Set Internal Fault. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Set Logfile Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Set LFSR Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Set Number Shifts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Set Pattern Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Set Pattern Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Set Pattern Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Set Pattern Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
Set Possible Credit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Set Random Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Set Screen Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Set Split Capture_cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

10 LBISTArchitect Reference Manual, v2017.3

September 2017
Table of Contents

Set System Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721

Setup LFSRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Setup Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Setup Tied Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Update Implication Detections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Write Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

Chapter 5
Shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Shell Command Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Command Line Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
lbistarchitect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737

Appendix A
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Mentor Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
Index
Third-Party Information

End-User License Agreement

LBISTArchitect Reference Manual, v2017.3 11

September 2017
 List of Figures

List of Figures

Figure 2-1. LBISTArchitect-Generated faultsim dofile with -Top Option . . . . . . . . . . . . . . 70

Figure 2-2. LBISTArchitect-Generated ATPG Dofile with No -Top Option . . . . . . . . . . . . 71
Figure 2-3. Control Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 2-4. Observe Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 2-5. Control Point Example for -None . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Figure 2-6. Observe Point Example with -Existing_scan_cell . . . . . . . . . . . . . . . . . . . . . . . 324
Figure 2-7. Observe Point Example for -None and -Model. . . . . . . . . . . . . . . . . . . . . . . . . . 325
Figure 2-8. Observe Point Example with -New_scan_cell . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Figure 2-9. I/O Identification Default Tracing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Figure 2-10. All Input Logic Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Figure 2-11. Control and Observe Point Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Figure 3-1. PRPG Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Figure 3-2. MISR Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Figure 3-3. Example Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Figure 3-4. Five-bit PRPG with Tap Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Figure 3-5. Out Tap Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Figure 3-6. In Tap Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Figure 3-7. Interconnecting Internal Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Figure 3-8. Interconnecting into a Single Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Figure 3-9. Interconnecting Internal Bused Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Figure 3-10. Set Capture Waveform cap1 Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Figure 3-11. Set Capture Waveform cap2 Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Figure 3-12. Set Capture Waveform cap3 Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Figure 3-13. MTPI Phase Decoder Signal Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Figure 3-14. Example Schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Figure 3-15. Scan Enable Timing Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Figure 4-1. MISR placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Figure 4-2. How the -Instance Switch Determines Fault Counts . . . . . . . . . . . . . . . . . . . . . 651

12 LBISTArchitect Reference Manual, v2017.3

September 2017
List of Tables

List of Tables

Table 2-1. Conventions for BIST-Ready Command Line Syntax . . . . . . . . . . . . . . . . . . . . 17

Table 2-2. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 2-3. Report DRC Rules Available Information and Arguments . . . . . . . . . . . . . . . . . 183
Table 2-4. Fault Class Codes and Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Table 2-5. Name Conventions Used by Report Faults -Cell_name . . . . . . . . . . . . . . . . . . . 192
Table 2-6. Report Gate Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Table 2-7. Output Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Table 2-8. Latch Use for Different Polarity Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . 275
Table 2-9. Instance Type Prefix Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Table 2-10. Scan Insertion Invocation Default Pin Names . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Table 2-11. Insert Test Logic versus Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Table 3-1. Conventions for BIST Controller Command Line Syntax . . . . . . . . . . . . . . . . . 361
Table 3-2. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Table 4-1. Conventions for Fault Simulation Command Line Syntax . . . . . . . . . . . . . . . . . 501
Table 4-2. Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Table 4-3. Report DRC Rules Available Information and Arguments . . . . . . . . . . . . . . . . . 597
Table 4-4. Fault Class Codes and Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Table 4-5. Reportable Gate Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Table 4-6. Clock Port Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Table 4-7. Default Report Processors Information Display . . . . . . . . . . . . . . . . . . . . . . . . . 643
Table 4-8. Additional Data Displayed by -Verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Table 4-9. Supported -Noinitialization Output Pattern Formats . . . . . . . . . . . . . . . . . . . . . . 666
Table 4-10. Distributed Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Table 4-11. Name Conventions Used by Write Faults -Cell_name . . . . . . . . . . . . . . . . . . . 732
Table 5-1. Conventions for Command Line Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

LBISTArchitect Reference Manual, v2017.3 13

September 2017
 List of Tables

14 LBISTArchitect Reference Manual, v2017.3

September 2017
 Chapter 1
What is In This Reference Manual

This document provides a dictionary-style listing of LBISTArchitect commands and includes

the following sections:

• “BIST-Ready Command Dictionary”

• “BIST Controller Command Dictionary”
• “Fault Simulation Command Dictionary”
• “Shell Commands”

Tip: For a more comprehensive discussion of the strategy for using these commands, see
the LBISTArchitect Process Guide.

LBISTArchitect Reference Manual, v2017.3 15

September 2017
What is In This Reference Manual

16 LBISTArchitect Reference Manual, v2017.3

September 2017
 Chapter 2
BIST-Ready Command Dictionary

This section contains command descriptions for the BIST-Ready phase of LBISTArchitect.

Command Line Syntax Conventions

This manual uses the following command usage line syntax conventions.

Table 2-1. Conventions for BIST-Ready Command Line Syntax

Convention Example Usage
UPPercase REPort ENvironment Required command letters are in uppercase; in
(substitute product-specific most cases, you may omit lowercase letters when
examples throughout) 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 REad Controls {0 | 1} A boldface font indicates a required argument.
[ ] EXIt [-force] Square brackets enclose optional arguments. Do
not enter the brackets.
Italic DOFile filename An italic font indicates a user-supplied argument.
{ } ADD CEll Library library Braces enclose arguments to show grouping. Do
{{-Model name} | -All} not enter the braces.
| ADD CEll Library library The vertical bar indicates an either/or choice
{{-Model 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.
… ADD CLocks off_state An ellipsis follows an argument that may appear
primary_input_pin… more than once. Do not include the ellipsis when
[-Internal] entering commands.

LBISTArchitect Reference Manual, v2017.3 17

September 2017
BIST-Ready Command Dictionary
Command Summary

Command Summary
Table 2-2 contains a summary of the commands described in this manual.

Table 2-2. Command Summary

Command Description
Add Black Box Defines black boxes and sets the constrained value on output or
bidirectional black box pins.
Add Buffer Insertion Specifies for LBISTArchitect to place buffer cells between the
primary input of the specified test pin and the gates that it drives.
Add Cell Models Specifies the name of a DFT library cell that LBISTArchitect can
use with user-defined test points, system-generated test points,
and system-generated test logic.
Add Clock Groups Specifies the grouping of scan cells controlled by different clocks
onto one chain.
Add Clocks Specifies the names and inactive states of the primary input pins
that control the clocks in the design.
Add Mapping Definition Overrides the nonscan to scan model mapping defined by
LBISTArchitect.
Add Multi_cycle Path Specifies that the tool should add x-bounding logic to memory
elements that capture values from a multicycle path.
Add Nofaults Places nofault settings either on a pin or on all pins of a specified
instance or module.
Add Nonscan Instances Specifies for LBISTArchitect to ignore the specified instances,
all instances controlled by the specified control pin, or all
instances within the specified module, when identifying and
inserting the required scan elements and test logic.
Add Nonscan Models Instructs LBISTArchitect to ignore all instances of the specified
sequential DFT library model when identifying and inserting the
required scan elements and test logic into the design.
Add Notest Points Adds circuit points to list for exclusion from testability insertion.
Add Output Masks Instructs LBISTArchitect to mask, and optionally maintain a
constant logic level on, the specified primary output pins during
scan identification analysis.
Add Pin Constraints Specifies that LBISTArchitect hold the input pin at a constant
state during the rules checking and loop cutting processes.
Add Pin Equivalences Specifies to hold the specified primary input pins at a state either
equal to, or inverted in relationship to, the state of another
primary input pin during rules checking.

18 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Add Primary Inputs Adds a primary input to the net.
Add Primary Outputs Adds a primary output to the net.
Add Read Controls Adds an off-state value to specified RAM read control lines.
Add Scan Chains Specifies a name for a preexisting scan chain within the design.
Add Scan Groups Adds one scan chain group to the system.
Add Scan Instances Specifies that LBISTArchitect add the specified instance, all
instances controlled by the specified control pin, or all instances
within the specified module, to the scannable instance list.
Add Scan Models Specifies that LBISTArchitect is to flag every instance of the
named DFT library model for inclusion into the identified scan
list.
Add Scan Pins Declares the name of a scan chain at the top-level module and
assigns the corresponding scan input pin, scan output pin, and
optionally, the scan clock pin that you want to associate with that
chain.
Add Sub Chains Specifies the name of a preexisting scan chain that exists entirely
within a module, library model, or instance within a hierarchical
design.
Add Subchain Clocks Specifies the clock pins for a scan chain within a module, library
model, instance, blackbox, or empty module of a hierarchical
design.
Add Test Points Specifies explicitly where LBISTArchitect is to place a user-
defined test point to improve the design’s testability through
either improved controllability or improved observability.
Add Tied Signals Specifies for LBISTArchitect to hold the named floating objects
(nets or pins) at the given state value.
Add Write Controls Specifies the off-state value of the write control lines for RAMs.
Alias Specifies the shorthand name for a BIST-Ready command,
UNIX command, or existing command alias, or any combination
of the three.
Analyze Control Signals Identifies and optionally defines the primary inputs of control
signals.
Analyze Input Control Specifies for LBISTArchitect to calculate and display the effects
of constraining primary input pins to an unknown value on those
pins’ control capability.
Analyze Output Observe Specifies for LBISTArchitect to calculate and display the effects
on the observability of masked primary output pins.

LBISTArchitect Reference Manual, v2017.3 19

September 2017
BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Analyze Testability Reports general scannability and testability information, as well
as calculating the controllability and observability values for
gates.
Archive Test_points Saves the MTPI testpoint insertion information in an archive file.
Delete Black Box Undoes the effect of the Add Black Box command.
Delete Buffer Insertion Specifies the type of scan test pins on which you want to remove
the fanout limit.
Delete Cell Models Specifies the name of the DFT library cell that LBISTArchitect is
to remove from the active list of cells that the user can access
when adding test points or that LBISTArchitect can access when
inserting test logic.
Delete Clock Groups Specifies the name of the group that you want to remove from the
clock groups list.
Delete Clocks Removes primary input pins from the clock list.
Delete Mapping Returns the nonscan to scan model mapping to the default
Definition mapping defined by LBISTArchitect.
Delete MTPI Removes a specified MTPI control point from the current netlist.
Control_point
Delete MTPI Removes a specified MTPI observe point from the current netlist.
Observe_point
Delete Nofaults Removes the no-fault settings from either the specified pin or
instance pathnames.
Delete Nonscan Removes the specified sequential instances from the non-scan
Instances instance list.
Delete Nonscan Models Removes from the non-scan model list the specified sequential
DFT library models.
Delete Notest Points Removes the specified pins from the list of notest points which
the tool cannot use for testability insertion.
Delete Output Masks Removes the masking of the specified primary output pins.
Delete Pin Constraints Removes the pin constraints from the specified primary input
pins.
Delete Pin Equivalences Removes the pin equivalence specifications for the designated
primary input pins.
Delete Primary Inputs Removes the specified primary inputs from the current netlist.
Delete Primary Outputs Removes the specified primary outputs from the current netlist.

20 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Delete Read Controls Removes the read control line off-state definitions from the
specified primary input pins.
Delete Scan Chains Removes the specified scan chain definitions from the scan chain
list.
Delete Scan Groups Removes the specified scan chain group definitions from the scan
chain group list.
Delete Scan Instances Removes the specified, sequential instances from the user-
identified scan instance list.
Delete Scan Models Removes the specified sequential models from the scan model
list.
Delete Scan Pins Removes any previously-assigned scan input, output, and clock
names from the specified scan chains.
Delete Subchain Clocks Deletes a specified subchain clock.
Delete Test Points Remove the test point definitions at the specified locations.
Delete Tied Signals Removes the assigned (tied) value from the specified floating
nets or pins.
Delete Write Controls Removes the RAM write control line off-state definitions from
the specified primary input pins.
Dofile Executes the commands contained within the specified file.
Echo Issues a user-defined string to the transcript.
Exit Terminates the current BIST-Ready session.
Find Design Names Displays design object hierarchical names matched by an input
regular expression.
Help Displays the usage syntax and system mode for the specified
command.
History Displays a list of previously-executed commands.
Insert Test Logic Inserts the test structures that you define into the netlist to
increase the design’s testability.
Load Static_timing Reads in a specified path file that contains critical-path locations
Report for exclusion from MTPI test point insertion.
Printenv Prints out the values of the UNIX variables in the environment.
Read Procfile Reads the specified enhanced procedure file.
Report BIST Bounding Displays bounding settings and lists any excluded input pins.
Report Black Box Displays information on blackboxes and undefined models.

LBISTArchitect Reference Manual, v2017.3 21

September 2017
BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Report Buffer Insertion Displays a list of all the different scan test pins and the
corresponding fanout limit.
Report Cell Models Displays a list of either all cell models or the DFT library models
associated with the specified cell type.
Report Circuit Displays information about the components of the circuit as
Components either modules or instances.
Report Clock Groups Displays a list of all clock group definitions.
Report Clocks Displays a list of all clock definitions.
Report Displays a list of the commands that the tool executes upon
Configuration_data startup based on the available configuration data file for that
Commands design.
Report Control Signals Displays the rules checking results for the specified control
signals.
Report Dft Check Generates the scannability check results for non-scan instances.
Report Drc Rules Displays either a summary of DRC violations (fails) or violation
occurrence message(s).
Report Environment Displays the current values of all the “set” commands and the
default names of the scan type pins.
Report Faults Displays fault information from the current fault list.
Report Feedback Paths Displays a textual report of the currently identified feedback
paths.
Report Gates Displays the netlist information and simulation results for the
specified gates.
Report Instance Displays list of instances matched by instance expression.
Report Loops Displays information about circuit loops.
Report Mapping Reports the nonscan to scan model mapping defined in the
Definition design.
Report Nofaults Displays the no-fault settings for the specified pin or instance
pathnames.
Report Nonscan Models Displays the sequential non-scan model list.
Report Notest Points Displays all the circuit points removed from consideration by
LBISTArchitect as controllability and observability insertion
points.
Report Output Masks Displays a list of the currently masked primary output pins.
Report Pin Constraints Displays the pin constraints of the primary inputs.

22 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Report Pin Equivalences Displays the pin equivalences of the primary inputs.
Report Primary Inputs Displays the specified primary inputs.
Report Primary Outputs Displays the specified primary outputs.
Report Read Controls Displays all of the currently defined read control lines.
Report Scan Cells Displays a report or writes a file on the scan cells that reside in
the specified scan chains.
Report Scan Chains Displays a report on all the current scan chains.
Report Scan Enable Reports on the scan_enable signal for each scan_chain.
Report Scan Groups Displays a report on all the current scan chain groups.
Report Scan Models Displays the sequential scan models currently in the scan model
list.
Report Scan Pins Displays all previously assigned scan input, output, and clock
names.
Report Sequential Displays information and testability data for sequential instances.
Instances
Report Statistics Displays a detailed report of the design’s statistics.
Report Subchain Clocks Reports on subchain clocks defined for a specified subchain.
Report Test Logic Displays the test logic added during the scan insertion process.
Report Test Points Displays the test point specifications you created with Add Test
Points command and any test points that you enabled
LBISTArchitect to automatically identify.
Report Testability Displays the results of the Analyze Testability command.
Analysis
Report Tied Signals Displays a list of the tied floating signals and pins.
Report Timeplate Displays the specified timeplate.
Report Variables Displays user-defined variables and values.
Report Write Controls Displays the currently defined write control lines and their off-
states.
Reset State Removes all instances from both the scan identification and test
point identification lists identified during a run.
Restore Test_points Reads in the specified MTPI test points information text file.
Ripup Scan Chains Removes the specified scan chains from the design.
Run Runs the scan or test point identification process.

LBISTArchitect Reference Manual, v2017.3 23

September 2017
BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Save History Saves the command line history file to the specified file.
Set Bidi Gating Specifies how bidirectional (bidi) pins are controlled during scan
chain shifting to prevent potential bus contention or to ensure an
on/off state during testing.
Set BIST Enables Specifies the names of the enable signals controlling control
points, x-bounding multiplexers, and observe sink points.
Set Clock Period Specifies setup arguments related to the timing of clocks and
control signals, or removes all timing associated with that signal.
Set Dofile Abort Lets you specify that the tool complete processing of all
commands in a dofile regardless of an error detection.
Set Drc Handling Specifies how LBISTArchitect globally handles design rule
violations.
Set File Compression Controls whether the tools read and write files with .Z or .gz
extensions as compressed files (the default).
Set Gate Level Specifies the hierarchical level of gate reporting and displaying.
Set Gate Report Specifies the additional display information for the Report Gates
command.
Set Gzip Options Specifies GNU gzip options to use with the GNU gzip command.
Set Identification Model Specifies the simulation model that LBISTArchitect uses to
imitate the scan operation during the scan identification process.
Set Internal Fault Specifies whether the tool allows faults within or on the
boundary of library models.
Set Io Insertion Specifies whether to insert I/O buffers.
Set Latch Handling Specifies whether the tool considers non-transparent latches for
scan insertion while test logic is turned on.
Set Lockup Latch Specifies for LBISTArchitect to insert latches between different
clock domains to synchronize the clocks within a scan chain.
Set Logfile Handling Specifies for LBISTArchitect to direct the transcript information
to a file.
Set Loop Duplication Specifies whether to include duplicate gates in feedback paths
which are generated during the circuit flattening process.
Set Net Resolution Specifies the behavior of multi-driver nets.
Set Nonscan Handling Specifies whether to check the nonscan instances for
scannability.
Set Scan Enable Assigns scan_enable signals to specific scan chains.

24 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Set Scan_enable Sharing Divides all scan chains into specified groups and assigns a unique
scan_ enable signal to each group.
Set Screen Display Specifies whether LBISTArchitect writes the transcript to the
session window.
Set Sensitization Specifies whether DRC checking attempts to verify a suspected
Checking C3 rules violation.
Set System Mode Specifies the next system mode for the tool to enter.
Set Test Logic Specifies which types of control lines LBISTArchitect makes
controllable during the DFT rules checking.
Set Tristate Gating Specifies how tri-state devices are controlled during scan chain
shifting.
Setup Naming Explicitly defines the default names for nets and instances, and
reports current or modified settings.
Setup Output Masks Sets the default mask for all output and bidirectional pins.
Setup Partition Scan Specifies a partition scan run.
Setup Pin Constraints Sets the default pin constraint value for all input pins.
Setup Registered IO Registers the primary inputs and outputs of a core design.
Setup Scan Identification Specifies whether or not to use the full scan identification
methodology during the LBISTArchitect identification run.
Setup Scan Insertion Sets up the parameters for the Insert Test Logic command.
Setup Scan Pins Changes the scan-in or scan-out pin naming parameters to index
or bus format.
Setup Test_point Specifies the number of control and observe test points that
Identification LBISTArchitect flags during the identification run.
Setup Test_point Specifies how LBISTArchitect configures the inputs for the
Insertion control test points and the outputs for the observe test points.
Setup Tied Signals Changes the default value for floating pins and floating nets that
do not have assigned values.
Setup Wrapper Chains Specifies wrapper chains for scan insertion
Setup X_bounding Defines the X bounding parameters.
Synthesize Inserts test structures into the netlist to increase the design’s
testability.
System Passes the specified command to the operating system for
execution.

LBISTArchitect Reference Manual, v2017.3 25

September 2017
BIST-Ready Command Dictionary
Command Summary

Table 2-2. Command Summary

Command Description
Verify Scan Verifies that newly inserted scan can pass DRC.
Write BIST Setup Writes the top-level design interface and dofile used in the BIST
Controller phase of LBISTArchitect.
Write Writes a constraints driver file for the formal verification tool,
Formal_verification FormalPro.
Setup
Write Loops Writes a list of all loops to the specified file.
Write Netlist Writes the current design in the specified netlist format to the
specified file.
Write Primary Inputs Writes primary inputs to the specified file.
Write Primary Outputs Writes primary outputs to the specified file.
Write Procfile Writes existing procedure and timing data to the named enhanced
procedure file.
Write Scan Identification Writes a list of the scan instances which LBISTArchitect has
identified or you have defined as scan cells.
Write Scan Order Creates specified DEF file.
Write Scan Setup Writes the test procedure file and the dofile for inserted scan
chains to the specified files.
Write Static_timing Writes a constraints file for use with static timing analysis tools.
Setup
Write Subchain Setup Writes the appropriate Add Sub Chains commands to a file so
that LBISTArchitect can understand the preexisting scan sub-
chains at the top-level of this module.

26 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Command Descriptions

Command Descriptions
The following section provides an alphabetical list and descriptions of the commands available
for your use for the BIST-Ready flow of LBISTArchitect.

Tip: Use the line continuation character, “\\”, when the application commands extend
beyond the end of a line.

LBISTArchitect Reference Manual, v2017.3 27

September 2017
BIST-Ready Command Dictionary
Add Black Box

Add Black Box

Scope: Setup mode
Usage
ADD BLack Box {{{-Instance ins_pathname | -Module module_name} [0 | 1 | X | Z]} [-Pin
pinname {0 | 1 | X | Z}]…} | {-Auto [0 | 1 | X | Z]} [-FAUlt_boundary |
-NOFAUlt_boundary | -NO_Boundary]
Description
Defines black boxes and sets the constrained value on output or bidirectional black box pins.
The Verilog netlist parser will not automatically blackbox any instantiated module or
component that is not defined in either the ATPG library or the design netlist, but they will issue
a warning that such an instance was detected. The -Auto switch for this command allows you to
indicate to the tool that all detected, undefined models should be blackboxed. If you do not issue
the Add Black Box -Auto command, and undefined models exist, LBISTArchitect issues an
error message suggesting you automatically blackbox these models.
Use Add Black Box with the -Auto switch to automatically blackbox all instances of models the
tool considers undefined. By default, instances the tool automatically blackboxes drive Xs on
their outputs. Faults that propagate to the black box inputs are classified at ATPG_untestable
(AU). You can use the Add Black Box command to change the output values.
Issuing two Add Black Box commands, where one is module-based and the other is instance-
based, lets you globally blackbox all instances of a particular module while selectively
blackboxing a particular instance of the same module with slightly different values.
Arguments
• -Instance ins_pathname
A switch and string pair that specifies for the tool to blackbox the instance at the full
pathname, ins_pathname. Instance-based blackboxing always overrides module-based
blackboxing.
• -Module module_name
A switch and string pair that specifies for the tool to blackbox every instantiation of the
module, module_name.
• -Auto
A switch that specifies that all models detected without a module or instance name will be
made black box models with default output values.
• 0|1|X|Z
An optional literal that specifies pin tie values. When used with the -Instance or -Module
switches, it specifies the tie value for any pin not explicitly defined. When used with -Auto,
it specifies the tie value for every pin. If you specify no value for this option, then the
application defaults to the Setup Tied Signals command’s value.

28 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Black Box

• -Pin pinname {0 | 1 | X | Z}
An optional, repeatable switch, string, and literal triplet that specifies the tie value of a
particular pin on the black box. Valid values are 0, 1, X, and Z. You must specify a value.
Unspecified pins assume the default tie value.
• -FAUlt_boundary
A switch that specifies to keep pin pathnames at the boundaries of all blackboxed instances
and allow boundary pins to become fault sites. This is the default behavior.
• -NOFAUlt_boundary
A switch that specifies to keep pin pathnames at the boundaries of all blackboxed instances,
but not allow boundary pins to become fault sites.
Note
You must include this switch when you use the Add Black Box command to blackbox
macros for Tessent FastScan MacroTest.

• -NO_Boundary
A switch that specifies to not keep pin pathnames at the boundaries of all blackboxed
instances and to not allow boundary pins to become fault sites.
Example
The following example creates a blackbox for module core with tie value of 0, then core1.
add black box -module core 0
add black box -instance core1 -pin pin1 1

The following example creates a black box for all undefined models.

add black box -auto

The following example keeps the pin pathnames at the boundary of all instances of the
blackboxed module named “macro1”, but nofaults the pins.

add black box -module macro1 -nofault_boundary

Related Commands
Add Tied Signals Report Black Box
Delete Black Box

LBISTArchitect Reference Manual, v2017.3 29

September 2017
BIST-Ready Command Dictionary
Add Buffer Insertion

Add Buffer Insertion

Scope: All modes
Usage
ADD BUffer Insertion max_fanout test_pin… [-Model modelname]
Description
Specifies for LBISTArchitect to place buffer cells between the primary input of the specified
test pin and the gates that it drives.
When LBISTArchitect inserts the scan circuitry into the design, the scan-related pins (enables
and clocks) can fan out to drive multiple gates. When a pin has a large fanout, the pin’s
increased load factor affects the quality of the pin’s output signal.
If you want to avoid signal degradation of a primary input scan pin, you can use the Add Buffer
Insertion command. This sets the fanout limit on all buffers used to buffer the specified signal.
The fanout limit propagates down the buffer tree the tool inserts.
Arguments
• max_fanout
A required integer that specifies the maximum number of gates the test_pin can drive before
LBISTArchitect inserts buffers. The value must be greater than 1. By default, the tool
assumes the test_pin can drive an infinite number of gates. This value overrides the default
value set by the Add Cell Models command.
• test_pin
A required, repeatable literal that specifies the type of the primary input scan pin on which
you want to monitor the maximum fanout. The following lists the default pin names for each
type of scan pin. You can use the Setup Scan Insertion command to change the default
names of the scan pins.
SEN (scan enable; default name scan_en) — A literal that specifies the primary input
pin that enables the scan chain.
SCLK (scan clock; default name scan_clk) — A literal that specifies the primary input
pin that clocks the scan data through the scan chain, which the clocked scan type uses.
TEN (test logic enable; default name test_en) — A literal that specifies the primary
input pin that enables the operation of the test logic circuitry.
TCLK (test logic clock; default name test_clk) — A literal that specifies the primary
input pin that clocks the values LBISTArchitect requires for proper functionality of
the test logic.
SMCLK (master scan clock; default name scan_mclk) — A literal that specifies the
primary input pin that clocks the scan data into the master scan elements of the scan
chain when using the LSSD scan type.

30 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Buffer Insertion

SSCLK (slave scan clock; default name scan_sclk) — A literal that specifies the
primary input pin that clocks the scan data into the slave scan elements of the scan
chain when using the LSSD scan type.
SET (scan set; default name scan_set) — A literal that specifies the scan set for the new
scan cells.
RESET (scan reset; default name scan_reset) — A literal that specifies the scan reset for
the new scan cells.
• -Model modelname
An optional switch and string pair that specifies the name of a buffer in the library that
LBISTArchitect inserts when the scan pin reaches the maximum fanout. You must first
identify the buffer with either the Add Cell Models command or with the cell_type library
attribute. If you do not use the -Model switch, by default, the tool uses the first buffer model
in the buffer cell model list (which you can obtain with the Report Cell Models command).
Examples
The following mux-DFF example explicitly specifies the buffer model to use and sets the
maximum fanout for the scan enable pin itself.
You must first define the buf1a buffer model in the library using the cell_type library attribute
with the value of “BUF”. The first command explicitly adds the buf2a cell to the buffer model
list and defines its fanout to be 10. Next, the report shows the two buffers currently in the buffer
model list. The last command specifies the maximum fanout of the scan enable pin and all
buffers inserted to buffer the scan enable signal.
This example uses the -Model switch to specify the buf2a model. Without this switch, the tool
would use the buf1a model, because it is the first in the buffer model list.
add cell models buf2a -type buf -max_fanout 10
report cell models
BUF : buf1a<infinity> buf2a<10>
add buffer insertion 5 sen -model buf2a

Related Commands
Add Cell Models Report Buffer Insertion
Delete Buffer Insertion Setup Scan Insertion

LBISTArchitect Reference Manual, v2017.3 31

September 2017
BIST-Ready Command Dictionary
Add Cell Models

Add Cell Models

Scope: All modes
Usage
ADD CEll Models dftlib_model {-Type {INV | And | {Buf -Max_fanout integer} | OR | NAnd
| NOr | Xor | INBuf | OUtbuf | {Mux selector data0 data1} | {Scancell clk data} | {DFf clk
data} | {DLat enable data [-Active {High | Low}]}} [{-Noinvert | -Invert} output_pin]
Description
Specifies the name of a DFT library cell that LBISTArchitect can use with user-defined test
points, system-generated test points, and system-generated test logic.
Test logic is combinational circuitry that LBISTArchitect can add in front of sequential
elements, memory elements, or enable lines of tri-state drivers to ensure controllability of those
elements.
If you enable test logic functionality with the Set Test Logic command, you need to specify the
names of the DFT library cells that the tool is to use. If you do not specify the corresponding
DFT library cells, then, when you issue the Insert Test Logic command, LBISTArchitect does
not know which cells to insert for the test logic. In this case, it displays an error message for
each cell that does not have a corresponding DFT library cell.
If you add multiple cells of the same type with the Add Cell Models command, the tool uses the
first added cell. You may want to add multiple cells of the same type if you are manually adding
test points with the Add Test Points command, because you can use different models of the
same type at different test point locations.
If you are unsure of whether a particular design requires test logic, you can force
LBISTArchitect to report the names of elements that require test logic. To use the reporting
functionality, you enable the test logic functionality in Setup mode with the Set Test Logic
command, enter Dft mode, and then issue the Report Dft Check command. This command lists
the LBISTArchitect-identified pins that require test logic for controllability. If you decide the
design requires the addition of test logic, you can then issue the Add Cell Models command.
Arguments
• dftlib_model
A required string that specifies the name of a cell model in the DFT library that
LBISTArchitect uses for test logic, buffer tree, lockup latch, or test point insertion.
• -Type INV | And | {Buf -Max_fanout integer} | OR | NAnd | NOr | Xor | INBuf | OUtbuf
| {Mux selector data0 data1} | {Scancell clk data} | {DFf clk data} | {DLat enable data
[-Active {High | Low}]}
A required switch and argument pair, with an optional switch and literal pair, that specifies
the cell model type for the named dftlib_model. The cell model type choices are as follows:
INV — A literal that specifies a one-input inverter gate.
And — A literal that specifies a two-input AND gate.

32 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Cell Models

Buf -Max_fanout integer — A literal with a switch and integer pair that specifies a one-
input buffer gate with an optional buffer fanout limit.
OR — A literal that specifies a two-input OR gate.
NAnd — A literal that specifies a two-input NAND gate.
NOr — A literal that specifies a two-input NOR gate.
Xor — A literal that specifies an exclusive OR gate.
INBuf — A literal that specifies a primary input buffer gate that LBISTArchitect inserts
whenever the tool adds new input pins (such as the scan input or scan enable pins). It
places the buffer between the primary input and the new pin.
OUtbuf — A literal that specifies a primary output buffer gate that LBISTArchitect
inserts whenever the tool adds new output pins (such as the scan output pin). It places
the buffer between the new pin and the primary output.
Mux selector data0 data1 — A literal and three strings that specify a 2-1 multiplexer, as
well as the names of the selector pin and both data pins.
Scancell clk data — A literal and two strings that specify a mux-scan cell with four
input pins (clock, data, scan in, and scan enable), clocked scan cell with four inputs
(clock, data, scan clock, and scan enable), or LSSD scan cell with five inputs (clock,
data, scan in, master clock, and slave clock). You must specify the name of the clock
and data pins of the DFT library cell model.
DFf clk data — A literal and two strings that specify a D flip-flop with two input pins
(clock and data). You must specify the names of the clock and data pins of the DFT
library cell model.
DLat enable data [-Active {High | Low}] — A literal and two strings that specify a D
latch with two input pins (enable and data). You must specify the names of the enable
line and the data pin of the DFT library cell model. You can also include the optional
-Active switch if you are defining this model for use with lockup latches:
-Active {High | Low} — An optional switch and literal pair that specifies whether
the enable input is active high or active low. The information from this option is
used by the Set Lockup Latch command. The default is active high.
• {-Noinvert | -Invert} output_pin
An optional switch and string pair that you can use with values of the cell_model that are
sequential elements. This switch specifies whether the output_pin has an inversion
relationship with the data input of the given sequential element. By default, LBISTArchitect
assumes no inversion relationship between the output_pin and the data input. If you do not
explicitly specify an inversion switch, by default, LBISTArchitect uses the first output_pin
value it identifies on a DFF, ScanCell, or DLAT model.
Examples
The following example shows a typical use of test logic, which involves the set, reset, and clock
pins on sequential elements (flip-flops). LBISTArchitect can usually ensure controllability of
sequential elements with model types of And, Or, and Mux.

LBISTArchitect Reference Manual, v2017.3 33

September 2017
BIST-Ready Command Dictionary
Add Cell Models

add clocks 0 clk

set test logic -set on -reset on -clock on
set system mode dft -force
report dft check
…
add cell models and2 -type and
add cell models or2 -type or
add cell models mux21h -type mux si a b

The following mux-DFF example adds the buf2a cell to the buffer model list, explicitly
specifies the buffer model to use, and sets the maximum fanout for the scan enable:
add cell models buf2a -type buff
report cell models
BUF : buf1a buf2a

add buffer insertion 5 sen -model buf2a

Related Commands
Add Buffer Insertion Set Io Insertion
Add Test Points Set Lockup Latch
Delete Cell Models Set Test Logic
Report Cell Models Setup Scan Identification

34 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Clock Groups

Add Clock Groups

Scope: Dft mode
Prerequisites: You must first define all the clocks with the Add Clocks command.
Usage
ADD CLock Groups group_name clk_pin… [-Tclk]
Description
Specifies the grouping of scan cells controlled by different clocks onto one chain.
If you are going to merge scan cells controlled by multiple shift clocks into one scan chain, you
can use the Add Clock Groups command to place the scan cells together that share the same
shift clock.
LBISTArchitect groups scan cells controlled by the same clock in the chain. If you want to
insert lockup latches between the different clock domains of the groups, you can use the Set
Lockup Latch command. These latches synchronize the pulses to all the clock inputs of the scan
cells within the same scan chain.
As you define clock groups, the clocks in these groups are removed from the default clock
group, all_clocks. Every clock is contained in either a user-defined clock group or the default
clock group.
Caution
Do not use the Add Clock Groups command to define clocks as a single clock domain;
clock equivalencies created with this command are problematic. Instead, you should use
the Add Pin Equivalences command.

The Add Clock Groups command controls which scan cells are merged into the same
scan chain, but the clocks are not considered equivalent from a timing perspective. As a
result, LBISTArchitect does not consider all clocks within a clock group to be equivalent
when identifying the target location for a new scan cell created during X-bounding or
MTPI.

Arguments
• group_name
A required string that specifies the name you want to assign to the list of clock pins that you
provide with the clk_pin argument.
• clk_pin
A required, repeatable string that specifies the names of all the clocks that control the cells
that you want to group together.

LBISTArchitect Reference Manual, v2017.3 35

September 2017
BIST-Ready Command Dictionary
Add Clock Groups

• -Tclk
An optional switch that specifies to include the test clock in the clock group. Because
LBISTArchitect adds the clock signal during test structure insertion, you cannot specify the
actual clock name here.
Examples
The following example lists the clocks in the current clock list, splits those clocks into two
different groups, and defines the latch LBISTArchitect will use to synchronize the different
clocks. It also enables automatic lockup latch insertion and then performs the scan and latch
placement.
add clock 1 clk1 clk2
add clock 0 clk3 clk4 clk5 clk6
set system mode dft
…
add clock groups group1 clk1 clk3 clk4
add clock groups group2 clk2 clk5 clk6
add cell models dlat1a -type dlat enable data
add cell models inv -type inv
set lockup latch on
run
synthesize

Note
This example causes LBISTArchitect to create two scan chains because there are two
clock groups.

Related Commands
Add Cell Models Report Clock Groups
Add Clocks Set Lockup Latch
Add Pin Equivalences Synthesize
Delete Clock Groups

36 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Clocks

Add Clocks
Scope: Setup mode
Usage
ADD CLocks off_state primary_input_pin… … [-internal] [-pin_name user_pinname]
[-top_name existing_pin [-inverted]]
Description
Specifies the names and inactive states of the primary input pins that control the clocks in the
design.
You must declare all control signals (such as clocks, sets, and resets) and their corresponding
off-states with the Add Clocks command before entering the Dft mode. Otherwise, instances
that the design rules checker cannot completely control do not pass the scannability check. If an
instance does not pass the scannability check, LBISTArchitect does not recognize it as a
scannable instance, and cannot replace it with the corresponding scan cell.
As you declare clocks, they are inserted into a default clock group, all_clocks. Deleted clocks
are removed from all_clocks.
Arguments
• off_state
A required literal that specifies the pin value that cannot affect the output pin activity of the
instance. For example, the off-state of an active low reset pin is 1 (high). For an edge-
triggered control signal, the off–state is the value on the pin that results in the clock inputs
being placed at the initial value of a capturing transition.
The off-state choices are as follows:
0 — A literal specifying that the off-state value is 0.
1 — A literal specifying that the off-state value is 1.
• primary_input_pin
A required repeatable string that lists the primary input pins that you want controlling the
output pins of an instance. The list of primary input pins must all have the same off_state.
If you declare a control pin with the Add Clocks command, LBISTArchitect also
automatically declares all pins that are equal to that pin as control pins, by looking at the
arguments of any Add Pin Equivalences commands. If the -Internal switch is used,
primary_input_pin lists internal pin pathnames. If both the -Internal and -Pin_name
switches are used, primary_input_pin lists internal pin pathnames to merge into a single,
new primary input pin.
• -Internal
An optional switch that specifies primary_input_pin is an internal pin that, for DRC analysis
only, should be disconnected from its original driver and treated as if it were a clock primary
input. If you use this switch, the primary_input_pin argument must be an internal pin, not an

LBISTArchitect Reference Manual, v2017.3 37

September 2017
BIST-Ready Command Dictionary
Add Clocks

actual clock primary input pin. When writing out the modified netlist, this internal clock
input is not added to the top level interface. Use this switch to define internal clock inputs
normally driven by on-chip circuitry.
• -PIn_name user_pinname
An optional switch and string pair that specifies the name of a new pseudo primary input
pin that drives all of the internal pins specified with the primary_input_pin argument. The
user_pinname is a name (wildcards are not allowed) given to the newly-created primary
input pin.
The -Pin_name switch is only valid when the -Internal switch is also specified. The
-Pin_name switch is also allowed if the primary_input_pin argument specifies a single,
internal pin pathname which ensures that a known pin name is used for the new primary
input pin.
• -top_name existing_pin
An optional switch and string pair that specifies the name of an existing top level pin that
drives the internal node during scan chain shifting. The top level pin should be a clock
signal; you do not need to define it using the Add Clocks command. Note: Although the
top_name switch is optional, DFTAdvisor issues a warning message if it cannot
automatically trace from the internal node to a primary input pin (the pin must not be a scan
signal, and must not have any pin constraints).
• -inverted
An optional switch that must be used in conjunction with the -top_name switch to indicate
an inverting path; this may be necessary if the signals cannot be traced due to a black-boxed
module.
Example 1
The following example first lists the primary inputs of the design, which, in this case, is simply
a D flip-flop. The next two commands declare the preset, clear, and clock pins to be clocks,
which means they have the ability to control the states on the output pins of that instance.
report primary inputs
SYSTEM: /CLK_INPUT
SYSTEM: /D_INPUT
SYSTEM: /PRE_INPUT
SYSTEM: /CLR_INPUT

add clock 1 /pre_input /clr_input

add clock 0 /clk_input

Example 2
The following example defines the output of a PLL block as an internal clock and explicitly
specifies the top level signal that can be used to generate a clock pulse at the internal node. The
Write Atpg Setup command will refer to the top level signal instead of the internal net.

add clock 0 /pll_block/clock1 -internal -top_name /clock_trigger

38 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Clocks

Related Commands
Add Clock Groups Delete Clocks
Analyze Control Signals Report Clocks

LBISTArchitect Reference Manual, v2017.3 39

September 2017
BIST-Ready Command Dictionary
Add Mapping Definition

Add Mapping Definition

Scope: Setup and Dft modes
Prerequisites
You can only override the mapping for scan models of the same scan type. For example, a mux-
DFF scan model can only be replaced by another mux-DFF scan model.
Usage
ADD MApping Definition object_name [-Instance | -Module]
[-Nonscan_model nonscan_model_name] [-Scan_model scan_model_name]
[-Output scan_ouput_pin_name]
Description
Overrides the nonscan to scan model mapping defined by LBISTArchitect.
The Add Mapping Definition command defines the mapping of nonscan models to scan models.
You can change the scan model for an individual instance, all instances under a hierarchical
instance, all instances in all occurrences of a module in the design, or all occurrences of the
model in the entire design. Additionally, you can change the scan output pin of the scan model
in the same manner.
Note
The intent of this command is to change the existing nonscan to scan model mapping, as
defined in the library, and not to define the mapping.

For additional information on scan cell and scan output mapping, refer to “Scan Cell and Scan
Output Mapping” in the Scan and ATPG User’s Manual.
Arguments
• object_name
A required string that specifies the name of the nonscan model you want to map to a
different scan model. You can also specify an instance, hierarchical instance, module, or
scan model.
o If this argument is the name of an instance or hierarchical instance, the -Instance
switch is required and the model must be specified with the -Nonscan_model switch
or -Scan_model switch.
o If this argument is the name of a module, then the -Module switch is required and the
model must be specified with the -Nonscan_model or -Scan_model switch.
o If this argument is a scan model, then the -Output switch is required. Because you
specified a scan model, you can only define the scan output pin mapping.

40 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Mapping Definition

• -Instance | -Module
An optional switch that specifies the type of the object_name argument. If neither switch is
specified, the object_name is a model (the default).
o If you specify -Instance and the instance is primitive, then only the named instance
has its mapping changed.
o If you specify -Instance and the instance is hierarchical, then all instances under that
instance matching the -Nonscan_model or (for output mapping) matching the -
Scan_model have their mapping changed.
o If you specify -Module, then for all occurrences of that module, all instances within
that module that match the -Nonscan_model or (for output mapping) matching the -
Scan_model have their mapping changed.
• -Nonscan_model nonscan_model_name
A switch and string pair that specifies the name of the nonscan model for which you want to
change the mapping. This argument is only required if you specify the -Instance or -Module
switch. Otherwise, specify the nonscan model in the object_name argument.
• -Scan_model scan_model_name
A switch and string pair that specifies the name of the scan model that you want to use for
the specified nonscan model. This argument is required except when you are only changing
the mapping of the scan output pin and you specify the scan model in the object_name
argument.
• -Output scan_ouput_pin_name
An optional switch and string pair that specifies the name of the scan output pin to use
instead of the LBISTArchitect-defined scan output pin. You must have already declared the
port as a scan-out port in the scan_definition section of the scan cell.
Examples
The following example maps the fd1 nonscan model to the fd1s scan model for all occurrences
of the model in the design:
add mapping definition fd1 -scan_model fd1s

The following example maps the fd1 nonscan model to the fd1s scan model and changes the
scan output pin to “qn” for all occurrences of the model in the design:
add mapping definition fd1 -scan_model fd1s -output qn

The first command in the following example maps the fd1 nonscan model to the fd1s scan
model for all matching instances in the “counter” module and for all occurrences of that module
in the design. The second command maps the fd1 nonscan model to the fd1s2 scan model and
changes the scan output pin to “qn” for all matching instances under the hierarchical instance
“/top/counter1”. Note that counter1 is an instance of the module counter changed in the first
command.

LBISTArchitect Reference Manual, v2017.3 41

September 2017
BIST-Ready Command Dictionary
Add Mapping Definition

add mapping definition counter -module -nonscan_model fd1 -scan_model fd1s

add mapping definition /top/counter1 -instance -nonscan_model fd1 -scan_model fd1s2
-output qn

The following example changes the scan output pin to “qn” for all occurrences of the fd1s scan
model in the design:
add mapping definition fd1s -output qn

Related Commands
Delete Mapping Definition Report Mapping Definition

42 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Multi_cycle Path

Add Multi_cycle Path

Scope: All modes
Usage
ADD MUlti_cycle Path enable_name {pin_name…}
Description
Specifies that the tool should add x-bounding logic to memory elements that capture values
from a multicycle path.
A design that contains multicycle paths is defined as having combinational logic paths between
memory elements that require more than one system clock cycle to acquire the new value.
The issue is that the registers that capture the values from multicycle paths capture unknown
values during Logic BIST testing. To resolve this issue the tool can add x-bounding logic to all
memory elements that capture values from a multicycle path.
This x-bounding logic consists of OR gates that lets the tool capture a known value (of ‘1’) from
the multicycle path. These x-bounding gates are controlled by a dynamic signal that is derived
from the pattern counter. Once this mechanism is in place, the tool can create a special capture
window that generates two clock pulses with the appropriate time separation to allow the
multicycle path to stabilize before capture. The tool disables the x-bounding gates only when
this capture window is applied.
When dealing with circuits that contain multicycle paths, you also need to issue the Set
Dynamic X_bounding command during the BIST-Controller generation phase of the tool,
which enables x-bounding by driving the enable signal(s) (enable_name) high during the
specified capture window and low during all other capture windows.
Arguments
• enable_name
A required string that specifies a new signal that will be dynamically driven by the BIST
controller.
• pin_name
A required string that must be the name of an internal net that is connected to the data input
of a flip-flop.
Related Commands
Add Capture Window Set Capture Waveform
Delete Capture Window Set Dynamic X_bounding
Report Capture Window

LBISTArchitect Reference Manual, v2017.3 43

September 2017
BIST-Ready Command Dictionary
Add Nofaults

Add Nofaults
Scope: Setup mode
Usage
ADD NOfaults {{{modulename -Module} | {object_expression… [-PIN | -Instance]}}
[-Stuck_at {01 | 0 | 1}] [-Keep_boundary]} [-VERbose] [{> | >>} file_pathname]
Description
Places nofault settings either on a pin or on all pins of a specified instance or module.
The Add Nofaults command places a no-fault setting on either a single specified pin or on all
pins of a specified instance or module. If the pathname is a pin, then LBISTArchitect ignores
only the fault on that pin. If the pathname is an instance, then the tool ignores all pin faults on
the top-level of that instance, along with all the pin faults underneath that instance (if it is a
hierarchical instance). If the pathname is a module, then the tool ignores all pin faults on the
top-level of the module, along with all the pin faults on all instances and pins underneath that
module for every occurrence of that module in the design. The nofaults that you create with the
Add Nofaults command only exist for the current LBISTArchitect session.
LBISTArchitect recognizes the no-fault setting on pins and instances through two different
tagging processes. The first process involves interactively using the Add Nofaults command
(which you can use on pins and instances); the second process involves using the no-fault DFT
library attribute (which you can only use on pins, not on instances).
Arguments
• modulename
A repeatable string that specifies the name of a module to which you want to assign nofault
settings. You must include the -Module switch when you specify a module name.
• -Module
A switch that specifies to interpret the modulename argument as a module pathname. All
instances of the module are affected. You can use the asterisk (*) and question mark (?)
wildcards for the modulename argument, and the tool adds the nofault for all matching
modules or library models.
• object_expression
A string representing a list of pathnames of instances or pins for which you want to assign
nofault settings. The string may include any number of embedded asterisk (*) or question
mark (?) wildcard characters. The asterisk matches any sequence of characters (including
none) in a name, and the question mark matches any single character.
Pin pathnames must be ATPG library cell instance pins, also referred to as design level pins.
If the object expression specifies a pin within an instance of an ATPG library model, the
tool ignores it. By default, pin pathnames are matched first. If a pin pathname match is not
found, the tool next tries to match instance pathnames. You can force the tool to match only

44 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Nofaults

pin pathnames or only instance pathnames by including the -Pin or -Instance switch after the
object_expression.
• -PIN
An optional switch that specifies to use the preceding object expression to match only pin
pathnames; the tool will then assign nofault settings to all the pins matched.
• -Instance
An optional switch that specifies to use the preceding object expression to match only
instance pathnames; the tool will then assign nofault settings to all boundary and internal
pins of the instances matched (unless you use the -Keep_boundary switch).
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies to which stuck-at values you want to assign
a nofault setting. The choices for stuck-at values are as follows:
01 — A literal that specifies the placement of a nofault setting on both the “stuck-at-0”
and “stuck-at-1” faults. This is the default.
0 — A literal that specifies the placement of a nofault setting on the “stuck-at-0” faults.
1 — A literal that specifies the placement of a nofault setting on the “stuck-at-1” faults.
• -Keep_boundary
An optional switch that specifies that nofaults are applied to the pins inside of the specified
instance or module, but faults are still allowed at the boundary pins of the specified
instances or modules. This option does not apply to nofaults on pin pathnames.
• -VERbose
By default when you specify wildcard characters for instance (-INstance) or pin (-PIN)
names, the tool outputs a summary message similar to the following:
// Note: Adding faults for 330 fault sites.

When you specify the optional -VERbose switch, then the tool outputs the instance or pin
names instead of the summary. You can optionally redirect this output to a file using the >
or >> redirection operators.
If you use actual instance or pin names instead of wildcards, then this switch has no effect.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.

LBISTArchitect Reference Manual, v2017.3 45

September 2017
BIST-Ready Command Dictionary
Add Nofaults

Examples
The following example first tags all the pin faults on and below an instance. The example then
tags the fault on a specific pin.
add clocks 0 clock
add nofaults i_1006 -instance
add nofaults i_1_16/df0/q
set system mode dft
run

Related Commands
Delete Nofaults Report Nofaults

46 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Nonscan Instances

Add Nonscan Instances

Scope: All modes, except only Dft mode for the -Control_signal option.
Usage
ADD NONscan Instances pathname… [-INStance | -Control_signal | -Module]
Description
Specifies for LBISTArchitect to ignore the specified instances, all instances controlled by the
specified control pin, or all instances within the specified module, when identifying and
inserting the required scan elements and test logic.
The Add Nonscan Instances command causes LBISTArchitect to ignore the specified instances,
instances controlled by the specified control signals, or all instances within the specified module
when you execute both the scan identification process with the Run command and the scan
insertion process with the Insert Test Logic command.
Also, LBISTArchitect will not perform the scannability rule checks on nonscan instances unless
you execute the Set Nonscan Handling command.
If you want to flag all instances of a certain library model as nonscan, you can use the Add
Nonscan Models command as a short cut.
When adding nonscan instances with control signals, LBISTArchitect adds all scannable
instances controlled by the control signals to the nonscan instance list. Control pins can be any
clock, set, or reset signal (primary input) that controls the contents of sequential instances. You
can use the Report Control Signals command to see the pins that control the sequential instances
in the design.
If TIE0 and TIE1 nonscan cells are scannable, they are considered for scan. However, if these
cells are used to hold off sets and resets of other cells so that another cell can be scannable, you
must use this command to make them nonscan.
Arguments
• pathname
A required, repeatable string that specifies the pathnames of the sequential instance or
control signals (that control instances) which you want LBISTArchitect to ignore. If the
instance is hierarchical, then all instances beneath it are also flagged as nonscan.
• -INStance | -Control_signal | -Module
A switch that specifies whether the pathnames are instances, pins (control signals), or
modules. An example Verilog module is “module clkgen (clk, clk_out, …)” where clkgen is
the module name. You can only use the -Control_signal option in Dft mode. The default is
instances.

LBISTArchitect Reference Manual, v2017.3 47

September 2017
BIST-Ready Command Dictionary
Add Nonscan Instances

Examples
The following example specifies that LBISTArchitect ignore the sequential i_1006 instance
when identifying and inserting the required scan circuitry:
add nonscan instances i_1006

Related Commands
Delete Nonscan Instances Report Sequential Instances
Insert Test Logic Run
Report Instance Set Nonscan Handling

48 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Nonscan Models

Add Nonscan Models

Scope: All modes
Usage
ADD NONscan Models model_name…
Description
Instructs LBISTArchitect to ignore all instances of the specified sequential DFT library model
when identifying and inserting the required scan elements and test logic into the design.
The Add Nonscan Models command causes LBISTArchitect to ignore the instances of the
specified models, when you execute both the scan identification process with the Run
command, and the scan insertion process with the Insert Test Logic command.
Also, LBISTArchitect will not check the scannability on the instances instantiated from the
added nonscan models, unless you specify checking using the Set Nonscan Handling command.
If you want to flag individual instances as nonscan, you can use the Add Nonscan Instances
command.
Arguments
• model_name
A required, repeatable string that specifies the model names that you want LBISTArchitect
to ignore. You must enter the model names as they appear in the DFT library.
Examples
The following example specifies that LBISTArchitect should not substitute any of the instances
of the DFT library model named d_flip_flop with the equivalent scan replacement DFT library
model.
add nonscan models d_flip_flop

Related Commands
Delete Nonscan Models Run
Insert Test Logic Report Nonscan Models
Set Nonscan Handling

LBISTArchitect Reference Manual, v2017.3 49

September 2017
BIST-Ready Command Dictionary
Add Notest Points

Add Notest Points

Scope: Setup and Dft modes
Usage
ADD NOtest Points [-Control_only | -OBserve_only] {pin_pathname… |
{instance_pathname… [-Observe_scan_cell]}} | -Path filename
Description
Adds circuit points to list for exclusion from testability insertion.
The Add Notest Points command excludes the specified cell output pins, specified D input scan
cells, all output pins on the specified instance, or specified critical delay paths, from use as
controllability and observability insertion points. If the selected pin is already a control or
observe point, an error occurs when you issue this command.
If you specify a path file that contains critical delay paths, each gate contained in a path is
marked so that no test point can be added to the output of that gate. This prevents control and
observation points from being added to a critical path and thus prevents increasing the load on
any of these gates in that path. The format of the file is the same as the file loaded into Tessent
FastScan™ with the Load Paths command. For more information on the format, refer to “The
Path Definition File” in the Scan and ATPG User’s Manual.
You can use the Report Notest Points command to display all the pins in this list or list the
defined critical paths.
Arguments
• -Control_only | -OBserve_only
An optional switch that specifies points in the design where test points (control points and
observe points) cannot be inserted. By default, neither observe nor control points can be
inserted at a notest point.
-Control_only — A literal that specifies that control points are forbidden in the specified
location. Observe points are allowed.
-OBserve_only — A literal that specifies that observe points are forbidden in the
specified location. Control points are allowed.
• pin_pathname
A repeatable string that lists the output pins that you do not want LBISTArchitect to use for
controllability and observability insertion.
• instance_pathname [-Observe_scan_cell]
A repeatable string and optional switch that lists the instances whose output pins you do not
want to use for controllability and observability insertion. All output pins within that
(hierarchical) instance are added to the list of pins that are excluded from consideration.
-Observe_scan_cell — An optional switch that excludes the instance named in the
instance_pathname argument for use as an observation scan cell.

50 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Notest Points

• -Path filename
A switch and filename pair that specifies the pathname to a file that contains critical path
information. For more information on the format of the file, refer to “The Path Definition
File” in the Scan and ATPG User’s Manual.
Examples
The following example first sets up the test point identification parameters, then specifies
output pins tr_io and ts_i that LBISTArchitect cannot use for testability insertion:
setup test_point identification -control 9 -obs 20 -patterns 32000
setup test_point insertion -cshare 16 -oshare 16
set system mode dft
setup scan identification none
add notest points tr_io ts_i
run

Related Commands
Delete Notest Points Setup Test_point Insertion
Report Notest Points

LBISTArchitect Reference Manual, v2017.3 51

September 2017
BIST-Ready Command Dictionary
Add Output Masks

Add Output Masks

Scope: Setup mode
Usage
ADD OUtput Masks {primary_output… | -All} [-Nohold | -Hold {0 | 1}]
Description
Instructs LBISTArchitect to mask, and optionally maintain a constant logic level on, the
specified primary output pins during scan identification analysis.
LBISTArchitect uses primary output pins as the observe points during the scan identification
process. When you mask a primary output pin, you inform LBISTArchitect to mark that pin as
an invalid observation point during the identification process.
You can set a default mask for all output and bidirectional pins using the Setup Output Masks
command. You can add a hold value to a default mask with the Add Output Masks command, or
remove a hold value using the Delete Output Masks command. To turn off the default masks for
all output pins, you must use the Setup Output Masks command with the Off literal.
Arguments
• primary_output
A repeatable string that specifies the names of the primary output pins you want to mask.
When you enter the primary_output argument without the -Hold switch, LBISTArchitect
marks the specified pins as invalid observation points during the identification process.
If you specify the -Hold switch, then, in addition to masking the specified pins,
LBISTArchitect also applies and maintains the specified (-Hold) state value on the pins.
• -All
A switch that specifies to mask all primary output pins.
• -Nohold
An optional switch specifying that you want LBISTArchitect to allow any state value on the
primary output pin. This is the default.
• -Hold 0 | 1
An optional switch and literal pair that specifies the particular state that you want
LBISTArchitect to maintain on the primary output pin. If you use this switch, you can
explicitly specify that the output pin is driving the inactive value.

52 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Output Masks

The choices for the hold literal value are as follows:

0 — A literal that specifies to maintain a low logic state on the primary output pin.
1 — A literal that specifies to maintain a high logic state on the primary output pin.
Examples
The following example first sets up LBISTArchitect to recognize only the partition cells during
the scan identification run. The invocation default identification type is sequential scan. Next,
the example specifies the primary output pins that the Add Output Masks command associates
with the partition scan cells.
setup scan identification partition_scan
add output masks out1 out2 out3

When you issue the Run command later in the session, LBISTArchitect identifies all the
sequential elements that are observable only through the primary output pin that you masked.
Then, when you issue the Insert Test Logic command, LBISTArchitect stitches all those scan
cells it previously identified as being in the partition into one partition scan chain.

Related Commands
Analyze Output Observe Setup Output Masks
Delete Output Masks Setup Scan Identification
Report Output Masks

LBISTArchitect Reference Manual, v2017.3 53

September 2017
BIST-Ready Command Dictionary
Add Pin Constraints

Add Pin Constraints

Scope: Setup mode
Usage
ADD PIn Constraints primary_input_pin {C0 | C1 | CZ | CX | CR0 | CR1}
[-SYnthesize | {-SImulate {ATPG | BIST | ALL}}]
Description
Specifies that LBISTArchitect hold the input pin at a constant state during the rules checking
and loop cutting processes.
LBISTArchitect performs the rules checking and loop cutting processes when you issue the Set
System Mode Dft command. During the rules checking process there are times that you want to
hold a pin at a constant state. For example, you may want to hold a test enable pin at the active
state to keep the chip in test mode.
Note
This command has effects on other commands that relate to fault simulation; this includes
multiphase test point selection, along with BIST pattern simulation (in BIST mode).

You can set a default pin constraint value for all input pins using the Setup Pin Constraints
command. The pin constraints set by the Setup Pin Constraints command can be overridden by
the values set with the Add Pin Constraints command. You can remove an override of a default
pin constraint using the Delete Pin Constraints command. To remove the default pin constraint
for all input pins, you should use the Setup Pin Constraints command with the None literal.
Arguments
• primary_input
A required string that specifies the primary input pin that you want LBISTArchitect to hold
at the constant_value.
• C0 | C1 | CZ | CX | CR0 | CR1
A literal that specifies the application of the constant value with which you want to constrain
the primary_input pin. The constraint choices are as follows:
C0 — A literal that specifies application of the constant 0 to the chosen primary input
pins.
C1 — A literal that specifies application of the constant 1 to the chosen primary input
pins.
CZ — A literal that specifies application of the constant Z (high-impedance) to the
chosen primary input pins.
CX — A literal that specifies application of the constant X (unknown) to the chosen
primary input pins.

54 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Pin Constraints

CR0 — A literal that specifies a constant that returns to 0; LBISTArchitect uses this
constant only when formatting the patterns. BIST simulation treats CR0 as a C0.
CR1 — A literal that specifies a constant that returns to 1; LBISTArchitect uses this
constant only when formatting the patterns. BIST simulation treats CR1 as a C1.
• -SYnthesize
An optional switch that specifies for LBISTArchitect to synthesize the pin constraints in the
hardware. That is, LBISTArchitect creates extra gates on the input paths that are controlled
by lbist_enable as shown here:
Core

a a_internal
b b_internal
lbist_enable

The CZ and CX constant values can not be used with the -Synthesize switch. The tool adds
the necessary hardware when you issue the Insert Test Logic command.
• -SImulate {ATPG | BIST | ALL}
An optional switch that specifies for LBISTArchitect to constrain the pins through the test
environment (such as the test bench and test vectors). These signals must be driven with the
appropriate values any time a logic BIST test is active. If you use -Simulate, a tester is
required to apply these pin constraints. So, the test may not be usable at the board/system
level.
The ALL literal is the default when you specify (or by default use) the -Simulate switch.
The ATPG literal specifies for the tool to constrain the pins in the ATPG topup pattern
generation (but not during BIST), the BIST literal specifies for the tool to constrain the pins
in the BIST simulation (but not during ATPG), and the ALL literal specifies for the tool to
constrain the pins in both ATPG and BIST.
Examples
The following example illustrates how to hold two primary input pins to constant values:
add pin constraints kgmt c1
add pin constraints dsint c0

Related Commands
Analyze Input Control Report Pin Constraints
Delete Pin Constraints Setup Pin Constraints

LBISTArchitect Reference Manual, v2017.3 55

September 2017
BIST-Ready Command Dictionary
Add Pin Equivalences

Add Pin Equivalences

Scope: Setup mode
Usage
ADD PIn Equivalences primary_input_pin… [-Invert] primary_input_pin_ref
Description
Specifies to hold the specified primary input pins at a state either equal to, or inverted in
relationship to, the state of another primary input pin during rules checking.
Rules checking occurs with the Set System Mode Dft command. During these rule checks, there
are times when a pin needs to be held at the same (or opposite) state in reference to another pin.
Note
This command has effects on other commands that relate to fault simulation; this includes
simulation-based and multiphase test points selection.

Arguments
• primary_input_pin
A required, repeatable string that specifies a list of primary input pins whose values you
want to either equal or invert with respect to primary_input_pin_ref.
• -Invert
An optional switch that specifies for LBISTArchitect to hold the primary_input_pin value to
the opposite state of the primary_input_pin_ref value. If you use this switch, you must enter
it immediately prior to the primary_input_pin_ref value.
• primary_input_pin_ref
A required string that specifies the name of the primary input pin whose value you want
LBISTArchitect to use when determining the state value of primary_input_pin. You can
immediately precede this string with the -Invert switch to cause LBISTArchitect to hold the
primary_input_pin value to the opposite state of the primary_input_pin_ref value.
Examples
The following example restricts the first primary input (indata2) to have an inverted value with
respect to the second primary input (indata4):
add pin equivalences indata2 -Invert indata4

Related Commands
Delete Pin Equivalences Report Pin Equivalences

56 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Primary Inputs

Add Primary Inputs

Scope: Setup mode
Usage
ADD PRimary Inputs net_pathname… [-Cut] [-Module]
Description
Adds a primary input to the net.
The Add Primary Inputs command adds an additional primary input to each specified net path.
Once added, the tool designates them as user class primary inputs, as opposed to the primary
inputs described in the original netlist, which it designates as system class primary inputs. Use
the -Cut option to disconnect the original drivers of the net, so that the added primary input
becomes the only driver of the net. Otherwise, if there are other drivers besides the newly added
primary input, the tool treats this net as a wired net. You can display the user class, system class,
or full classes of primary inputs using the Report Primary Inputs command.
Arguments
• net_pathname
A required, repeatable string that specifies the pathname of the pins to which you want to
add primary inputs.
• -Cut
An optional switch that specifies disconnection of the original drivers of the net, making the
added primary input the only driver of the net. The design must be flattened with the Flatten
Model command prior to using this option.
• -Module
An optional switch that specifies addition of the primary input to the specified nets in all
modules. Only one primary input is added to the design for that net when many occurrences
of that net occurs in the modules.
Examples
The following example adds two new primary inputs to the circuit and places it in the user class
of primary inputs:
add primary inputs indata2 indata4

Related Commands
Delete Primary Inputs Report Primary Inputs

LBISTArchitect Reference Manual, v2017.3 57

September 2017
BIST-Ready Command Dictionary
Add Primary Outputs

Add Primary Outputs

Scope: Setup mode
Usage
ADD PRimary Outputs net_pathname…
Description
Adds a primary output to the net.
The Add Primary Outputs command adds an additional primary output to each specified net.
Once added, the tool defines them as user class primary outputs. The tool defines the primary
outputs described in the original netlist as system class primary outputs. You can display the
user class, system class, or full classes of primary outputs using the Report Primary Outputs
command.
Arguments
• net_pathname
A required, repeatable string that specifies the nets to which you want to add primary
outputs.
Examples
The following example adds a new primary output to the circuit and places it in the user class of
primary outputs:
add primary outputs outdata1

Related Commands
Delete Primary Outputs Report Primary Outputs

58 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Read Controls

Add Read Controls

Scope: Setup mode
Usage
ADD REad Controls {0 | 1} primary_input_pin…
Description
Adds an off-state value to specified RAM read control lines.
The Add Read Controls command defines the circuit read control lines and assigns their off-
state values. The off-state value of the pins that you specify must be sufficient to keep the RAM
outputs stable. You cannot use clocks, constrained pins, or equivalent pins as read control lines.
Arguments
• 0
A literal that specifies 0 as the off-state value for the RAM read control lines.
• 1
A literal that specifies 1 as the off-state value for the RAM read control lines.
• primary_input_pin
A required, repeatable string that lists the primary input pins you want to designate as RAM
read control lines, and to which you are assigning the given off-state value.
Examples
The following example assigns an off-state value of 0 to two read control lines, r1 and r2:
add clocks 0 clk
add read controls 0 r1 r2
set system mode dft
run

Related Commands
Analyze Control Signals Report Read Controls
Delete Read Controls

LBISTArchitect Reference Manual, v2017.3 59

September 2017
BIST-Ready Command Dictionary
Add Scan Chains

Add Scan Chains

Scope: Setup mode
Prerequisites
Prior to using this command, you must define the scan chain group with the Add Scan Groups
command. If multiple scan chains are in the same scan group, you must load the chains in
parallel.
Usage
ADD SCan Chains chain_name group_name primary_input_pin primary_output_pin
Description
Specifies a name for a preexisting scan chain within the design.
The Add Scan Chains command defines a scan chain that exists in the design. A scan chain
references the name of a scan chain group, which you must define prior to issuing this
command.
A preexisting scan chain is a serially connected set of scan cells, that have been stitched
together in a previous scan insertion operation, or that you created manually. In order for
LBISTArchitect to be able to correctly insert scan elements in the remainder of the design or to
run rules checking on existing scan circuitry, you need to notify LBISTArchitect of this
circuitry, so it can treat those elements in the chain differently than the elements in the rest of
the design.
When you use this command to notify LBISTArchitect of a preexisting scan chain,
LBISTArchitect removes the scan cells in the scan chain from the eligible scan elements list.
Because the tool removes the scan cells in the scan chain from the scan candidate list, the rules
checker does not perform the usual scannability checks on those scan cells. However, the rules
checker does perform additional rules checking based on the declaration of preexisting scan
elements that pertain to the checking of the validity and the operation of that scan chain.
If the design does have a preexisting scan chain that you declare with the Add Scan Chains
command, you need to provide information on the operation of that scan chain in a test
procedure file.
Arguments
• chain_name
A required string that specifies the name of the preexisting scan chain you want added to the
scan group.
• group_name
A required string that specifies the name of the scan chain group to which you are adding the
scan chain.

60 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Scan Chains

• primary_input_pin
A required string that specifies the primary input pin of the scan chain.
• primary_output_pin
A required string that specifies the primary output pin of the scan chain.
Examples
The following example defines two scan chains (chain1 and chain2) that belong to the same
scan group (group1):
add scan groups group1 scanfile
add scan chains chain1 group1 indata2 testout2
add scan chains chain2 group1 indata4 testout4

Related Commands
Add Scan Groups Report Scan Chains
Delete Scan Chains Ripup Scan Chains

LBISTArchitect Reference Manual, v2017.3 61

September 2017
BIST-Ready Command Dictionary
Add Scan Groups

Add Scan Groups

Scope: Setup mode
Usage
ADD SCan Groups group_name test_procedure_filename
Description
Adds one scan chain group to the system.
The Add Scan Groups command has two different uses. The main use of this command is to
specify a group name for a set of preexisting scan chains within the design. You can add only
one scan chain group within a LBISTArchitect session. Additionally, use this command to
provide necessary initialization values to non-scan memory elements.
If the design has preexisting scan chains, those scan chains must belong to a scan group. The
Add Scan Group command also specifies the corresponding test procedure file for that scan
group. A sequence of procedures in the test procedure file defines the operation of the scan
chains within a scan group. The scan group must have a corresponding test procedure file.
If the design does not have preexisting scan chains, but you need to initialize some non-scan
memory elements specifically for scannability checking, you can specify “dummy” as the
group_name along with a test_procedure_filename. Then, within the test procedure file, you
can use the optional test_setup procedure to initialize the non-scan memory elements. As a
result, LBISTArchitect will model the non-scan memory elements as a TIE1 or TIE0.
Note
You must also define these same elements as non-scan using the Add Nonscan Instance
command.

Arguments
• group_name
A required string that specifies the name of the scan chain group that you want to add to the
system.
• test_procedure_filename
A required string that specifies the name of the test procedure file that contains the
information for controlling the scan chains in the specified scan chain group.
Examples
The following example defines a scan chain group, group1, which loads and unloads a set of
scan chains, chain1 and chain2, by using the procedures in the file, scanfile:
add scan groups group1 scanfile
add scan chains chain1 group1 indata2 testout2
add scan chains chain2 group1 indata4 testout4

62 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Scan Groups

Related Commands
Add Scan Chains Read Procfile
Delete Scan Groups Write Procfile
Report Scan Groups

LBISTArchitect Reference Manual, v2017.3 63

September 2017
BIST-Ready Command Dictionary
Add Scan Instances

Add Scan Instances

Scope: All modes
Usage
ADD SCan Instances pathname… [-INStance | -Control_signal | -Module]
[-INPut | -Output | {-Hold {0 | 1}}]
Description
Specifies that LBISTArchitect add the specified instance, all instances controlled by the
specified control pin, or all instances within the specified module, to the scannable instance list.
If LBISTArchitect is only inserting partial scan during the BIST-Ready phase, the Add Scan
Instances command allows a way of ensuring that LBISTArchitect includes specific sequential
instances in the scan list. LBISTArchitect generates the scan list during the scan identification
process (which you execute with the Run command in the Dft mode). However, if the instance
you specify does not pass the rules checking process, LBISTArchitect cannot include it in the
identified scan list.
If you do not issue the Add Scan Instances command with partial scan, LBISTArchitect chooses
the sequential instances it includes in the identified scan list based on the settings you specified
with the Setup Scan Identification command (or uses the default argument values for that
command).
If BIST-Ready phase is in the Dft mode, the Add Scan Instances command can accept
scannable instance pathnames, control signal pins, or module names as arguments. Scannable
instances are those sequential instances that passed all the scannability checks run by the Design
Rule Checker when you entered the Dft mode.
When adding scan instances with control signals, LBISTArchitect adds all scannable instances
controlled by the control signals to the identified scannable instance list. Control pins can be
any clock, set, or reset signal (primary input or output) that controls the contents of sequential
instances. You can use the Report Control Signals command to see the pins that control the
sequential instances in the design.
Arguments
• pathname
A required, repeatable string that specifies the pathnames of the sequential instances or
control signals (that control instances) which you want to add to the scan instance list. If the
instance is hierarchical, then the tool also adds all sequential instances beneath it to the scan
list.
• -INStance | -Control_signal | -Module
A switch that specifies whether the pathnames are instances, pins (control signals), or
modules. An example Verilog module is “module clkgen (clk, clk_out, …)” where clkgen is
the module name. You can only use the -Control_signal option in Dft mode. The default is
-Instance.

64 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Scan Instances

• -INPut | -Output | {-Hold {0 | 1}}

An optional switch that the scan instances are added as input or output partition scan cells. If
you specify the -Hold option, then you must also supply a high (1) or low (0) literal to define
hold 0 or hold 1 output partition scan cells. If none of these options are specified, the added
scan instances are considered as regular scan cells.
Examples
The following example first specifies two sequential instances that the user wants to ensure are
in the identified scan list (assuming they pass rules checking). In the remainder of the example,
you enter Dft mode, specify that LBISTArchitect is to choose the 50 percent of the eligible scan
elements that maximizes the fault coverage, and then run the scan identification process.
add scan instances i_1006 i_1007
set system mode dft
setup scan identification full_scan
run

Because of the previous setup in this example, when LBISTArchitect runs the scan
identification process it chooses the optimal 50 percent of eligible scan instances, but always
includes i_1006 and i_1007 within that fifty percent.
Related Commands
Delete Scan Instances Report Sequential Instances
Report Instance Setup Scan Identification

LBISTArchitect Reference Manual, v2017.3 65

September 2017
BIST-Ready Command Dictionary
Add Scan Models

Add Scan Models

Scope: All modes
Usage
ADD SCan Models model_name…
Description
Specifies that LBISTArchitect is to flag every instance of the named DFT library model for
inclusion into the identified scan list.
If you are only inserting partial scan during the BIST-Ready phase, the Add Scan Models
command allows a way of ensuring that LBISTArchitect includes all instances of a specific
sequential DFT library model in the scan list. LBISTArchitect generates the scan list during the
scan identification process (which you initiate with the Run command in the Dft mode).
LBISTArchitect then replaces all instances in the scan list with the equivalent DFT library scan
model during scan synthesis (which you initiate with the Insert Test Logic command within the
Dft mode).
If you do not issue the Add Scan Models command with partial scan, LBISTArchitect chooses
the sequential instances it includes in the scan list based on the settings you specified with the
Setup Scan Identification command (or uses the default argument values for that command).
If the BIST-Ready phase is in the Dft mode, the Add Scan Models command only flags the
scannable instances of the specified library model for inclusion into the scan list. Scannable
instances are those sequential instances that passed all the scannability checks run by the Design
Rule Checker when you entered the Dft mode. So, if there are instances of the specified library
model that were not put into the eligible scan list because they failed some of the design rules
checks, LBISTArchitect would not include those instances in the identified scan list.
The Add Scan Models command flags all instances of the specified sequential DFT library
model, where the Add Scan Instances Command only individually flags sequential design
instance(s).
Arguments
• model_name
A required, repeatable string that specifies the model names that you want to add to the scan
model list. Enter the model names as they appear in the DFT library.
Examples
The following example flags all instances of the specified DFT library model for inclusion into
the scan list.
add scan models dff1a
set system mode dft
setup scan identification full_scan
run

66 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Scan Models

Related Commands
Delete Scan Models Report Scan Models

LBISTArchitect Reference Manual, v2017.3 67

September 2017
BIST-Ready Command Dictionary
Add Scan Pins

Add Scan Pins

Scope: All modes
Usage
ADD SCan PIns chain_name scan_input_pin scan_output_pin [-CLock pin_name] [-CUt]
[-Registered] [-Top primary_input_pin primary_out_pin]
Description
Declares the name of a scan chain at the top-level module and assigns the corresponding scan
input pin, scan output pin, and optionally, the scan clock pin that you want to associate with that
chain.
If you specify signal names for the scan input or scan output pins that do not currently reside in
the design, LBISTArchitect generates a warning, and then adds the appropriate pins when you
perform the scan synthesis process with the Insert Test Logic command.
If you need to explicitly define the scan input and scan output primary pins at the top-level of
the design, but also need to specify internal pin pathnames for the scan_input_pin and
scan_output_pin arguments, you must use the -Top option to create the faultsim dofile correctly
when executing the Write Atpg Setup command.
If you do not issue either this command, or the Setup Scan Pins command, LBISTArchitect uses
the default names when generating the scan chain. The default name of the scan chain is chain1,
with the corresponding scan input pin named scan_in1, and the corresponding scan output pin
named scan_out1. If LBISTArchitect inserts multiple scan chains, the default naming
increments the suffix number of each argument by one for each chain (such as chain2, scan_in2,
and scan_out2).
You can optionally use the Setup Scan pins command to globally set the default naming
conventions for scan chains that do not use existing design pins. The Add Scan Pins command
only specifies the naming for a specific scan chain.
Arguments
• chain_name
A required string that specifies the name of the scan chain with which you want
LBISTArchitect to associate the scan_input_pin and scan_output_pin names.
• scan_input_pin
A required string that specifies the scan input pin name of the scan chain. This pin can be a
top-level input pin, top-level bidirectional pin, or an internal signal.
In addition to a primary input pin name (for instance, scan_in), you can also specify an
internal instance pin pathname (for example, /I116/d) as the scan_input_pin value. If you do
so, that pin pathname must be an output pin of an instance. If the specified internal instance
pin cannot be traced back to a primary input pin through a simple path (only inverters or/and
buffers), when the Write Atpg Setup command is issued, a warning message is written to the

68 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Scan Pins

top of the ATPG dofile and the following command is added in front of the Add Scan
Chains command referencing the internal scan_input_pin argument:
add primary input -cut “scan_input_pin”

If the pin is a top-level bidirectional pin, LBISTArchitect assumes that you configured the
pin to be in input mode during the scan test and does not check for correct configuration.
If you specify -Registered, the scan_input_pin is the output of the DFF head register.
• scan_output_pin
A required string that specifies the scan output pin name of the scan chain. This pin can be a
top-level output pin, top-level bidirectional pin (single driver), or an internal signal. If the
scan-out pin you specify is driven by multiple instances, LBISTArchitect adds a mux gate to
multiplex the original functional driver with the driver from the last scan cell of the scan
chain.
Note
If the scan output pin you specify has a functional connection, DFTAdvisor multiplexes
this connection with the connection line from the last scan cell of the scan chain.

In addition to a primary output pin name (such as scan_out), you can also specify an internal
instance pin pathname (such as /I116/q) as the scan_output_pin value. If you do so, that pin
pathname must be an input pin of an instance.
If the specified internal instance pin cannot be traced forward to a primary input pin through
a simple path (only inverters or/and buffers), when the Write Atpg Setup command is
issued, a warning message is written to the top of the ATPG dofile and the following
command is added in front of the Add Scan Chains command referencing the internal
scan_output_pin argument:
add primary output “scan_output_pin”

If the pin is a top-level bidirectional pin, LBISTArchitect assumes that you configured the
pin to be in output mode during the scan test and does not check for correct configuration.
If -Registered is specified, the scan_output_pin is the input of the DFF tail register.
• -CLock pin_name
An optional switch and string pair that specifies the pin name of the clock that you want
LBISTArchitect to assign to the scan chain. You must have predefined this pin as a scan
clock by using the Add Clocks command.
• -CUt
An optional switch that specifies to remove an existing functional connection, if there is
one, to the specified scan output pin and to connect the last scan cell of the specified scan
chain to this scan output pin.
• -Registered
An optional switch that specifies to attach head and tail DFF registers to the scan chain.

LBISTArchitect Reference Manual, v2017.3 69

September 2017
BIST-Ready Command Dictionary
Add Scan Pins

• -Top primary_input_pin primary_out_pin

An optional switch and two string triplet that defines the corresponding top-level primary
input/output pins for the scan in and scan out ports. LBISTArchitect uses these names when
generating the faultsim dofile. Refer to the second example for clarification of how the
contents of the faultsim dofile are created. Both pin names must be supplied. This option
does not add pins to the top-level of the design.
Example 1
The following example assigns a scan input and scan output name to the scan chain:
add clocks 0 clk
set system mode dft
// run scan identification
run
add scan pins chain1 si so -clock clk
// scan insertion
insert test logic

Example 2
The following example assigns a scan input and scan output name to the scan chain, along with
assigning the top-level primary input and output pins when they have different names than the
specified internal scan_input_pin and scan_output_pin:
add clocks 0 clk
set system mode dft
// run scan identification
run
add scan pins chain1 u125/u121/Qi u126/u224/TI -top scan_in1 scan_out1
// scan insertion
insert test logic
write atpg setup scan.testproc scan.do

Figure 2-1 shows the resulting faultsim dofile from the Write Atpg Setup command. Notice that
the specified top-level primary pin names (scan_in1 and scan_out1) are used in place of the
internal scan in and scan out pin pathnames shown in Figure 2-2. Also notice that the Add Scan
Chains is commented out in the second figure.

Figure 2-1. LBISTArchitect-Generated faultsim dofile with -Top Option

//
// Generated by LBISTArchitect (BIST-Ready) at Mon Oct 25 10:15:42
1999
//
add scan groups grp1 scan.testproc
add scan chains grp1 scan_in1 scan_out1
add clocks o ck1
...

70 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Scan Pins

Figure 2-2. LBISTArchitect-Generated ATPG Dofile with No -Top Option

//
// Generated by LBISTArchitect (BIST-Ready) at Mon Oct 25 10:13:23
1999
//
// Command lines containing “//DFTA” have been commented
// out by LBISTArchitect because internal pins were specified.
// The lines may require editing to ensure a functional
// dofile.
add scan groups grp1 scan.testproc
//DFTA add scan chains grp1 u125/u121/Q u126/u224/TI
add clocks o ck1
...

Related Commands
Delete Scan Pins Setup Scan Pins
Report Scan Pins

LBISTArchitect Reference Manual, v2017.3 71

September 2017
BIST-Ready Command Dictionary
Add Sub Chains

Add Sub Chains

Scope: Setup mode
Usage
ADD SUb Chains object_name subchain_name scan_input_pin scan_output_pin length
scan_type [-Module | -Library_model | -Instance] [-TEN test_enable_pin {0 | 1}] [-TCLK
test_clock_pin {0 | 1}]
Description
Specifies a preexisting scan chain within a module, library model, instance, blackbox, or empty
module in a hierarchical design (subchain). An empty module is a module defined in the netlist
without any content; It only consists of an input and output port definition.
If you create scan on a block-by-block basis, then each module or instance has its own
preexisting scan chain(s). At the higher-design level, LBISTArchitect does not automatically
consider chains inserted at the lower level as scan sub-chains. The Add Sub Chains command
allows you to incorporate those scan sub-chains into the top-level scan chain(s) during the
stitching process.
If you perform block-by-block test synthesis at lower design levels, LBISTArchitect can write
the sub-chain setup information to a file with the Write Subchain Setup command. You can then
read in this setup file that contains the Add Sub Chains command as part of the setup and avoid
having to manually define the preexisting scan sub-chains at the higher design level.
You can define subchains with their inputs (scan input and scan enable pins on their subchain
container) tied to 0 or 1. You can also define subchains with their scan inputs connected to their
scan output either directly or via buffers. LBISTArchitect removes such connections from the
scan input pin and reuses the connection wire to connect the scan output port to the next scan
cell. Any buffers lying along such feedback are then retained in scan output connection.
To define clock information for subchains, see Add Subchain Clocks.
Scannability analysis DRCs: S1, S2, and S3 validate the defined subchains when you exit Setup
mode.
Arguments
• object_name
A required string that specifies either the pathname of an instance, the name of a module, or
the name of a library model. The object_name is the container where the sub-chain resides.
• subchain_name
A required string that specifies a name for the scan sub-chain. A unique sub-chain name
should be used for each Add Sub Chains command.
• scan_input_pin
A required string that specifies the scan input pin of the scan sub-chain.

72 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Sub Chains

• scan_output_pin
A required string that specifies the scan output pin of the scan sub-chain.
• length
A required integer that specifies the number of scan cells in the scan sub-chain.
• scan_type
Scan type usage:
Mux_scan{{-SEN_Core | -SEN_In | -SEN_Out} scan_enable [INVerted]} [-CLock
pin_name1 pin_name2] | Clocked_scan scan_clock | Lssd master_clock slave_clock
A required literal and multiple argument option that specifies the mux_scan type and control
of the scan sub-chain. Options include:
[-SEN_Core | -SEN_In | -SEN_Out] scan_enable [INVerted] — Required switch,
string, and literal that specifies the type, name, and internal inversion of the scan
enable pin on the sub-chain container (module or library_model).
Normally, LBISTArchitect inserts one type of scan enable signal, referred to as
Sen_core. In a partition scan insertion flow, LBISTArchitect can also insert two more
types of scan enable signals if partitioning by I/O type is specified. The scan enable
signals inserted for separate input and output partition cells are referred to as Sen_in
and Sen_out. For more information on partitioning by I/O type, refer to the section
that describes the Setup Partition Scan command. At least one of these three types of
scan enables must be specified in the sub-chain declaration. A sub-chain may contain
all three types of scan enables, in which case you should repeat the triplet for each
type of scan enable.
-Clock pin_name1 pin_name2 — An optional switch and two strings that specify the
names of the clock pins on the top module that control the defined sub-chain.
pin_name1 specifies the clocks for the first cell (closer to the scan input).
pin_nam2 specifies the name of the clock pin for the last cell (closer to the scan
output).
The first and the last cell clock pins determine the transition of clock domains when
the subchain is placed in a top-level scan chain, so lockup cells are inserted correctly
at these transitions. During scan cell partitioning, only the first cell clock pin
information is used to determine which top-level scan chain the sub-chain cell is
placed in. If this switch is not specified, LBISTArchitect tries to find the top-level
clock pins using the sub-clock pins via structural tracing, as described below. If
LBISTArchitect cannot determine the top module clock pins, it places the defined
sub-chain in separate scan chains in the top module, along with other sub-chains with
undetermined top module clock pins.
Clocked_scan scan_clock — A required literal and string pair that specifies the
clocked-scan style of scan cells and the name of the scan clock for the scan sub-chain.
Lssd master_clock slave_clock — A required literal and two-string triplet that specifies
Level-Sensitive Scan Design and the names of the master and slave clocks,
respectively, for the scan sub-chain.

LBISTArchitect Reference Manual, v2017.3 73

September 2017
BIST-Ready Command Dictionary
Add Sub Chains

• -Module | -Library_model | -Instance

An optional switch that specifies the type of the sub-chain container specified by the
object_name argument. The container can then be a module (-Module), a library model
(-Library_model), or an instance of a module/model (-Instance). The default type is
-Module.
• -TEN test_enable_pin {0 | 1}
An optional switch, string, and literal pair that specifies the test enable pin added in the sub-
module that you want connected to the corresponding pin in the top module. The active
value can be 0 or 1.
• -TCLK test_clock_pin {0 | 1}
An optional switch, string, and literal pair that specifies the test clock pin added in the sub-
module that you want connected to the corresponding pin in the top module. The off-state
value can be 0 or 1.
Examples
The following example defines a sub-chain on a sub-module:
add sub chains addr subc1 /scan_in1 /scan_out1 8 mux_scan -sen_core /scan_en inverted //
-clock /topclk1 /topclk2
report sub chains
mux_scan: addr subc1 8 scan_in1 scan_out1 scan_en (inverted)

This next example defines three sub-chains on an instance. Note that each sub-chain has its
designated scan enable pin:
add sub chains /mytop/u1 subc1 si1 so1 150 mux_scan -sen_in senin
add sub chains /mytop/u1 subc2 si2 so2 138 mux_scan -sen_out senout
add sub chains /mytop/u1 subc3 si3 so3 1600 mux_scan -sen_core sen
report sub chains
mux_scan: /mytop subc1 150 si1 so1 senin
mux_scan: /mytop subc2 138 si2 so2 seout
mux_scan: /mytop subc3 1600 si3 so3 sen

Related Commands
Add Clocks Setup Partition Scan
Add Subchain Clocks Write Subchain Setup
Report Scan Cells

74 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Subchain Clocks

Add Subchain Clocks

Scope: Setup mode
Prerequisites: Subchains must be added with the Add Sub Chains command.
Usage
ADD SUbchain CLocks subchain_name off_state {clock_port_name ...}
{-Set | -Reset | -First_cell_clock [-LEading_edge | -Trailing_edge]
| -LAst_cell_clock [-LEading_edge | -Trailing_edge]
Description
Specifies the clock pins for a scan chain within a module, library model, instance, blackbox, or
empty module of a hierarchical design.
Scannability analysis DRCs: S1, S2, and S3 validate the defined subchains when you exit Setup
mode.
Arguments
• subchain_name
A required string that specifies the name of a subchain previously defined with the
Add Sub Chains command.
• off_state
A required string that specifies the off state for sequential instances. Sequential instances
maintain their state when the clock is at the specified value; either 1 or 0.
• clock_port_name
A required repeatable string that specifies the clock pins on the subchain that must be
controlled during scan chain shifting.
• -Set
A required switch that specifies the clock pins listed by the clock_port_name argument are
set signals for cells in the subchain and should be held in the off state during scan chain
shifting.
• -Reset
A required switch that specifies the clock pins listed by the clock_port_name argument are
reset signals for cells in the subchain and should be held in the off state during scan chain
shifting.
• -First_cell_clock
A required switch that specifies the clock pin listed by the clock_port_name argument
drives the first cell in the subchain.

LBISTArchitect Reference Manual, v2017.3 75

September 2017
BIST-Ready Command Dictionary
Add Subchain Clocks

• -LAst_cell_clock
A required switch that specifies the clock pin listed by the clock_port_name argument
drives the last cell in the subchain.
• -LEading_edge
An optional switch that specifies the clock pin listed by the clock_port_name argument
updates cells on the leading edge of the off-state to on-state transition. This value is used
during scan chain stitching, so it is only valid for defining the first and/or last cell clocks.
• -Trailing_edge
An optional switch that specifies the clock pin listed by the clock_port_name argument
updates cells on the trailing edge of the off-state to on-state transition. This value is used
during scan chain stitching, so it is only valid for defining the first and/or last cell clocks.
Example 1
The following example defines a sub-chain on a library module:
add sub chains MULTIBITSFF3 chain1 SI SO 4 mux_scan S library_model
add subchain clocks chain1 0 RESET -reset
add subchain clocks chain1 0 SET -set
add subchain clocks 0 CK -first_cell_clock -leading_edge
add subchain clocks 0 CK -last_cell_clock -leading_edge
report subchain clocks chain1
// clock name type off_state edge
// ---------- ---- --------- -----
// RESET reset 0
// SET set 0
// CK first cell clock 0 leading edge
// CK last cell clock 0 leading edge

add subchain clocks chain1 1 SET -set

// Error: Duplicate clock definition for SET

delete subchain clocks chain1 CK

report subchain clocks chain1
// clock name type off_state edge
// ---------- ----- --------- ------
// RESET reset 0
// SET set 0

add subchain clocks chain1 0 CK -first_cell_clock -trailing_edge

report subchain clocks chain1
// clock name type off_state edge
// ---------- ---- ---------- ------
// RESET reset 0
// SET set 0
// CK first cell clock 0 trailing edge

76 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Subchain Clocks

Example 2
The following example reports subchains defined within a blackbox. The subchain is treated as
a single sequential instance, but it is listed once for each clock line that needs fixing.
DFT> report dft check
SCANNABLE SUBCHAIN Testlogic /macro MULTIBITSFFX (1)
Set: T /macro/SET1
SCANNABLE SUBCHAIN Testlogic /macro MULTIBITSFFX (1)
Set: T /macro/SET2
SCANNABLE SUBCHAIN Testlogic /macro MULTIBITSFFX (1)
Set: T /macro/SET3
SCANNABLE SUBCHAIN Testlogic /macro MULTIBITSFFX (1)
Reset: T /macro/RESET1

All the test logic issues for a specified subchain instance map to a single DRC rule violation.
The Analyze Drc Violation command displays the entire macro (with an X on each clock line
that requires test logic) and arbitrarily displays the driving gate for only one of the pins that
requires fixing.
Related Commands
Add Sub Chains Report Subchain Clocks
Delete Subchain Clocks Write Subchain Setup
Report Dft Check

LBISTArchitect Reference Manual, v2017.3 77

September 2017
BIST-Ready Command Dictionary
Add Test Points

Add Test Points

Scope: Setup and Dft mode
Prerequisites
You must define the model_name with either the Add Cell Models command or the cell_type
attribute within the DFT library.
Usage
ADD TEst Points tp_pin_pathname {{Control model_name [input_pin_pathname]
[mux_sel_input_pin] [-New_scan_cell scancell_model_name]} |
{Observe output_pin_pathname [-New_scan_cell scancell_model_name2]} |
{Lockup lockup_latch_model_name clkpin [-INVert | -NOInvert]}}
Description
Specifies explicitly where LBISTArchitect is to place a user-defined test point to improve the
design’s testability, through either improved controllability or improved observability.
The Add Test Points command allows you to manually specify the location of a test point and
whether that point is for control or observation. This command also allows you to specify
whether to insert a scan cell at the test point location, in addition to the control logic, for control
or observe purposes. An additional use of this command is for manually specifying the location
of lockup latches to control timing problems on merged scan chains.
The Add Test Points command operates independently of the Set Test Logic command. Set Test
Logic causes LBISTArchitect to automatically insert test logic during the scan synthesis
process, based upon the analysis LBISTArchitect performs during the rules checking process.
The Add Test Points command also works independently of the automatically system-defined
test points. For more information on using the automatic test point functionality, refer to
“Performing Input-Bounding, X-Bounding, and MTPI” in the LBISTArchitect Process Guide.
You can manually create user-defined test points with the Add Test Points command to increase
the testability of the design. For example, a test point can be useful in disabling latch loops or
cutting non-duplicating combinational loops. Note that this command only specifies the
location at which to add the test point.
If you specify the scan_cell option, LBISTArchitect adds a scan cell for either control or
observe purposes (depending on which you selected). LBISTArchitect inserts an instance of the
scan_model at the same time it inserts the rest of the scan elements, which is when you issue the
Insert Test Logic command.
Arguments
• tp_pin_pathname
A required string that specifies the location where you want LBISTArchitect to insert the
control or observe test point.

78 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Test Points

• Control model_name [input_pin_pathname] [mux_sel_input_pin] [-New_scan_cell

scancell_model_name]
The Control test point argument specifies that the test point is for control purposes.
model_name — A required string (if you use the Control argument) that specifies the
DFT library model that you want LBISTArchitect to place an instance of, at the
location specified by tp_pin_pathname. Before you can use the Add Test Points
command, you must use either the Add Cell Models command or the cell_type DFT
library attribute to define the DFT library model that corresponds to the model type
you want LBISTArchitect to insert. The valid cell model types include AND, OR,
INV, BUF, NAND, NOR, XOR and MUX.
input_pin_pathname — An optional string that specifies the pathname of the pin to
which you want to connect the other input of the gate specified by the model_name
argument. The pathname can be either to an existing primary input pin, an internal
driver pin, or a currently nonexistent pin. If the pin does not currently exist in the
design, LBISTArchitect transcripts a message when you issue this command, and
then creates a new primary input pin with the specified name during the insertion of
the scan chain(s).
mux_sel_input_pin — An optional string for use when the model_name argument type is
a MUX. It is not needed when inserting a buffer or inverter. This argument specifies
where LBISTArchitect is to connect the selector input of the multiplexer.

Figure 2-3. Control Example

tp_pin_pathname model_name

/I$21 /I$23

input_pin_pathname

(if -New_scan_cell) New scan cell

0/1 D Q
Connected by si
“Insert Test Logic” se so next scan cell
Existing scan clk
chain clock

-New_scan_cell scan_model_name — A switch and string pair that specifies whether

LBISTArchitect places a scan cell at the control test point and the DFT library
SCANCELL type model that you want inserted. If you use this option, you must first
define the scancell_model with the Add Cell Models command or the cell_type DFT
library attribute. LBISTArchitect automatically connects the new scan cell to the
same clock as the scan cell it feeds in the chain. See Figure 2-3.
Note that these are new scan cells, not scan replacements for existing sequential
elements. They are connected into chain(s) during insertion of test logic. If the design

LBISTArchitect Reference Manual, v2017.3 79

September 2017
BIST-Ready Command Dictionary
Add Test Points

contains no scan, the test point scan cells are connected into one or more scan chains,
depending on their clock pins.
• Observe output_pin_pathname [-New_scan_cell scancell_model_name2]
The Observe test point argument specifies for LBISTArchitect to place an observe point at
the location specified by the value of the tp_pin_pathname argument.
output_pin_pathname — A string that specifies the pathname of the primary output pin
that you want LBISTArchitect to connect to the observe point. If the primary output
pin does not currently exist in the design, LBISTArchitect creates a new primary
output pin with the specified name during the insertion of the scan chain(s).

Figure 2-4. Observe Example

PO
output_pin_pathname
(default)
tp_pin_pathname

/I$21 /I$23
New scan cell
(if -New_scan_cell)

D Q
Connected at si
“insert test logic” se
Existing scan clk
chain clock

-New_scan_cell scan_model_name2 — An optional switch and string pair that specifies

whether LBISTArchitect places a scan cell at the observe test point, and the DFT
library SCANCELL type model that you want inserted. If you use this option, you
must first define the scancell_model with the Add Cell Models command or the
cell_type DFT library attribute. LBISTArchitect automatically connects the new scan
cell to the same clock as the scan cell it feeds in the chain. See Figure 2-4.
Note that these are new scan cells, not scan replacements for existing sequential
elements. They are connected into chain(s) during insertion of test logic. If the design
contains no scan, the test point scan cells are connected into one or more scan chains,
depending on their clock pins.
• Lockup lockup_latch_model_name clkpin [-INVert | -NOInvert]
If you enable Set Lockup Latch on, LBISTArchitect normally inserts lockup latches where
necessary to control timing problems between cells in merged scan chains. This Lockup
argument lets you specify for LBISTArchitect to add a lockup latch at any specified
location.
If the location (tp_pin_pathname) is a primary output or an instance input pin, the tool
inserts the latch in front of the pin. If the location is a primary input or an instance output

80 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Test Points

pin, the tool inserts the latch after the pin, and it will drive all fanouts that were originally
driven by the pin.
lockup_latch_model_name — A required string (if you use the Lockup argument) that
specifies the library latch model name. If you use this option, you must first define the
model with the Add Cell Models command.
clkpin — A string that specifies the pathname of the clock pin to which the clock pin of
the latch is connected.
-INVert | -NOInvert — A switch that specifies whether to insert an inverter between the
specified clkpin and the clock input to the latch. The default is -NOInvert.
Examples
The following example first defines a DFT library model (and2a) of type AND, and then
defines a control test point, which LBISTArchitect then generates as part of the Insert Test
Logic command:
add cell models and2a -type and
add test point /I_6_16/cp control and2a control1
set system mode dft
run
insert test logic

Related Commands
Add Cell Models Report Test Points
Delete Test Points Set Lockup Latch
Insert Test Logic Set Test Logic

LBISTArchitect Reference Manual, v2017.3 81

September 2017
BIST-Ready Command Dictionary
Add Tied Signals

Add Tied Signals

Scope: Setup mode
Usage
ADD TIed Signals {0 | 1 | X | Z} floating_object_name… [-Pin]
Description
Specifies for LBISTArchitect to hold the named floating objects (nets or pins) at the given state
value.
LBISTArchitect creates a tied simulation gate (depending on the tied value) for each tied signal
during the design flattening process. If you do not assign a specific value to a floating object,
LBISTArchitect ties the object i to the default value for all tied objects. You can change the
value for tied objects from the invocation default value of unknown (X) by using the Setup Tied
Signals command.
When you add tied signals or pins, the tool places them into the user class. This includes
instance-based blackbox tied signals. When the netlist ties signals or pins to a value, the tool
places them into the system class.
Note
The tool will not tie a signal that is connected to I/O pins. This causes a problem if you
are considering UDD as an I/O pin.

Arguments
• 0
A literal that specifies to tie the floating nets or pins to logic 0 (low to ground).
• 1
A literal that specifies to tie the floating nets or pins to logic 1 (high to voltage source).
• X
A literal that specifies to tie the floating nets or pins to unknown.
• Z
A literal that specifies to tie the floating nets or pins to high-impedance
• floating_object_name
A required, repeatable string that specifies the floating nets or pins to which you want to
assign a specific value. The tool assigns the tied value to all floating nets or pins in all
modules that have the specified names.
If you do not specify the -Pin option, the tool assumes the name is a net name. If you do
specify the -Pin option, the tool assumes the name is a pin name. If you specify a net
pathname, you cannot use the -Pin option.

82 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Add Tied Signals

• -Pin
An optional switch specifying that the floating_object_name argument that you provide is a
floating pin name.
Examples
The following example ties all floating signals in the circuit that have the net names vcc and
vdd, to logic 1 (tied to high):
add tied signals 1 vcc vdd

Related Commands
Delete Tied Signals Report Tied Signals
Setup Tied Signals

LBISTArchitect Reference Manual, v2017.3 83

September 2017
BIST-Ready Command Dictionary
Add Write Controls

Add Write Controls

Scope: Setup mode
Usage
ADD WRite Controls {0 | 1} primary_input_pin…
Description
Specifies the off-state value of the write control lines for RAMs.
The Add Write Controls command defines the circuit write control lines and assigns their off-
state values. The off-state value of the pins that you specify must be sufficient to keep the RAM
contents stable. You may not use clocks, constrained pins, or equivalent pins as write control
lines.
Arguments
• 0
A literal specifying that 0 is the off-state value for the RAM primary_input_pin.
• 1
A literal specifying that 1 is the off-state value for the RAM primary_input_pin.
• primary_input_pin
A required, repeatable string that specifies the primary input pins that are write control lines
for the RAM and to which you want to assign an off-state value.
Examples
The following example assigns an off-state to two write control lines, w1 and w2:
add write controls 0 w1 w2
set system mode dft
run

Related Commands
Analyze Control Signals Report Write Controls
Delete Write Controls

84 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Alias

Alias
Scope: All modes
Usage
ALIas [synonym {!unix_command; | tool_command; | alias_synonym;}…]
Description
Specifies the shorthand name for a BIST-Ready command, UNIX command, or existing
command alias, or any combination of the three.
Issuing the Alias command with no arguments will list 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.
In addition, you can parameterize the command strings 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 arguments, which are substituted into the command prior
to its execution.
You can also provide an optional file, .lbistarchitect_startup, that contains commands that you
want executed prior to any other batch or interactive commands. The primary purpose of this
file is to execute Alias commands that tailor the tool’s command language to your needs. Upon
invocation, the tool searches for the startup file in the following locations and order of
precedence:
1. The directory pointed to by the MGCDFT_STARTUP environment variable
2. The local invocation directory
3. Your home directory
The first startup file the tool encounters is the only one it executes if you have startup files in
multiple locations. If the tool does not locate a tool_specific startup file, it searches the same
locations for the generic startup file, .mgcdft_startup.
Arguments
• synonym {!unix_command; | tool_command; | alias_synonym;}
An optional string with a repeatable string that specifies a shorthand name, synonym, for the
specified UNIX or tool command or for a previously-defined alias synonym (which has the
effect of a command). Repeated commands must be separated by semicolons.
!unix_command — An optional, repeatable string that consists of any well-formed
UNIX command, with its arguments, or a UNIX script. You must precede this string
with an exclamation point to differentiate it from a tool-specific command.
tool_command — An optional, repeatable string that consists of any well-formed BIST-
Ready command and its arguments.

LBISTArchitect Reference Manual, v2017.3 85

September 2017
BIST-Ready Command Dictionary
Alias

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 Netscape 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 any “lckup” names:
alias findlockup !find . -name \*.v -print -exec egrep lckup {} \;

You could then use that new command within another Alias command that writes out the
current design:
alias findit write netlist -verilog temp.v -replace; findlockup

Related Commands
System Dofile
History
Command Summary

86 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Analyze Control Signals

Analyze Control Signals

Scope: All modes
Usage
ANAlyze COntrol Signals [-Report_only | -Auto_fix] [-Verbose]
Description
Identifies and optionally defines the primary inputs of control signals.
The Analyze Control Signals command analyzes each control signal (clocks, set, reset, write-
control, read-control, and so on) of every sequential element (DFF, latch, RAM, ROM, and so
on) and optionally defines its primary input as a control signal. The purpose of analyzing the
control signals is to identify the primary input that needs to be defined as a clock, read-control,
or write-control for LBISTArchitect. This analysis also considers pin constraints, but only
traces through simple, combinational gates.

If the -Verbose option is specified, the tool issues messages indicating why certain control
signals are not reported as controllable. At the end of the analysis, statistical information
displays, listing the number of primary inputs identified as control signals, their types, and
additional information.

If the -Auto_fix option is specified, all identified primary inputs of control signals are
automatically defined. For example, when a clock is identified, an implicit Add Clocks
command is performed to define the primary input. The default for control signals is report
only.

Note
This command performs the flattening process automatically, if executed prior to
performing flattening.

Arguments
• -Report_only
An optional literal that specifies to only identify control signals (not to define the primary
inputs as control signals). This is the invocation default.
• -Auto_fix
An optional literal that specifies to define the primary inputs of all identified control signals
as control signals. For example, when the tool identifies a clock, it also performs an implicit
Add Clocks command to define that primary input.
• -Verbose
An optional literal that specifies to display information on control signals (whether they are
identified or not, and why) while the analysis is performed.

LBISTArchitect Reference Manual, v2017.3 87

September 2017
BIST-Ready Command Dictionary
Analyze Control Signals

Examples
The following example analyzes the control signals, then only provides a verbose report on the
control signals in the design. After examining the transcript, you can then perform another
analysis of the control signals to add them.
analyze control signals -verbose
// command: analyze control signals -reports_only -verbose
//
------------------------------------------------------------------------
// Begin control signals identification analysis.
//
------------------------------------------------------------------------
// Warning: Clock line of ‘/cc01/tim_cc1/add1/post_latch_29/WRITEB_reg/r/
(7352)’ is uncontrolled at ‘/IT12 (4)’.
...
...
// Identified 2 clock control primary inputs.
// /IT23 (5) with off-state = 0.
// /IT12 (4) with off-state = 0.
// Identified 0 set control primary inputs.
// Identified 1 reset control primary inputs.
// /IRST (1) with off-state = 0.
// Identified 0 read control primary inputs.
// Identified 0 write control primary inputs.
-----------------------------------------------------------------------
// Total number of internal lines is 105 (35 clocks, 35 sets , 35 resets,
0 reads, 0 writes).
// Total number of controlled internal lines is 25 (17 clocks, 0 sets ,
8 resets, 0 reads, 0 writes).
// Total number of uncontrolled internal lines is 80 (18 clocks, 35 sets,
27 resets, 0 reads, 0 writes).
// Total number of added primary input controls 0 (0 clocks, 0 sets ,
0 resets, 0 reads, 0 writes).
-----------------------------------------------------------------------

analyze control signals -auto_fix -verbose

Related Commands
Add Clocks Report Clocks
Add Read Controls Report Read Controls
Add Write Controls Report Write Controls

88 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Analyze Input Control

Analyze Input Control

Scope: Dft mode
Usage
ANAlyze INput Control
Description
Analyzes and reports the effects of constraining primary input pins to an unknown value.
When creating wrapper chains, you must constrain uncontrollable primary inputs at the
chip-level with the Add Pin Constraints command. LBISTArchitect then uses the constrained
inputs when identifying non-scan cells to place in the input wrapper chains.
Sometimes there is combinational logic between the constrained pin and the sequential element
that gets converted to an input wrapper cell, constraining the primary input pin can impact the
fault detection of this combinational logic.
The Analyze Input Control command determines the controllability factor of an input pin by
removing the X constraint, and calculating the controllability improvement on the affected
combinational gates. If a constrained input pin has a significant impact on the fault coverage
within that combinational logic, you should consider making that pin a test point or adding a
new scan cell either inside or outside of that wrapper chain to improve fault detection.
LBISTArchitect reports the results of the analysis with the primary input having the largest
controllability gain listed first.
Examples
The following example adds three pin constraints and then reports the constrained pins in
descending order based on controllability gain:
add pin constraints data1 cx
add pin constraints addr4 cx
add pin constraints addr7 cx
analyze input control
addr4
addr7
data1

Related Commands
Add Pin Constraints Report Testability Analysis
Analyze Output Observe Setup Scan Identification

LBISTArchitect Reference Manual, v2017.3 89

September 2017
BIST-Ready Command Dictionary
Analyze Output Observe

Analyze Output Observe

Scope: Dft mode
Usage
ANAlyze OUtput Observe
Description
Analyzes and reports the observabilty effects of masked primary output pins.
When creating wrapper chains, you must mask unobservable primary outputs at the chip-level
with the Add Output Masks command. LBISTArchitect then uses the masked outputs when
identifying the non-scan cells to place in the output wrapper chains.
When there is combinational logic between the masked pin and the sequential element that gets
converted to an output wrapper cell, masking the primary output pin can impact the fault
detection of this combinational logic.
The Analyze Output Observe command determines the observability factor of an output pin by
removing the mask and calculating the observability improvement on the affected
combinational gates. If a masked output pin has a significant impact on the fault coverage
within that combinational logic, you should consider making that pin a test point or adding a
new scan cell either inside or outside of that wrapper chain to improve fault detection.
LBISTArchitect reports the results of the analysis with the primary output put having the largest
observability gain listed first.
Examples
The following example masks three primary outputs, analyzes the observability, and reports the
masked output pins in descending order based on observability gain:
add output masks qout1 -hold 1
add output masks addr_res<1> -hold 0
add output masks addr_res<4> -hold 1
analyze output observe
addr_res<1>
qout1
addr_res<4>

Related Commands
Add Output Masks Report Testability Analysis
Analyze Input Control Setup Scan Identification

90 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Analyze Testability

Analyze Testability
Scope: Dft mode
Usage
ANAlyze TEstability [-Scoap_only]
Description
Reports general scannability and testability information, as well as calculating the
controllability and observability values for gates.
The Analyze Testability command reports general scannability and testability information that
can help you determine how much partial scan the design may need to achieve high test
coverage.
The scannability and testability information reported includes:
• Statistics about the total number of sequential elements, number of scannable sequential
elements, number of nonscannable sequential elements, and so on
• Number of scannable sequential elements that need to be scanned to break all global
sequential loops
• Number of scannable sequential elements with self loops
• Number of scannable sequential elements required to scan RAM boundaries (if the
design contains RAMs)
• Number of scannable sequential elements required to limit sequential depth and
consecutive self loops.

Note
If the design contains sequential loops, the reported sequential depth is estimated.

• Number of uncontrollable and unobservable scannable sequential elements (based on

SCOAP analysis)
The information reported is mainly related to the structure of the circuit. If you are using
structure-based scan selection, you can use the report to correlate structural criteria with the
amount of scan required. For example, you will see a report on how much scan is required to
break all sequential loops or to limit sequential depth to a given number. This can help you in
determining what parameters to provide to structure-based scan selection.
If you want to use partial scan, it is recommended that you use the more automated, Automatic
scan-selection method. The information provided by this report can also give you a measure of
how testable the circuit is at any given time, which can help you in determining whether more
scan needs to be selected. For example, if all global loops are broken and the sequential depth is
small, this indicates that the circuit is likely to achieve high test coverage and that the scan
selected thus far may be sufficient.

LBISTArchitect Reference Manual, v2017.3 91

September 2017
BIST-Ready Command Dictionary
Analyze Testability

In addition, this command uses SCOAP testability measures to calculate the controllability and
observability of individual gates which can be reported using the Report Testability Analysis
command. If you use the -Scoap_only switch, this command only calculates the controllability
and observability values.
Arguments
• -Scoap_only
A switch that specifies to only compute SCOAP controllability and observability numbers
for use with the Report Testability Analysis command. If this switch is not specified, these
numbers are still calculated, but in addition, scannability and testability information is
calculated and reported.
Examples
The following example shows the default output from the Analyze Testability command. The
controllability and observability numbers are also calculated, but must be reported using the
Report Testability Analysis command (as shown in the next example).
DFT> analyze testability
// Number of sequential instances:
// Total = 751
// Scannable = 319 ( 42.48%)
// Identified = 0 ( 0.00%)

// Targets = 319 ( 42.48%)

// Uncontrollable = 319 ( 42.48%)
// Unobservable = 319 ( 42.48%)
// Maximum sequential depth = 115
// Scannable instances with self loops = 165 ( 21.97%)
// Scan to break global loops = 98 ( 13.05%)
// Scan RAM boundaries = 74 ( 9.85%)
// Scan to limit consecutive self loops:
// To 32 = 28 ( 3.73%)
// To 16 = 52 ( 6.92%)
// To 8 = 56 ( 7.46%)
// To 4 = 78 ( 10.39%)
// To 2 = 104 ( 13.85%)
// Scan to limit sequential depth:
// To 64 = 80 ( 10.65%)
// To 32 = 122 ( 16.25%)
// To 16 = 150 ( 19.97%)
// To 8 = 150 ( 19.97%)
// To 4 = 165 ( 21.97%)
// To 2 = 248 ( 33.02%)

The following example shows the flow of displaying only the controllability values. The report
displays the controllability value for the low logic state (where NC means non-controllable), the
controllability value for the high logic state, the primitive gate type, the gate identification
number, and the pathname to the gate.

92 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Analyze Testability

set system mode dft

…
analyze testability -scoap_only
report testability analysis -control -percent 5
0 NC TIE0 32 /addr/U15
NC 0 TIE1 53 /addr/U35
1 7001 INV 95 /cntr/U45
5672 1 BUF 382 /blk1/U85

Related Commands
Add Test Points Setup Scan Identification
Report Testability Analysis

LBISTArchitect Reference Manual, v2017.3 93

September 2017
BIST-Ready Command Dictionary
Archive Test_points

Archive Test_points
Scope: Dft mode
Usage
ARChive TEst_points tpfile [-Replace]
Description
Saves the MTPI testpoint insertion information in an archive file.
The Archive Test_points command is for use in a flow in which you have inserted test points
and are trying to achieve timing closure. Because following this flow could result in a reduction
in fault coverage, it is assumed that timing closure is the primary objective.
The flow consists of these steps:
1. Run MTPI and save the test point-inserted netlist. Archive the test point information to
tpfile with Archive Test_points.
2. Run static timing analysis on the saved netlist to identify new paths that violate timing.
Correlate those paths to the MTPI-inserted test points.
3. Reinvoke BIST-Ready on the original core netlist and read in tpfile with the Restore
Test_points command. Remove the test points associated with the timing violations
using the Delete Mtpi Control_point or Delete Mtpi Observe_point commands. Insert
test logic and save the netlist
Arguments
• tpfile
A required string that specifies the name of a text file containing information about the test
points identified in a MTPI run. This is a plain text file, not a list of BIST-Ready commands.
• -Replace
An optional switch that specifies to overwrite the contents of tpfile if a file by the same
name already exists.
Examples
The following example uses MTPI to identify test points, inserts the test points then archives the
test points into the file mtpi1.arc:
…
setup test_point identification -control 10-observe 10 -patterns 8191 -verbose -phases 4
-bpc_threshold 5 -sig_prob_threshold 0.1
setup test_point insertion -observe /NX1 -model FD1SQA
insert test logic -test_point on -scan off
archive test_points mtpi1.arc -replace

94 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Archive Test_points

Related Commands
Restore Test_points Delete MTPI Observe_point
Delete MTPI Control_point Write Static_timing Setup

LBISTArchitect Reference Manual, v2017.3 95

September 2017
BIST-Ready Command Dictionary
Delete Black Box

Delete Black Box

Scope: Setup mode
Usage
DELete BLack Box -Instance [ins_pathname] | -Module [module_name] | -All
Description
Undoes the effect of the Add Black Box command.
For a module that you originally modeled, removing the effects of the Add Black Box command
reinstates the original model. Specified tied values are no longer set on the output pins. For a
module that was empty or undefined in the input netlist, the output pins revert to the default tied
value of X.
Note
The tool releases the flattened model if one exists at the time you issue this command.

Arguments
• -Instance [ins_pathname]
A switch that specifies for the tool to undo the effect of the Add Black Box command on all
instance-based blackboxes. This is the default if no ins_pathname is given. You can
optionally specify an instance pathname to undo a single instance-based blackbox.
• -Module [module_name]
A switch that specifies for the tool to undo the effect of the Add Black Box command on all
module-based blackboxes. This is the default if no module_name is given. You can
optionally specify a module name to undo a single module-based blackbox.
• -All
A switch that specifies for the tool to undo the effect of the Add Black Box command on all
blackboxes.
Example
The following example adds the black box for module core then undoes all blackboxes that
were defined.
add black box -module core 1
delete black box -all

Related Commands
Add Black Box Report Black Box
Delete Tied Signals

96 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Buffer Insertion

Delete Buffer Insertion

Scope: All modes
Usage
DELete BUffer Insertion test_pin… | -ALL
Description
Specifies the type of scan test pins on which you want to remove the fanout limit.
The default fanout limit on all types of scan test pins is infinity. You can limit the fanout with
the Add Buffer Insertion command, and you can remove that limit with the Delete Buffer
Insertion command. If you remove the limit, LBISTArchitect resets the limit to the default of
infinity.
Arguments
• test_pin
A repeatable literal that specifies the type of the primary input scan pin from which you
want LBISTArchitect to remove the fanout limit. The following shows the default pin
names for each type of scan pin, but you can change the default names using the Setup Scan
Insertion command.
SEN (scan enable; default name scan_en) — A literal that specifies the primary input
pin that enables the scan chain.
SCLK (scan clock; default name scan_clk) — A literal that specifies the primary input
pin that clocks the scan data through the scan chain; the clocked scan type uses this pin.
TEN (test logic enable; default name test_en) — A literal that specifies the primary
input that enables the operation of the test logic circuitry.
TCLK (test logic clock; default name test_clk) — A literal that specifies the primary
input pin that clocks the values LBISTArchitect requires for proper functionality of the
test logic.
SMCLK (master scan clock; default name scan_mclk) — A literal that specifies the
primary input that clocks the scan data into the master scan elements of the scan chain
when using the LSSD scan type.
SSCLK (slave scan clock; default name scan_sclk) — A literal that specifies the
primary input that clocks the scan data into the slave scan elements of the scan chain
when using the LSSD scan type.
• -ALL
A switch that removes the fanout limits from all the primary input scan pins and returns each
to its default setting of infinity.

LBISTArchitect Reference Manual, v2017.3 97

September 2017
BIST-Ready Command Dictionary
Delete Buffer Insertion

Examples
The following example changes the default settings for test logic and then removes those
settings. The two reports show the results of each command.
add buffer insertion 5 ten tclk -model buf1a
report buffer insertion
scan_enable <infinity>
scan_clock <infinity>
test_enable 5 buf1a
test_clock 5 buf1a
scan_master_clock <infinity>
scan_slave_clock <infinity>
hold_enable <infinity>

delele buffer insertion -all

report buffer insertion
scan_enable <infinity>
scan_clock <infinity>
test_enable <infinity>
test_clock <infinity>
scan_master_clock <infinity>
scan_slave_clock <infinity>
hold_enable <infinity>

Related Commands
Add Buffer Insertion Report Buffer Insertion

98 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Cell Models

Delete Cell Models

Scope: All modes
Usage
DELete CEll Models dftlib_model… | {-Type {INV | And | Buf | OR | NAnd | NOr | Xor |
INBuf | OUtbuf | Mux | Scancell | DFf | DLat}} | -All
Description
Specifies the name of the DFT library cell that LBISTArchitect is to remove from the active list
of cells that the user can access when adding test points or that LBISTArchitect can access when
inserting test logic.
You originally added the cells to the active list with either the Add Cell Models command or
with the cell_type library attribute. If you remove a cell model from the active list, you only
remove the cell from that list and do not change the DFT library.
If you accidently delete a DFT library cell from the active list with the Delete Cell Models
command, you can add the specified cell back into the active list with the Add Cell Models
command.
Arguments
• dftlib_model
A repeatable string that specifies the names of the particular DFT library models that you
want LBISTArchitect to remove from the active list.
• -Type INV | And | Buf | OR | NAnd | NOr | Xor | INBuf | OUtbuf | Mux | Scancell | DFf |
DLat
A switch and argument pair that specifies the cell model type of all DFT library models that
you want LBISTArchitect to remove from the active list. The valid cell model types are as
follows:
INV — A literal that specifies a one-input inverter gate.
And — A literal that specifies a two-input AND gate.
Buf — A literal that specifies a one-input buffer gate.
OR — A literal that specifies a two-input OR gate.
NAnd — A literal that specifies a two-input NAND gate.
NOr — A literal that specifies a two-input NOR gate.
Xor — A literal that specifies an exclusive OR gate.
INBuf — A literal that specifies a primary input buffer gate.
OUtbuf — A literal that specifies a primary output buffer gate.
Mux — A literal that specifies a 2-1 multiplexer.
Scancell — A literal that specifies a mux-scan D flip-flop.

LBISTArchitect Reference Manual, v2017.3 99

September 2017
BIST-Ready Command Dictionary
Delete Cell Models

DFf — A literal that specifies a D flip-flop.

DLat — A literal that specifies a D latch.
• -All
A switch that removes all cell models from the active list, including those tagged in the DFT
library with the cell_type attribute. This switch does not change the contents of the DFT
library, only the active list within LBISTArchitect.
Examples
The following example removes a DFT library model from the active list:
add clocks 0 clk
set test logic -set on -reset on
set system mode dft
add cell models and2 -type and
add cell models or2 -type or
add cell models mux21h -type mux s a b
add cell models nor2 -type nor
delete cell models or2
insert test logic

Related Commands
Add Cell Models Set Test Logic
Report Cell Models

100 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Clock Groups

Delete Clock Groups

Scope: Dft mode
Usage
DELete CLock Groups group_name… | -All
Description
Specifies the name of the group that you want to remove from the clock groups list.
If you are going to merge multiple shift clocks together to form one scan chain, you can use the
Add Clock Groups command to place the shift clocks in the same clock group. If you make a
mistake when defining the clocks within a clock group, you can use the Delete Clock Groups
command. As you delete clock groups, the specified clocks are returned to the default clock
group, all_clocks.
Arguments
• group_name
A repeatable string that specifies the names of the clock groups that you want to remove.
The value of the group_name argument is the same as that which you specified with the Add
Clock Groups command.
• -All
A switch that specifies to remove all the clock groups.
Examples
The following example defines the current clocks, splits those clocks incorrectly into two
different groups, removes the clock group that was incorrectly defined, and then continues
defining the clock groups:
add clock 1 clk1 clk2
add clock 0 pre1 clr1 pre2 clr2
set system mode dft
…
add clock groups group1 clk1 pre2 clr1
delete clock groups group1
add clock groups group1 clk1 pre1 clr1
add clock groups group2 clk2 pre2 clr2

Related Commands
Add Clock Groups Report Clock Groups
Add Clocks Report Clocks

LBISTArchitect Reference Manual, v2017.3 101

September 2017
BIST-Ready Command Dictionary
Delete Clocks

Delete Clocks
Scope: Setup mode
Usage
DELete CLocks primary_input_pin… | -All
Description
Removes primary input pins from the clock list.
The Delete Clocks command removes the specified primary input pins from the clock list.
Deleted clocks are also removed from the default clock group, all_clocks. If you remove an
equivalence pin from the clock list, LBISTArchitect automatically removes all of the equivalent
pins from the clock list.
Arguments
• primary_input_pin
A repeatable string that specifies the list of primary input pins that you want to delete from
the clock list.
• -All
A switch that deletes all pins from the clock list.
Examples
The following example deletes an incorrect clock from the clock list:
add clocks 1 clock1
add clocks 1 clock2
delete clocks clock1

Related Commands
Add Clocks Report Clocks

102 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Mapping Definition

Delete Mapping Definition

Scope: Setup and Dft modes
Usage
DELete MApping Definition -All | {object_name [-Instance | -Module]
[-Nonscan_model nonscan_model_name] [-Scan_model scan_model_name]
[-Output [scan_ouput_pin_name]]}
Description
Returns the nonscan to scan model mapping to the default mapping defined by LBISTArchitect.
The Delete Mapping Definition command deletes the mapping of nonscan models to scan
models. You can remove the scan model mapping for an individual instance, all instances under
a hierarchical instance, all instances in all occurrences of a module in the design, or all
occurrences of the model in the entire design. Additionally, you can remove the mapping the
scan output pin of the scan model in the same manner.
To return the scan mapping back to the library default, you can specify the nonscan model, then
the scan mapping and output mapping are removed from the model. If you specify both the
nonscan and scan model, then the scan and output mapping is removed for only those instances
that match the nonscan and scan model.
When only removing the scan output pin mapping, you specify the scan model (and not the
nonscan model). If you also specify the output scan pin, then only scan candidates matching the
scan model and output pin have their output pin mapping removed.
Arguments
• -All
A switch that specifies to remove all scan and output mapping in the entire design.
• object_name
A string that specifies the name of the nonscan model you want to remove the mapping. You
can also specify an instance, hierarchical instance, module, or scan model.
o If this argument is the name of an instance or hierarchical instance, the -Instance
switch is required and the model must be specified with the -Nonscan_model switch
or -Scan_model switch.
o If this argument is the name of a module, then the -Module switch is required, and
the model must be specified with the -Nonscan_model or -Scan_model switch.
o If this argument is a scan model, then the -Output switch is required. Because you
specified a scan model, you can only remove the scan output pin mapping.
• -Instance | -Module
An optional switch that specifies the type of the object_name argument. If neither switch is
specified, the object_name is a model (the default).

LBISTArchitect Reference Manual, v2017.3 103

September 2017
BIST-Ready Command Dictionary
Delete Mapping Definition

o If you specify -Instance and the instance is primitive, then only the named instance
has its mapping changed.
o If you specify -Instance and the instance is hierarchical, then all instances under that
instance matching the -Nonscan_model or (for output mapping) matching the
-Scan_model have their mapping changed.
o If you specify -Module, then for all occurrences of that module, all instances within
that module that match the -Nonscan_model or (for output mapping) matching the
-Scan_model have their mapping changed.
• -Nonscan_model nonscan_model_name
A switch and string pair that specifies the name of the nonscan model that you want to
remove the scan and pin mapping. This is a required argument if you specify the -Instance
or -Module switch; otherwise, you can specify the nonscan model in the object_name
argument.
• -Scan_model scan_model_name
A switch and string pair that specifies the name of the scan model that is mapped to the
specified nonscan model. This is a required argument if you want to constrain the removing
of the scan mapping or are just removing the scan output pin mapping based on -Instance or
-Module.
• -Output [scan_ouput_pin_name]
An optional switch and optional string pair that specifies to remove the scan output pin.
Specifying just the -Output switch removes all changed scan output pins for the specified
scan model, while specifying the switch with a pin name removes the mapping for only scan
models that use that pin for the scan output.
Examples
The following example removes the scan and output mapping for all occurrences of the fd1
nonscan model in the design:
delete mapping definition fd1

The following example removes the scan and output mapping for each occurrence of the fd1
nonscan model that is mapped to the fd1s scan model and has the scan output pin mapped to
“qn”:
delete mapping definition fd1 -scan_model fd1s -output qn

The following example removes the scan and output mapping for each occurrence of the fd1
nonscan model under the hierarchical instance “/top/counter1”:
delete mapping definition /top/counter1 -instance -nonscan_model fd1

The following example removes the scan and output mapping for each occurrence the fd1
nonscan model that is mapped to the fd1s2 scan model in the “counter” module and for all
occurrences of that module in the design:
delete mapping definition counter -module -nonscan_model fd1 -scan_model fd1s2

104 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Mapping Definition

The following example removes the scan output pin mapping and returns it to the library default
for all occurrences of the fd1s scan model in the design:
delete mapping definition fd1s -output

The following example removes the scan output pin mapping and returns it to the library default
for all occurrences of the fd1s scan model in the design with the scan output pin set to “qn”:
delete mapping definition fd1s -output qn

Related Commands
Add Mapping Definition Report Mapping Definition

LBISTArchitect Reference Manual, v2017.3 105

September 2017
BIST-Ready Command Dictionary
Delete MTPI Control_point

Delete MTPI Control_point

Scope: Dft mode
Prerequisites
The current netlist must have had the archived list of MTPI test points from a pre-timing
analysis run restored with the Restore Test_points command prior to using this command.
Usage
DELete MTpi CONTROL_point tp_pin_pathname…
Description
Removes a specified MTPI control point from the current netlist.
The Delete MTPI Control_point command is for use in a flow in which you have inserted test
points and are trying to achieve timing closure. Because following this flow could result in a
reduction in fault coverage, it is assumed that timing closure is the primary objective.
The flow consists of these steps:
1. Run MTPI and save the test point-inserted netlist. Archive the test point information to
tpfile with Archive Test_points.
2. Run static timing analysis on the saved netlist to identify new paths that violate timing.
Correlate those paths to the MTPI-inserted test points.
3. Re-invoke BIST-Ready on the original core netlist and read in tpfile with the Restore
Test_points command. Remove the test points associated with the timing violations
using the Delete MTPI Control_point or Delete MTPI Observe_point commands. Insert
test logic and save the netlist
Arguments
• tp_pin_pathname
A required, repeatable string that specifies the name(s) of the MTPI control points to
remove from the current netlist. You can find the name of the control points by looking in
the archived test points file, tpfile.
Examples
The following example removes a MTPI control test point that was found to cause a timing
violation during a timing analysis run:
…
restore test_points mtpi1.arc
delete mtpi control_point u7/L_FA_reg_4_/Q or 3
insert test logic -test_point on -scan off
…

106 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete MTPI Control_point

Related Commands
Archive Test_points Restore Test_points
Delete MTPI Observe_point Write Static_timing Setup

LBISTArchitect Reference Manual, v2017.3 107

September 2017
BIST-Ready Command Dictionary
Delete MTPI Observe_point

Delete MTPI Observe_point

Scope: Dft mode
Prerequisites
The current netlist must have had the archived list of MTPI test points from a pre-timing
analysis run restored with the Restore Test_points command prior to using this command.
Usage
DELete MTpi OBserve_point {share_id | tp_pin_pathname…}
Description
Removes a specified MTPI observe point from the current netlist.
The Delete MTPI Observe_point command is for use in a flow in which you have inserted test
points and are trying to achieve timing closure. Because following this flow could result in a
reduction in fault coverage, it is assumed that timing closure is the primary objective.
The flow consists of these steps:
1. Run MTPI and save the test point-inserted netlist. Archive the test point information to
tpfile with Archive Test_points.
2. Run static timing analysis on the saved netlist to identify new paths that violate timing.
Correlate those paths to the MTPI-inserted test points.
3. Re-invoke BIST-Ready on the original core netlist and read in tpfile with the Restore
Test_points command. Remove the test points associated with the timing violations
using the Delete MTPI Control_point or Delete MTPI Observe_point commands. Insert
test logic and save the netlist.
Arguments
• share_id
An integer that specifies the name of a group of shared observe points. Use this argument to
remove an entire tree. You can find the name of the tree by looking in the archived test
points file, tpfile.
• tp_pin_pathname
A repeatable string that specifies the name of the MTPI observe point to remove from the
current netlist. You can find the name of the observe points by looking in the archived test
points file, tpfile.

108 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete MTPI Observe_point

Examples
The following example removes a MTPI observe test point that was found to cause a timing
violation during a timing analysis run:
…
restore test_points mtpi1.arc
delete mtpi observe_point u7/L_FA_reg_4_/Q or 3
insert test logic -test_point on -scan off
…

Related Commands
Archive Test_points Restore Test_points
Delete MTPI Control_point Write Static_timing Setup

LBISTArchitect Reference Manual, v2017.3 109

September 2017
BIST-Ready Command Dictionary
Delete Nofaults

Delete Nofaults
Scope: Setup mode
Usage
DELete NOfaults {-All | {modulename -Module} | {object_expression… [-PIN | -Instance]}}
[-Stuck_at {01 | 0 | 1}] [-VERbose] [{> | >>} file_pathname]
Description
Removes the no-fault settings from either the specified pin or instance pathnames.
The Delete Nofaults command deletes the nofault settings which were previously specified with
the Add Nofaults command. You can optionally specify nofault settings that have a specific
stuck-at value. If you do not specify a stuck-at value when deleting a nofault setting, the
command deletes both the “stuck-at-0” and “stuck-at-1” nofault settings.
If the pathname is a pin, then LBISTArchitect removes the nofault on only that pin. If the
pathname is an instance, then the tool removes all pin nofaults on the top-level of that instance,
along with all the pin faults underneath that instance (if it is a hierarchical instance). If the
pathname is a module, then the tool removes all pin nofaults on the top-level of the module,
along with all the pin nofaults on all instances and pins underneath that module for every
occurrence of that module in the design.
You can use the Report Nofaults command to display all the current nofault settings.
Arguments
• -All
A switch that deletes all nofault settings.
• modulename
A string that specifies the name of a module from which you want to delete nofault settings.
You must include the -Module switch when you specify a module name.
• -Module
A switch that specifies interpretation of the modulename argument as a module pathname.
All instances of these modules are affected. You can use the asterisk (*) and question mark
(?) wildcards for the modulename argument, and the tool deletes the nofault for all
matching modules or library models.
• object_expression
A string representing a list of pathnames of instances or pins from which you want to delete
nofault settings. The string may include any number of embedded asterisk (*) or question
mark (?) wildcard characters. The asterisk matches any sequence of characters (including
none) in a name, and the question mark matches any single character.
Pin pathnames must be ATPG library cell instance pins, also referred to as design level pins.
If the object expression specifies a pin within an instance of an ATPG library model, the
tool ignores it. By default, pin pathnames are matched first. If a pin pathname match is not

110 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Nofaults

found, the tool next tries to match instance pathnames. You can force the tool to match only
pin pathnames or only instance pathnames by including the -Pin or -Instance switch after the
object_expression.
• -Pin
An optional switch that specifies to use the preceding object expression to match only pin
pathnames; the tool will then delete nofault settings from all the pins matched.
• -Instance
An optional switch that specifies to use the preceding object expression to match only
instance pathnames; the tool will then delete nofault settings from all boundary and internal
pins of the instances matched.
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies the stuck-at values that you want to delete.
The valid stuck-at literals are as follows:
01 — A literal that specifies to delete both the “stuck-at-0” and “stuck-at-1” nofault
settings. This is the default.
0 — A literal that specifies to only delete the “stuck-at-0” nofault settings.
1 — A literal that specifies to only delete the “stuck-at-1” nofault settings.
• -VERbose
By default when you specify wildcard characters for instance (-INstance) or pin (-PIN)
names, the tool outputs a summary message similar to the following:
// Note: Adding faults for 330 fault sites.

When you specify the optional -VERbose switch, then the tool outputs the instance or pin
names instead of the summary. You can optionally redirect this output to a file using the >
or >> redirection operators.
If you use actual instance or pin names instead of wildcards, then this switch has no effect.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example deletes an extra added no fault instance.
add nofaults i_1006 i_1007 i_1008 -instance
report nofaults

LBISTArchitect Reference Manual, v2017.3 111

September 2017
BIST-Ready Command Dictionary
Delete Nofaults

USER : 01 i_1006/IN
USER : 01 i_1006/OUT
USER : 01 i_1007/IN
USER : 01 i_1007/OUT
USER : 01 i_1008/IN
USER : 01 i_1008/OUT

delete nofaults i_1007 -instance

report nofaults
USER : 01 i_1006/IN
USER : 01 i_1006/OUT
USER : 01 i_1008/IN
USER : 01 i_1008/OUT

Related Commands
Add Nofaults Report Nofaults

112 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Nonscan Instances

Delete Nonscan Instances

Scope: All modes
Usage
DELete NONscan Instances {{pathname… | instance_expression [-INStance | -Control_signal
| -Module]} | -All} [-Class {User | System | Full}]
Description
Removes the specified sequential instances from the non-scan instance list.
The Delete Nonscan Instances command deletes sequential instances, instances specified by
control signals, or all instances within the specified module that were previously added to the
non-scan instance list by using either the Add Nonscan Instances command. You can delete
either a specific list of instance names or all instances.
Note
If these nonscan instances are ignored for scannability checks and then the Delete
Nonscan Instances command is entered in Dft mode, these specified instances will not be
eligible for scan. You must go back to the Setup mode and then re-enter Dft mode to have
scannability checks performed on these instances which can make them eligible for scan.

To display the current non-scan instance list, use the Report Sequential Instances command.
Arguments
• pathname
A repeatable string that specifies either the pathnames of the instances or signals that control
instances that you want LBISTArchitect to delete from the non-scan instance list.
• instance_expression
A string representing a list of instances within the design. The string instance_expression is
defined as:
{ string | string * } ...

The asterisk (*) is a wildcard that allows you to match many instances in a design. Any
expression that does not contain an asterisk (*) will match exactly zero or one instance. See
the examples in the Report Instance command section for ways to use the asterisk (*)
wildcard.
• -INStance | -Control_signal | -Module
A switch that specifies whether the pathnames are instances, pins (control signals), or
modules. An example Verilog module is “module clkgen (clk, clk_out, …)” where clkgen is
the module name. You can only use the -Control_signal option in Dft mode. The switch
default is -Instance.

LBISTArchitect Reference Manual, v2017.3 113

September 2017
BIST-Ready Command Dictionary
Delete Nonscan Instances

• -All
A switch that specifies to delete all instances from the non-scan instance list.
• -Class User | Full
An optional switch and literal pair that specifies the source (or class) of the non-scan
instance that you want to delete. The valid literals are as follows:
User — A literal that specifies to only delete the non-scan instances entered by the user
using the Add Nonscan Instances command. This is the default.
Full — A literal that specifies to delete all the non-scan instances in the user and system
class.
Examples
The following example deletes an extra sequential non-scan instance called i_1007, then
performs a full scan identification run, thereby allowing LBISTArchitect to treat the non-scan
instance i_1007 as a scan cell during the identification process:
set system mode dft
add nonscan instances i_1006 i_1007 i_1008
delete nonscan instances i_1007
setup scan identification full_scan
run

Related Commands
Add Nonscan Instances Setup Scan Identification
Report Instance Set Nonscan Handling
Report Sequential Instances

114 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Nonscan Models

Delete Nonscan Models

Scope: All modes
Usage
DELete NONscan Models model_name… | -All [-Class {User | System | Full}]
Description
Removes from the non-scan model list the specified sequential DFT library models.
When you issue the Add Nonscan Models command on a DFT library model, LBISTArchitect
places all instances of that DFT library model into the user-specified, non-scan instance list.
Once you remove a model from the non-scan model list with the Delete Nonscan Models
command, LBISTArchitect then has the freedom to decide whether to place those instances of
that model in the scan instance list.
Note
If these nonscan instances (models) are ignored for scannability checks and then the
Delete Nonscan Models command is entered in Dft mode, these specified instances
(models) will not be eligible for scan. You must go back to the Setup mode and then re-
enter Dft mode to have scannability checks performed on these instances (models) which
can make them eligible for scan.

LBISTArchitect decides whether to place individual instances in the scan instance list based on
many parameters including the scan setup settings. For example, if the scan setup has been
changed to All with the Setup Scan Insertion command, then LBISTArchitect is forced to place
all available sequential instances into the scan instance list.
Arguments
• model_name
A repeatable string that specifies the model names that you want to delete from the non-scan
model list. Enter the model names as they appear in the DFT library.
• -All
A switch that specifies to delete all models from the non-scan model list.
• -Class User | System | Full
An optional switch and literal pair that specifies the class code of the non-scan model that
you specify. The valid literal names are as follows:
User — A literal that specifies that the list of non-scan models were previously added by
using the Add Nonscan Models command. This is the default class.
System — A literal that specifies that the list of non-scan models were added by
LBISTArchitect.
Full — A literal that specifies that the list of non-scan models consist of both the user
and system class.

LBISTArchitect Reference Manual, v2017.3 115

September 2017
BIST-Ready Command Dictionary
Delete Nonscan Models

Examples
The following example deletes an extra sequential non-scan model called d_flip_flop2, then
performs a full scan identification run thereby allowing LBISTArchitect to treat the non-scan
model d_flip_flop2 as a scan cell during the identification process:
set system mode dft
add nonscan models d_flip_flop1 d_flip_flop2
delete nonscan models d_flip_flop2
setup scan identification full_scan
run

Related Commands
Add Nonscan Instances Report Nonscan Models
Add Nonscan Models Set Nonscan Handling

116 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Notest Points

Delete Notest Points

Scope: Setup and Dft modes
Prerequisites
You must add circuit points with the Add Notest Points command before you can delete them.
Usage
DELete NOtest Points {pin_pathname… |
{instance_pathname… [-Observe_scan_cell]}} | -ALL |
{-Path critical_pathname} | -ALL_Paths
Description
Removes the specified pins from the list of notest points which the tool cannot use for testability
insertion.
The Delete Notest Points command deletes the definition of pins, all pins within an instance,
scan cell, or paths that you have previously added using the Add Notest Points command. These
notest circuit points identify output pins of cells or paths within the circuit that LBISTArchitect
is not to use for insertion of controllability and observability circuitry. You can display a list of
these current circuit points and their associated pins by using the Report Notest Points
command.
When you delete a critical path, the critical path is removed from the list of active paths (paths
read in using Add Notest Points). For each gate in a removed path (which is in no other
remaining active paths), the no test point restriction is removed.
Arguments
• pin_pathname
A repeatable string that specifies a list of pins that you want to reestablish as circuit points
that LBISTArchitect can use for testability insertion.
• instance_pathname [-Observe_scan_cell]
A repeatable string and optional switch that lists the instances for whose output pins you
want to reestablish as circuit points that LBISTArchitect can use for testability insertion. All
output pins within that (hierarchical) instance are removed from the list of pins that are
excluded from consideration.
-Observe_scan_cell — An optional switch that specifies the scan cell instance named in
the instance_pathname argument can once again be used as an observation scan cell.
• -ALL
A switch that deletes all circuit points and critical paths previously added with the Add
Notest Points command.

LBISTArchitect Reference Manual, v2017.3 117

September 2017
BIST-Ready Command Dictionary
Delete Notest Points

• -Path critical_pathname
A switch and string pair that specifies to delete the named critical path from the active list of
notest paths. You can list the names of the critical paths using the Report Notest Points
command with the -Paths switch. For more information on the format of the file, refer to
“The Path Definition File” in the Scan and ATPG User’s Manual.
• -ALL_Paths
A switch that specifies to delete all critical paths from the active list of notest paths.
Examples
The following example deletes an incorrect notest circuit point and corrects it with a new circuit
point before performing testability analysis:
set system mode dft
add notest points tr_i ts_i
delete notest points tr_i
add notest points tr_io

Related Commands
Add Notest Points Report Notest Points

118 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Output Masks

Delete Output Masks

Scope: Setup mode
Usage
DELete OUtput Masks primary_output… | -All
Description
Removes the masking of the specified primary output pins.
LBISTArchitect uses primary output pins as the observe points during the scan identification
process. When you mask a primary output pin with the Add Output Masks command,
LBISTArchitect marks that pin as an unobservable primary output during the identification
process.
You can set a default mask for all output and bidirectional pins using the Setup Output Masks
command. You can add a hold value to a default mask with the Add Output Masks command, or
remove a hold value using the Delete Output Masks command. To turn off the default masks for
all output pins, you must use the Setup Output Masks command with the Off literal.
Arguments
• primary_output
A repeatable string that specifies the names of the primary output pins that you want to
unmask.
• -All
A switch that specifies to unmask all primary outputs that you previously masked by using
the Add Output Masks command.
Examples
The following example first incorrectly chooses two of the design’s primary output pins to
mask. Then, the example unmasks the one primary output that was inappropriate, masks the
correct primary output, and then displays the complete list of primary output pins that are
currently masked from being used as observation points.
add output masks q1 qb3 -hold 1
delete output masks qb3
add output masks qb1 -hold 0
report output masks
q1 hold1
qb1 hold0

Related Commands
Add Output Masks Report Output Masks
Analyze Output Observe Setup Output Masks

LBISTArchitect Reference Manual, v2017.3 119

September 2017
BIST-Ready Command Dictionary
Delete Pin Constraints

Delete Pin Constraints

Scope: Setup mode
Usage
DELete PIn Constraints primary_input_pin… | -All
Description
Removes the pin constraints from the specified primary input pins.
The Delete Pin Constraints command deletes pin constraints that were previously added to the
primary inputs with the Add Pin Constraints command. You can delete the pin constraints for
specific pins or for all pins.
Note
This command has effects on other commands that relate to fault simulation; this includes
simulation-based and multiphase test points selection, along with BIST pattern
simulation (in BIST mode).

You can set a default pin constraint for all input and bidirectional pins using the Setup Pin
Constraints command. The pin constraints set by the Setup Output Masks command can have
their values overridden with the Add Pin Constraints command. You can remove an override of
a default pin constraint using the Delete Pin Constraints command. To remove the default pin
constraint for all input pins, you should use the Setup Pin Constraints command with the None
literal.
Arguments
• primary_input_pin
A repeatable string that specifies a list of primary input pins whose pin constraints you want
to delete.
• -All
A switch that specifies to delete the pin constraints of all primary input pins.
Examples
The following example adds two pin constraints and then deletes one of them:
add pin constraints ph1 c0
add pin constraints ph2 c0
delete pin constraints ph1

Related Commands
Add Pin Constraints Setup Pin Constraints
Report Pin Constraints

120 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Pin Equivalences

Delete Pin Equivalences

Scope: Setup mode
Usage
DELete PIn Equivalences primary_input_pin… | -All
Description
Removes the pin equivalence specifications for the designated primary input pins.
The Delete Pin Equivalences command deletes the equivalence specifications that were
previously added to the primary inputs with the Add Pin Equivalences command. You can
delete pin equivalences for specific pins or for all pins.
Note
This command has effects on other commands that relate to fault simulation; this includes
simulation-based and multiphase test points selection, along with BIST pattern
simulation.

Arguments
• primary_input_pin
A repeatable string that specifies a list of primary input pins whose equivalence
specifications you want to delete.
• -All
A switch that specifies to delete all pin equivalence effects.
Examples
The following example deletes an incorrect pin equivalence specification and adds the correct
one:
add pin equivalences indata2 -invert indata4
delete pin equivalences indata2
add pin equivalences indata3 -invert indata4

Related Commands
Add Pin Equivalences Report Pin Equivalences

LBISTArchitect Reference Manual, v2017.3 121

September 2017
BIST-Ready Command Dictionary
Delete Primary Inputs

Delete Primary Inputs

Scope: Setup mode
Usage
DELete PRimary Inputs {net_pathname… | primary_input_pin… | -All}
[-Class {User | System | Full}]
Description
Removes the specified primary inputs from the current netlist.
The Delete Primary Inputs command deletes the primary inputs that you specify from the
circuit. You can delete either the user class, system class, or full classes of primary inputs. If
you do not specify a class, the tool deletes the primary inputs from the user class.
You can display a list of any class of primary inputs by using the Report Primary Inputs
command.
Arguments
• net_pathname
A repeatable string that specifies the circuit connections that you want to delete. You can
specify the class of primary inputs to delete with the -Class switch.
• primary_input_pin
A repeatable string that specifies a list of primary input pins that you want to delete. You
can specify the class of primary inputs to delete with the -Class switch.
• -All
A switch that deletes all primary inputs. You can specify the class of primary inputs to
delete with the -Class switch.
• -Class User | System | Full
An optional switch and literal pair that specifies the class code of the designated primary
input pins. The valid class code literal names are as follows:
User — A literal specifying that the primary inputs were added using the Add Primary
Inputs command. This is the default class.
System — A literal specifying that the primary inputs derive from the netlist.
Full — A literal specifying that the primary inputs consists of both user and system
classes.
Examples
The following example deletes an extra added primary input from the user class of primary
inputs:
add primary inputs indata2 indata4 indata6
delete primary inputs indata4 -class user

122 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Primary Inputs

Related Commands
Add Primary Inputs Write Primary Inputs
Report Primary Inputs

LBISTArchitect Reference Manual, v2017.3 123

September 2017
BIST-Ready Command Dictionary
Delete Primary Outputs

Delete Primary Outputs

Scope: Setup mode
Usage
DELete PRimary Outputs {net_pathname… | primary_output_pin… | -All}
[-Class {User | System | Full}]
Description
Removes the specified primary outputs from the current netlist.
The Delete Primary Outputs command deletes the primary outputs that you specify from the
circuit. You can delete either the user class, system class, or full classes of primary outputs. If
you do not specify a class, the tool deletes the primary outputs from the user class.
You can display a list of any class of primary outputs by using the Report Primary Outputs
command.
Note
LBISTArchitect removes the output for the tool’s internal representation of the netlist.
The output, however remains in the generated netlist.

Arguments
• net_pathname
A repeatable string that specifies the circuit connections that you want to delete. You can
specify the class of primary outputs to delete with the -Class switch.
• primary_output_pin
A repeatable string that specifies a list of primary output pins that you want to delete. You
can specify the class of primary outputs to delete with the -Class switch.
• -All
A switch that deletes all primary outputs. You can specify the class of primary outputs to
delete with the -Class switch.
• -Class User | System | Full
An optional switch and literal pair that specifies the class code of the primary output pins
that you specify. The valid literal names are as follows:
User — A literal specifying that the list of primary outputs were added using the Add
Primary Outputs command. This is the default class.
System — A literal specifying that the list of primary outputs derive from the netlist.
Full — A literal specifying that the list of primary outputs consists of both the user and
system class.

124 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Primary Outputs

Examples
The following example deletes a primary output from the system class of primary outputs:
delete primary outputs outdata1 -class system

Related Commands
Add Primary Outputs Write Primary Outputs
Report Primary Outputs

LBISTArchitect Reference Manual, v2017.3 125

September 2017
BIST-Ready Command Dictionary
Delete Read Controls

Delete Read Controls

Scope: Setup mode
Usage
DELete REad Controls primary_input_pin… | -All
Description
Removes the read control line off-state definitions from the specified primary input pins.
The Delete Read Controls command deletes the off-state definition of the read control lines
previously defined with the Add Read Controls command. You can delete the read control line
definitions for specific pins or for all pins.
Arguments
• primary_input_pin
A repeatable string that specifies a list of primary input pins from which you want to delete
any read control line off-state definitions.
• -All
A switch that specifies to delete the read control line off-state definitions for all primary
input pins.
Examples
The following example removes an incorrect read control line off-state definition, and then
creates the correct off-state for that read control line:
add clocks 0 clk
add read controls 0 r1 r2
delete read controls r1
add read controls 1 r1
set system mode dft

Related Commands
Add Read Controls Report Read Controls

126 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Scan Chains

Delete Scan Chains

Scope: Setup mode
Usage
DELete SCan Chains chain_name… | -All
Description
Removes the specified scan chain definitions from the scan chain list.
The Delete Scan Chains command deletes scan chains previously defined with the Add Scan
Chains command. You can delete the definitions of specific scan chains or of all scan chains.
When you remove a scan chain definition, it is only the definition you are removing, not the
scan chain itself. If you need to remove the scan chain itself, you can use the Ripup Scan Chains
command.
Arguments
• chain_name
A repeatable string that specifies the names of the scan chain definitions that you want to
delete.
• -All
A switch that specifies to delete all scan chain definitions.
Examples
The following example defines several scan chains, adding them to the scan chain list, then
deletes one of the scan chains:
add scan chains chain1 group1 indata2 outdata4
add scan chains chain2 group1 indata3 outdata5
add scan chains chain3 group1 indata4 outdata6
delete scan chains chain2

Related Commands
Add Scan Chains Ripup Scan Chains
Report Scan Chains

LBISTArchitect Reference Manual, v2017.3 127

September 2017
BIST-Ready Command Dictionary
Delete Scan Groups

Delete Scan Groups

Scope: Setup mode
Usage
DELete SCan Groups group_name… | -All
Description
Removes the specified scan chain group definitions from the scan chain group list.
The Delete Scan Groups command deletes scan chain groups previously defined with the Add
Scan Groups command. You can delete the definitions of specific scan chain groups or of all
scan chain groups.
When you delete a scan chain group, the tool also deletes all scan chains within the group.
Arguments
• group_name
A repeatable string that specifies the names of the scan chain group definitions that you
want to delete.
• -All
A switch that specifies to delete all the scan chain group definitions, which also
automatically causes LBISTArchitect to remove all scan chain definitions.
Examples
The following example defines two scan chain groups, adding them to the scan chain group list,
then deletes one of the scan chain groups:
add scan groups group1 scanfile1
add scan groups group2 scanfile2
delete scan groups group1

Related Commands
Add Scan Groups Report Scan Groups

128 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Scan Instances

Delete Scan Instances

Scope: All modes
Usage
DELete SCan Instances {pathname… [-INStance | -Control_signal | -Module]} | -All
Description
Removes the specified, sequential instances from the user-identified scan instance list.
The Delete Scan Instances command deletes sequential instances, instances specified by control
signals, or all instances within the specified module that were previously added to the scan
instance list by using the Add Scan Instances command. You can delete either a specific list of
instance names or all instances.
User-identified scan instances result from using the Add Scan Instances or Add Scan Models
commands. LBISTArchitect also selects the sequential instances by using the identification type
you specify with the Setup Scan Identification command (system-identified).
If you issue a Run command after removing an instance from the user-identified scan list with
the Delete Scan Instances command, LBISTArchitect then has the option of including it in the
system-identified scan instance list.
Arguments
• pathname
A repeatable string that specifies the pathnames of the instances or control signals (that
control instances) that you want LBISTArchitect to delete from the user-identified scan
instance list. The pathnames must be user-identified scan instances or control signals (that
control instances) which you previously selected with the Add Scan Instances command.
• -INStance | -Control_signal | -Module
A switch that specifies whether the pathnames are instances, pins (control signals), or
modules. An example Verilog module is “module clkgen (clk, clk_out, …)” where clkgen is
the module name. You can only use the -Control_signal option in Dft mode. The switch
default is -Instance.
• -All
A switch that specifies to delete all instances from the user-identified scan instance list. This
switch does not affect the instances in the system-identified scan instance list.
Examples
The following example deletes an extra sequential scan instance that was defined to be treated
as a scan cell; thus, the deleted instance is no longer included in the user-identified scan instance
list:
set system mode dft
add scan instances i_1006 i_1007 i_1008
delete scan instances i_1007

LBISTArchitect Reference Manual, v2017.3 129

September 2017
BIST-Ready Command Dictionary
Delete Scan Instances

Related Commands
Add Scan Instances Report Sequential Instances
Report Instance

130 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Scan Models

Delete Scan Models

Scope: All modes
Usage
DELete SCan Models model_name… | -All
Description
Removes the specified sequential models from the scan model list.
The Delete Scan Models command deletes all instances of the sequential models that you
specify. This includes removing all instances of the model_name from the user-identified scan
instance list. You can delete a specific list of sequential models or all the models.
There are two ways to identify sequential instances for scan: system and user. You can
explicitly identify scan instances with either the Add Scan Instances or the Add Scan Models
commands (user-identified). LBISTArchitect also selects the sequential instances by using the
identification type you specify with the Setup Scan Identification command (system-identified).
The Delete Scan Models command does not remove instances from the system-identified scan
instance list.
If you issue a Run command after removing a model from the user-identified scan list with the
Delete Scan Models command, LBISTArchitect then has the option of including any of the
instances of that model in the system-identified scan instance list.
To display the current scan model list use the Report Scan Models command.
Arguments
• model_name
A repeatable string that specifies the model names that you want to delete from the scan
model list and user-identified scan instance list. Enter the model names as they appear in the
DFT library.
• -All
A switch that specifies to delete all models from the scan model list and all instances from
the user-identified scan instance list.
Examples
The following example deletes an extra added sequential scan model; thus, the deleted model is
no longer included in the scan model list:
set system mode dft
add scan models d_flip_flop1 d_flip_flop2
delete scan models d_flip_flop2

Related Commands
Add Scan Instances Report Scan Models
Add Scan Models

LBISTArchitect Reference Manual, v2017.3 131

September 2017
BIST-Ready Command Dictionary
Delete Scan Pins

Delete Scan Pins

Scope: All modes
Usage
DELete SCan PIns chain_name… | -All
Description
Removes any previously-assigned scan input, output, and clock names from the specified scan
chains.
The Delete Scan Pins command removes user-specified names of the scan input and scan output
pins of the scan chains that you previously assigned with the Add Scan Pins command. You can
use the Report Scan Pins command to display all added scan input and output pin names for
each scan chain.
Arguments
• chain_name
A repeatable string that specifies the names of the scan chains from which you want
LBISTArchitect to remove the associated pins.
• -All
A switch that removes all added scan pin names from all scan chains.
Examples
The following example removes previously-assigned scan chain input and output names for
chain1:
add clocks 0 clk
set system mode dft
run
add scan pins chain1 si so
add scan pins chain2 si1 so1
delete scan pins chain1
insert test logic

Related Commands
Add Scan Pins Report Scan Pins

132 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Subchain Clocks

Delete Subchain Clocks

Scope: Setup mode
Usage
DELete SUbchain CLocks subchain_name clock_name
Description
Deletes subchain clocks previously defined with the Add Subchain Clocks command.
Arguments
• subchain_name
A required string that specifies the name of a subchain.
• clock_name
A required string that specifies the name of a subchain clock.
Examples
The following example adds, reports, and deletes a subchain clock:
add sub chains MULTIBITSFF3 chain1 SI SO 4 mux_scan S library_model
add subchain clocks chain1 0 RESET -reset
add subchain clocks chain1 0 SET -set
add subchain clocks 0 CK -first_cell_clock -leading_edge
add subchain clocks 0 CK -last_cell_clock -leading_edge
report subchain clocks chain1
// clock name type off_state edge
// ---------- ---- --------- -----
// RESET reset 0
// SET set 0
// CK first cell clock 0 leading edge
// CK last cell clock 0 leading edge

delete subchain clocks chain1 CK

report subchain clocks chain1
// clock name type off_state edge
// ---------- ----- --------- ------
// RESET reset 0
// SET set 0

Related Commands
Add Subchain Clocks Report Subchain Clocks

LBISTArchitect Reference Manual, v2017.3 133

September 2017
BIST-Ready Command Dictionary
Delete Test Points

Delete Test Points

Scope: Setup mode
Usage
DELete TEst Points {-ALL | testpoint_pin_name…} [-Full | -Control | -Observe | -Lockup]
Description
Remove the test point definitions at the specified locations.
If you do not specify -Control, -Observe, or -Lockup with either the testpoint_pin_name or the
-All option, LBISTArchitect uses the default -Full value. The -Full means that LBISTArchitect
removes all the control and observe test points, and lockup latches at the location(s) you specify.
This command removes both user-defined and system-defined test points. You can create user-
defined test points with the Add Test Points command. You can enable LBISTArchitect to
automatically identify test points by using a combination of the Setup Scan Identification, Setup
Test_point Identification, Setup Test_point Insertion, and Run commands.
Arguments
• -All
A switch that specifies to remove the control and/or observe test points from all locations.
• testpoint_pin_name
A repeatable string that specifies the locations where you want LBISTArchitect to remove
the control and/or observe test points.
• -Full
An optional switch that specifies to remove both the control and observe test points from the
locations that you specify. This is the default.
• -Control
An optional switch that specifies to remove the control test points from the locations that
you specify.
• -Observe
An optional switch that specifies to remove the observe test points from the locations that
you specify.
• -Lockup
An optional switch that specifies to remove the added lockup latch.

134 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Test Points

Examples
The following example creates the definition for three test points (one observe and two control),
and then removes two of the definitions:
add cell models and2a -type and
add test point /I_6_16/cp control and2a in2
add test point /I_7_16/q observe out1
add test point /I_8_16/cp control and2a in3
delete test points /I_6_16/cp /I_7_16/q

Note
The Delete Test Point command only specifies the testpoint_pin_names of the test points,
not the type. With this example there are two types (control and observe), which is
automatically covered by the default of -Full.

Related Commands
Add Test Points Setup Scan Identification
Insert Test Logic Setup Test_point Identification
Report Test Logic Setup Test_point Insertion
Report Test Points

LBISTArchitect Reference Manual, v2017.3 135

September 2017
BIST-Ready Command Dictionary
Delete Tied Signals

Delete Tied Signals

Scope: Setup mode
Usage
DELete TIed Signals {floating_object_name… | -All} [-Class {User | System | Full}] [-Pin]
Description
Removes the assigned (tied) value from the specified floating nets or pins.
The Delete Tied Signals command deletes the tied values that were previously assigned with the
Add Tied Signals command. You can delete tied values from either user class, system class, or
full classes of floating nets or pins. If you do not specify a class, the tool deletes the tied values
from the user class of floating nets or pins. To display a list of any class of tied floating nets or
pins, use the Report Tied Signals command.
When you remove the effects of a tied signal, LBISTArchitect reassigns the default tied signal
value to that object. The invocation default for tied objects is the unknown state (X), and you
can change that default with the Setup Tied Signals command.
Arguments
• floating_object_name
A repeatable string that specifies the names of the tied floating nets or pins whose tied
values you want to delete. The tool deletes all of the tied values associated with the floating
nets or pins in the class of tied floating nets or pins which you specify with the -Class
switch.
If you do not specify the -Pin option, the floating_object_name is assumed to be a net name.
If you specify a full net pathname, the tool deletes only the specified instance-based
blackbox tied signal. If you do specify the -Pin option, the floating_object_name is assumed
to be a pin name.
• -All
A switch that deletes the tied values from all tied floating nets or pins in the class of tied
floating nets or pins, which you specify with the -Class switch. This also includes all
instance-based blackbox tied signals.
• -Class User | System | Full
An optional switch and literal pair that specifies the class code of the tied floating nets or
pins that you specify. The valid literal names are as follows:
User — A literal that specifies that the list of tied floating nets or pins were previously
added by using the Add Tied Signals command. This is the default class.
System — A literal that specifies that the list of tied floating nets or pins are described in
the netlist.
Full — A literal that specifies that the list of tied floating nets or pins consist of both the
user and system class.

136 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Delete Tied Signals

• -Pin
An optional switch that specifies that the floating_object_name argument that you provide is
a floating pin name.
Examples
The following example deletes the tied value from the user-class tied net “vcc”; thereby leaving
“vcc” as a floating net:
add tied signals 1 vcc vdd
delete tied signals vcc -class user

Related Commands
Add Tied Signals Report Tied Signals
Setup Tied Signals

LBISTArchitect Reference Manual, v2017.3 137

September 2017
BIST-Ready Command Dictionary
Delete Write Controls

Delete Write Controls

Scope: Setup mode
Usage
DELete WRite Controls primary_input_pin… | -All
Description
Removes the RAM write control line off-state definitions from the specified primary input pins.
The Delete Write Controls command deletes write control line off-state definitions previously
defined with the Add Write Controls command. You can delete the write control line definitions
for specific pins or for all pins.
Arguments
• primary_input_pin
A repeatable string that specifies a list of primary input pins from which you want to delete
any write control line off-state definitions.
• -All
A switch that specifies to delete the write control line off-state definitions for all primary
input pins.
Examples
The following example deletes an incorrect write control line, and adds the correct off-state to
that write control line:
add write controls 0 w1 w2
delete write controls w1
add write controls 1 w1
set system mode dft

Related Commands
Add Write Controls Report Write Controls

138 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Dofile

Dofile
Scope: All modes
Usage
DOFile filename [-History]
Description
Executes the commands contained within the specified file.
The Dofile command sequentially executes the commands in a file that you specify. The Dofile
command is especially useful when you must issue a series of commands. Rather than executing
each command separately, you can place them into a file in their desired order, and then execute
them by using the Dofile command. You can also place comment lines in the file by starting the
line with a double slash (//); LBISTArchitect handles these lines as comments and ignores them.
The Dofile command sends each command expression, in order, to the tool, which, in turn,
displays each command from the file before executing it. If LBISTArchitect encounters an error
due to any command, the Dofile command stops and displays an error message. You can enable
the Dofile command to continue regardless of errors by setting the Set Dofile Abort command
to Off.
Arguments
• filename
A required string that specifies the name of the file that contains the commands which you
want LBISTArchitect to execute.
• -History
An optional switch that specifies for the tool to add the commands from a dofile to the
command line history list. By default, the commands in a dofile are not inserted into the
history list, but the Dofile command itself is added to the list.
Examples
The following example executes, all the commands from the file, command_file:
dofile command_file

The command_file may contain any application command available. An example of a

command_file is as follows:
add clocks 0 clock
set system mode dft
run

Related Commands
History Set Dofile Abort
Save History

LBISTArchitect Reference Manual, v2017.3 139

September 2017
BIST-Ready Command Dictionary
Echo

Echo
Scope: All modes
Usage
ECHo “string” [{> | >>} file_pathname]
Description
Issues a user-defined string to the transcript.
The Echo command 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 >> file redirection operator are first checked for
correctness. Syntax errors are reported to the display prior to the command’s execution.
The redirection operator does not hide these errors.

Arguments
• string
A required string. The string that you want echoed to the transcript. Double quotes are
required if the string contains spaces or special characters.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example redirects output from several commands into a single output file,
my_scan_report. The first command creates or replaces the my_scan_report file. The second
and following commands append to the same file.
echo "----------- scan cells ------------" > my_scan_report
report scan cells >> my_scan_report
echo "----------- scan chains ----------" >> my_scan_report
report scan chains >> my_scan_report

140 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Echo

Related Commands
History Report Scan Chains
Report Circuit Components Report Scan Groups
Report Dft Check Report Scan Pins
Report Drc Rules Report Sequential Instances
Report Environment Report Statistics
Report Primary Inputs Report Test Logic
Report Primary Outputs Report Test Logic
Report Scan Cells Report Test Points

LBISTArchitect Reference Manual, v2017.3 141

September 2017
BIST-Ready Command Dictionary
Exit

Exit
Scope: All modes
Usage
EXIt [-Force]
Description
Terminates the current BIST-Ready session.
The Exit command terminates the BIST-Ready phase and returns to LBISTArchitect. You
should either save the current netlist design before exiting or specify the -Force switch to not
save the netlist.
If you are operating in interactive mode (not running a dofile) and you neither saved the current
netlist nor used the -Force option, LBISTArchitect displays a warning message and you can
then continue the session and save the netlist before exiting.
Arguments
• -Force
An optional switch that explicitly specifies to not save the current netlist and terminate the
BIST-Ready session.
Examples
The following example exits BIST-Ready after performing scan chain insertion, and saving the
test procedure, dofile, and new netlist for the inserted scan chains:
add clocks 1 clk1
add clocks 0 clk0
set system mode dft
run
insert test logic
write atpg setup scan.testproc scan.do -replace
write netlist scan.v
exit

Related Commands
Write Scan Setup Write Scan Identification
Write Netlist

142 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Find Design Names

Find Design Names

Scope: All modes
Usage
FINd DEsign Names regular_expression [-LOcal | -Hier]
[-Design | -NETList | -LIbrary | -All]
[-INStance | -Net | -Pin [INPut | OUtput | INOut | ALLIn | ALLOut]
-Cell | -Module]
[{> | >>} file_pathname]
Description
Displays design object hierarchical names matched by an input regular expression, which may
include asterisk (*) or question mark (?) wildcard characters in the pathname string.
Arguments
• regular_expression
A required, regular expression, which may include asterisk (*) or question mark (?)
wildcard characters.
• -LOcal
An optional switch that matches wildcard characters within the current hierarchy level.
• -Hier
An optional switch that matches the regular expression across hierarchy boundaries (for
example, a* matches a1/b/c). This is the default.
• -Design
An optional switch that matches only pathnames to objects at the topmost library cell level.
• -NETList
An optional switch that matches objects from the top of the design down to the topmost
library cell.
• -LIbrary
An optional switch that matches objects within any level of library cells.
• -All
An optional switch that specifies matches objects at all levels of the design. This is the
default.
• -INStance
An optional switch that matches only instance pathnames. This is the default.
• -Net
An optional switch that matches only net pathnames.

LBISTArchitect Reference Manual, v2017.3 143

September 2017
BIST-Ready Command Dictionary
Find Design Names

• -Pin
An optional switch that matches only pin pathnames (any pin direction). The following
optional pin filters restrict which pins are matched:
INPut — Match only input pin pathnames.
OUtput — Match only output pin pathnames.
INOut — Match only bidirectional pin pathnames.
ALLIn — Match both input and bidirectional pin pathnames.
ALLOut — Match both output and bidirectional pin pathnames.
• -Cell
An optional switch that finds all library cell (model) names matching the specified regular
expression.
• -Module
An optional switch that finds all netlist module names matching the specified regular
expression.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following examples display object pathnames for various input wildcard expressions, given
a netlist with the following instance hierarchy:
/
tiny_i
U5
ret_i
intreg1_reg_0 ... intreg1_reg_31
add_20
U1_0 ... U1_3
add_30
U5 ... U12
mul_18
U5 ... U868
FS
U5 ... U33
mul_19
FS
U5 ... U278
U5 ... U181
mul_22
U5 ... U735
FS

144 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Find Design Names

U15 ...

and assuming the U5 instances all reference the following library cell:
model LSR2BUFA(Q, QN, S, R, G, SD, RD) (
input(S, R, G, SD, RD) ()
output(Q) (primitive = _buf UP1 (QT, Q);)
output(QN) (primitive = _buf UP2 (QNT, QN);)
intern(QT_int) (instance = LSI_LSR2 UD1 (QT_int, S, R, G, SD, RD);)
intern(QNT_int) (instance = LSI_LSR2N UD2 (QNT_int, S, R, G, SD, RD);)
intern(QT) (instance = LSI_NOTI UD3 (QT, QT_int);)
intern(QNT) (instance = LSI_NOTI UD4 (QNT, QNT_int);)
)

Example 1:
SETUP> find design names /ret_i/add_2* -instance -design -hier
// Note: Matched 4 names
/ret_i/add_20/U1_0
/ret_i/add_20/U1_1
/ret_i/add_20/U1_2
/ret_i/add_20/U1_3

Example 2:
SETUP> find design names /ret_i/add_2* -instance -netlist -hier
// Note: Matched 5 names
/ret_i/add_20
/ret_i/add_20/U1_0
/ret_i/add_20/U1_1
/ret_i/add_20/U1_2
/ret_i/add_20/U1_3

Finds instance add_20 under /ret_i/, and also descends the hierarchy to find all netlist instances
under /ret_i/add_20/.

Example 3:

SETUP> find design names /ret_i/add_2* -inst -netlist -local

// Note: Matched 1 names
/ret_i/add_20

This example shows that -Local doesn’t descend the hierarchy to find more matches as the
previous example does.

Example 4:

SETUP> find design names /ret_i/add_2* -ins -design -local

// Note: Matched 0 names

There are no instances of a library cell under /ret_i/ with instance name starting with add_2.

LBISTArchitect Reference Manual, v2017.3 145

September 2017
BIST-Ready Command Dictionary
Find Design Names

Example 5:

SETUP> find design names /ret_i/*_2? -ins -netlist -local

// Note: Matched 2 names
/ret_i/add_20
/ret_i/mul_22

Found 2 instances under /ret_i/.

Note
/ret_i/gt_68_2 did not match because the ‘?’ in the wildcard expression requires another
character after the ‘_2’.

Example 6:

SETUP> find design names */U5 -inst -design -hier

// Note: Matched 7 names
/tiny_i/U5
/ret_i/add_20/U5
/ret_i/mul_18/U5
/ret_i/mul_18/FS/U5
/ret_i/mul_19/U5
/ret_i/mul_19/FS/U5
/ret_i/mul_22/U5

Example 7:

SETUP> find design names ret_i/mul*/U5 -ins -des -local

// Note: Matched 3 names
/ret_i/mul_18/U5
/ret_i/mul_19/U5
/ret_i/mul_22/U5

Example 8:

SETUP> find design names ret_i/mul*/U5 -ins -design -hier

// Note: Matched 5 names
/ret_i/mul_18/U5
/ret_i/mul_18/FS/U5
/ret_i/mul_19/U5
/ret_i/mul_19/FS/U5
/ret_i/mul_22/U5

Example 9:

SETUP> find design names ret_i/mul_18/U5* -ins -library -hier

// Note: Matched 5 names
/ret_i/mul_18/U5
/ret_i/mul_18/U5/UD1
/ret_i/mul_18/U5/UD2

146 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Find Design Names

/ret_i/mul_18/U5/UD3
/ret_i/mul_18/U5/UD4

Example 10:

SETUP> find design names ret_i/mul*/U5/* -pin output -design -local

// Note: Matched 6 names
/ret_i/mul_18/U5/Q
/ret_i/mul_18/U5/QN
/ret_i/mul_19/U5/Q
/ret_i/mul_19/U5/QN
/ret_i/mul_22/U5/Q
/ret_i/mul_22/U5/QN

LBISTArchitect Reference Manual, v2017.3 147

September 2017
BIST-Ready Command Dictionary
Help

Help
Scope: All modes
Usage
HELp [command_name] [-MANual]
Description
Displays the usage syntax and system mode for the specified command.
The Help command displays useful information for a selected command. You can display the
usage and syntax of a command by typing Help and the command name. If you only type Help,
LBISTArchitect displays all of the commands. 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 consists of any keyword or BIST-Ready phase command. You can
use minimum typing for the command name.
• -MANual
An optional string that specifies to also display the reference manual description for the
specified command.
If you type HELp and include only the -MANual switch, the tool opens the product
bookcase, giving access to all the manuals for that product group.
Examples
The following example displays the usage and system mode for the Report Primary Inputs
command:
help report primary inputs
// Report primary inputs
// usage: REPort PRimary Inputs [-Class <User|System|Full>]
[-All | pin_pathname...]
// legal system modes: ALL

148 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
History

History
Scope: All modes
Usage
HIStory [list_count] [-Nonumbers] [-Reverse]
Description
Displays a list of previously-executed commands.
The History 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.
Each command line in the history list is preceded by a leading number indicating 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 recently 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.
Examples
The following command displays the history list with leading numbers, starting with the oldest
command.
history
1 help hist
2 dof fault.do

LBISTArchitect Reference Manual, v2017.3 149

September 2017
BIST-Ready Command Dictionary
History

3 analyze fault /I$20/en -stuck_at 1

4 set system mode setup
5 set system mode fault
6 add faults -all
7 run
8 report statistics
9 history

Related Commands
Save History

150 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Insert Test Logic

Insert Test Logic

Scope: Dft mode
Prerequisites
To use the -Verilog switch, you must have defined a buffer model with the Add Cell Model
command or with a cell_type attribute.
Usage
INSert TEst Logic [filename [-Fixed]] [-Scan {ON | OFf}] [-Test_point {ON | OFf}]
[-Ram {ON | OFf}] {[-NOlimit] | [-Max_length integer] | [-NUmber [integer]]}
[-Clock {Nomerge | Merge}] [-Edge {Nomerge | Merge}] [-COnnect {ON | OFf | Tied |
Loop | Buffer}] [-Output {Share | New}] [-MOdule {Norename | Rename}] [-Verilog]
[-Hierarchical {OFf | [ON -Tolerance integer_percent]}]
Description
Inserts the test structures that you define into the netlist to increase the design’s testability.
There are several ways that LBISTArchitect can aid in increasing a design’s fault coverage. The
major purpose of the BIST-Ready phase is to identify sequential cells that LBISTArchitect can
replace with the corresponding scan cells.
In addition to scan cell replacement, the BIST-Ready phase can also perform two other tasks
that can increase the design’s testability. LBISTArchitect supports the adding of test points
(both system-defined and user-defined), and it supports the automatic adding of test logic. For
more information on scan replacement, test points, and test logic, refer to the Scan and ATPG
User’s Manual.
The default behavior is to partition the scan cells over the scan chains without considering the
hierarchical distribution of the sub-modules in the circuit. This is called flat partitioning and it
may cause different instances of a sub-module to have a different number of scan chains. As a
result, when the final scan inserted netlist is written out, LBISTArchitect generates unique
module definitions for the different instances of the same sub-module.
To decrease, or prevent, the “uniquification” of module definitions that originate from flat scan
cell partitioning, turn on the -Hierarchical switch. Hierarchical partitioning is not deployed
when the “filename [-Fixed]” option is used. Hierarchical partitioning is recommended over flat
partitioning unless the circuit has previously inserted chains and/or test points. These previously
inserted elements can have an arbitrary distribution in the circuit and can therefore cause
uniquification of modules
There could be reasons to use flat partitioning, depending on your design. For instance, flat
partitioning places cells that have direct access to primary outputs at the end of the chains. This
can reduce the number of scan output pins that LBISTArchitect creates.
Hierarchical partitioning can cause an increased number of scan inputs and outputs for the sub-
modules, which could be an issue for your design. If this is the case, use the -Tolerance switch.
Specifying an integer percentage of tolerance allows the tool to create chain lengths shorter or

LBISTArchitect Reference Manual, v2017.3 151

September 2017
BIST-Ready Command Dictionary
Insert Test Logic

longer than their ideal length (total number of cells divided by the specified number of chains),
which can reduce the number of chains per sub-module, and, thus, the interconnections between
sub-modules.
One possible result of using a tolerance other than 0 is a variation of the number of scan chains
at the top level. The differences from the ideal length for each chain accumulate at the last chain
during the insertion process. A specified high tolerance can cause the removal or the unwanted
lengthening of the last chain. To see the before and after effect of the -Tolerance option, use the
Report Scan Chains command.
Arguments
• filename -Fixed
An optional string and associated optional switch that specifies the name of the ASCII file
that lists the scan instances that you want LBISTArchitect to stitch together. This file can
contain information regarding scan cell ordering along with which instances are to be in
each scan chain.
Note
If you use this file, it must contain all instances you want stitched. If you do not specify a
filename, LBISTArchitect stitches all non-scan cells that it has identified and mapped to
scan cells into a scan chain using the settings of the other Insert Test Logic arguments.

The -Fixed switch specifies for LBISTArchitect to stitch the scan instances in the fixed
order that is given in the filename The default scan cell ordering is based on hierarchical
rules, but within a hierarchical block the scan cell ordering is random. When using the -
Fixed option, it also ignores certain scan input/output mapping performed by the Add Scan
Pins command.
Note
If a fixed order file is used, the -Fixed switch is required in conjunction with the scan
instances filename.

152 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Insert Test Logic

The filename that you specify must list one instance per line and use the following format
(all on one line):
instance_pathname cell_id chain_id [&sub_chain_name]
[{+|-}[lockup_latch_model]]
instance_pathname — A string that specifies the name of the non-scan cell that you
want the tool to put in the scan chain.
cell_id — An integer that specifies the placement of the instance_pathname in relation
to other instance_pathnames. LBISTArchitect places the instance having the smallest
cell_id closest to the scan chain output. All instances in the same chain must have
unique cell_ids.
chain_id — An integer that specifies the scan chain in which you want the tool to place
the instance_pathname. LBISTArchitect places instances with the same chain_id in
the same chain.
&sub_chain_name — An optional special character and string that specifies the name of
the sub-scan chain you defined with the Add Test Points command. You need to
specify the sub-chain name when more than one sub-chain is defined for a sub-
module or a hierarchical instance. No space is allowed between the ampersand (&)
and the sub_chain_name argument.
{+|-}[lockup_latch_model] — An optional special character and an additional optional
string that specifies the location of the lockup latch. The +|- argument specifies that a
lockup latch is to be added to the scan out of the current instance_pathname. No
space is allowed between the +|- and the lockup_latch_model name. Note that if you
define a lockup latch in this file, you must specify every location that you want to
insert lockup latches. If the file contains no lockup latch definitions, LBISTArchitect
uses the settings in the Set Lockup Latch command.
+ — Specifies to use the clock that the instance_pathname with the next lower
cell_id uses. The next lower cell_id refers to the nonscan cell which will be
connected to the scan out of the current instance_pathname.
- — Specifies to use the clock that the instance_pathname uses.
lockup_latch_model — Specifies the name of the lockup latch model to use. You
must define the specified lockup latch with the Add Cell Models command or
define it in the DFT library, using the cell_type attribute. If you do not specify the
lockup_latch_model, the tool uses the first model in the defined latch model.
• -Scan ON | OFf
An optional switch and literal pair that specifies to replace the identified non-scan cells
(scan candidates) with the corresponding scan cells. The valid literals are as follows:
ON — A literal that enables the tool to replace the identified non-scan cells (scan
candidates) with the corresponding scan cells. This is the default.
OFf — A literal that disables the tool from replacing the identified non-scan cells (scan
candidates) with the corresponding scan cells.

LBISTArchitect Reference Manual, v2017.3 153

September 2017
BIST-Ready Command Dictionary
Insert Test Logic

• -Test_point ON | OFf
An optional switch and literal pair that specifies whether the tool adds the identified test
logic and test points into the design. The valid literals are as follows:
ON — A literal that enables the tool to add the identified test logic and test points into
the design. This is the default.
OFf — A literal that disables the tool from adding the identified test logic and test points
into the design.
• -Ram ON | OFf
An optional switch and literal pair that specifies whether the tool adds the identified test
logic gates that are necessary to allow the ATPG tools access to the write control lines of the
RAMs. The valid literals are as follows:
ON — A literal that enables the tool to add the identified test logic gates for RAM write
control line access. This is the default.
OFf — A literal that disables the tool from adding the identified test logic gates for
RAM write control line access.
• -NOlimit
An optional switch specifying that the scan chain has no limit on the number of scan cells it
contains. This is the default.
• -Max_length integer
An optional switch and integer pair that specifies the maximum number of scan cells that
LBISTArchitect can stitch into a scan chain. LBISTArchitect evenly divides the scan cells
into scan chains that are smaller than the max_length integer. Final results depend upon the
number of scan candidates.
• -NUmber integer
An optional switch and integer pair that specifies the exact number of scan chains that you
want the tool to insert. Final results depend upon the number of scan candidates. The default
number of chains is 1.
• -Clock Nomerge | Merge
An optional switch and literal pair that specifies whether to use different clocks on the same
scan chain. The two valid literals are:
Nomerge — A literal that specifies to not use different clocks on the same scan chain.
This is the default.
Merge — A literal that specifies to use different clocks on the same scan chain.
• -Edge Nomerge | Merge
An optional switch and literal pair that specifies whether to merge stable high chains into
stable low chains. The two valid literals are:
Nomerge — A literal that specifies to not merge stable high chains into stable low
chains. This is the default.

154 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Insert Test Logic

Merge — A literal that specifies to merge stable high chains into stable low chains.
• -COnnect ON | OFf | Tied | Loop | Buffer
An optional switch and literal pair that specifies whether LBISTArchitect stitches the scan
cells together into a scan chain. The valid literals for stitching the scan chain are:
ON — A literal that specifies to replace the identified non-scan cells with their
corresponding scan replacements and to stitch those scan cells together into a scan
chain. This is the default.
OFf — A literal that specifies to replace the identified non-scan cells with their
corresponding scan replacements, but not stitch those scan cells together into scan
chains.
Tied — A literal that specifies to replace the identified non-scan cells with their
corresponding scan replacements, but not stitch those scan cells together into scan
chains. This option has LBISTArchitect tie the input/output scan pins to ground.
Loop — A literal that specifies to replace the identified non-scan cells with their
corresponding scan replacements, but not stitch those scan cells together into scan
chains. This option has LBISTArchitect connect the scan_out pin to its own scan_in
pin as a self-loop.
Buffer — A literal that specifies to replace the identified non-scan cells with their
corresponding scan replacements, but not stitch those scan cells together into scan
chains. This option has LBISTArchitect connect the scan_out pin to its own scan_in
pin as a self-loop with a buffer in between.
• -Output Share | New
An optional switch and literal pair that specifies how LBISTArchitect creates scan out ports
on submodules. The valid literals are:
Share — A literal that specifies to use an existing module output port on submodules for
scan out, if that port is directly connected to the scan out of a scan cell. This is the
default.
New — A literal that specifies to always create a new output port for scan out.
• -MOdule Norename | Rename
An optional switch and literal pair that specifies how to name the modified module. The
valid literals are:
Norename — A literal that specifies to use the original module name, if LBISTArchitect
uses only one type of module modification, and to no longer use the original module
in the design. This is the default.
Rename — A literal that specifies that LBISTArchitect should always rename a module
if it modifies the module.
• -Verilog
An optional switch that specifies that the final output netlist format will be Verilog.
LBISTArchitect will insert a buffer instance for the scan output pin of a lower level module
in the design hierarchy, when this pin also fans out as the module’s functional output.

LBISTArchitect Reference Manual, v2017.3 155

September 2017
BIST-Ready Command Dictionary
Insert Test Logic

Without this switch, LBISTArchitect uses the Verilog ‘assign’ statement to generate this
scan output signal from the functional output. However, some layout tools do not support
the Verilog assign statement, so the -Verilog switch is required for LBISTArchitect to
replace the assign statement with a buffer instantiation and avoid using the assign statement.
Before using this command and switch, you must have defined a buffer model with the Add
Cell Model command or with a cell_type attribute.
• -Hierarchical {OFf | ON [-Tolerance integer_percent]}
An optional switch and literal pair, with an associated optional switch and integer pair, that
specify whether DFTAdvisor tries to insert the same scan chain segments into the identical
sub-module instances in the design. DFTAdvisor considers the entire design hierarchy when
performing the segmentation and therefore this functionality can be referred to as
hierarchical scan chain segmentation. Having the same scan segments on the identical sub-
module instances allows them to share the same scan-inserted module definition in the scan-
inserted netlist which may yield a reduced netlist size. An allowable percentage variation
from the ideal chain length (tolerance) helps in reaching this goal. The valid arguments are
as follows:
OFf — A literal that specifies to not consider hierarchical scan chain segmentation. This
is the invocation default.
ON — A literal that specifies for DFTAdvisor to perform hierarchical scan chain
segmentation. The tool tries to insert the same scan chain segments into identical sub-
module instances in the design, so that the instances share the same scan-inserted
module definition when the tool generates the scan-inserted netlist. The -Tolerance
switch and integer pair can optionally be specified with this option.
-Tolerance integer_percent — A switch and integer pair that specifies the
percentage deviation that DFTAdvisor can vary from the ideal chain length when
creating the scan chains. A non-zero percentage allows DFTAdvisor to vary the
chain lengths (shorter or longer), which helps in segmenting scan chains for the
identical sub-modules in the design. However, this may also result in fewer than
specified number of scan chains. This switch is optionally used when -
Hierarchical is set to ON.
integer_percent — An integer percentage. The default value is 0, which causes
DFTAdvisor to create chains with the ideal length.
Examples
The following example identifies the scannable sequential instances during the Run command,
and then uses the Insert Test Logic command to stitch them together into scan chains with a
maximum length of 10 scan cells each:
add clocks 0 clock
set system mode dft
setup scan identification full_scan
run
insert test logic -scan on -max_length 10

156 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Insert Test Logic

The following example causes the insertion of three scan chains using hierarchical partitioning
with a 5percent tolerance:
insert test logic -clock merge -edge merge -number 3 -hierarchy on -tolerance 5

Related Commands
Add Scan Instances Setup Scan Identification
Add Scan Pins Setup Scan Insertion
Add Test Points Setup Test_point Identification
Report Scan Chains Setup Test_point Insertion
Set Test Logic Synthesize

LBISTArchitect Reference Manual, v2017.3 157

September 2017
BIST-Ready Command Dictionary
Load Static_timing Report

Load Static_timing Report

Scope: Dft mode
Usage
LOAd STatic_timing Report filename [{-Primetime [-Clock clk_report_file]} | -Fastscan_cpa]
Definition
Reads in a specified path file that contains critical-path locations for exclusion from MTPI test
point insertion.
When you issue this command in a session that inserts MTPI test points (in which the
command, Setup Test_point Identification, is present), LBISTArchitect assumes all paths in the
report represent critical paths. The tool treats all nodes along all the paths in the report file as
notest point locations. The default for this report file is PrimeTime® format. The following is an
example of a PrimeTime command that would produce such a report:
report_timing -nosplit -slack_less 1.5 -max_path 200000 > core_sta.rep

When you issue this command in a subsequent session that restores and selectively deletes
MTPI test points, LBISTArchitect assumes all paths in the report contain test points that violate
critical timing and will automatically remove the offending test points.
Arguments
• filename
A required string that specifies the name of the timing report file that LBISTArchitect uses
for test point analysis.
• -Primetime
An optional switch that specifies that filename is in PrimeTime format. This is the default.
• -Clock clk_report_file
An optional switch and string pair that specifies to read the netlist clock information (clock
periods and duty cycles) from the PrimeTime-formatted file, clk_report_file. This file would
have been generated using the PrimeTime command, report_clock.
• -Fastscan_cpa
An optional switch that specifies that filename is in Tessent FastScan™ CPA format.
Examples
The following example causes the BIST-Ready phase of LBISTArchitect to read in a critical-
path report file, m8051_sta.rep, in PrimeTime format, as well as the netlist clock report file,
m8051_clk.rep, also in PrimeTime format:
load static_timing report m8051_sta.rep -primetime -clock m8051_clk.rep

158 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Load Static_timing Report

An example of the PrimeTime path_file is:

****************************************
Report : timing
-path full
-delay max
-slack_lesser_than 0.00
-max_paths 200000
Design : m8051
Version: 2000.11
Date : Tue Sep 11 10:09:09 2001
****************************************

Startpoint: LDLM_reg (rising edge-triggered flip-flop clocked by NX1)

Endpoint: u1/SMA_reg (rising edge-triggered flip-flop clocked by NX1)
Path Group: NX1
Path Type: max

Point Incr Path

-----------------------------------------------------------
clock NX1 (rise edge) 0.00 0.00
clock network delay (ideal) 0.00 0.00
LDLM_reg/CP (FD1SQC) 0.00 0.00 r
LDLM_reg/Q (FD1SQC) 0.42 0.42 f
xbnd53/Z (MUX21HA) 0.27 0.69 f
uu1/Z (N1A) 22.85 23.55 r
u1/scan_eninv (m3s001bo) 0.00 23.55 r
u1/SMA_reg/TE (FD2SL2QA) 0.00 23.55 r
data arrival time 23.55

clock NX1 (rise edge) 6.00 6.00

clock network delay (ideal) 0.00 6.00
u1/SMA_reg/CP (FD2SL2QA) 6.00 r
library setup time -5.00 1.00
data required time 1.00
-----------------------------------------------------------
data required time 1.00
data arrival time -23.55
-----------------------------------------------------------
slack (VIOLATED) -22.54

An example of the clock report file is:

****************************************
Report : clock
Design : m8051
Version: 2000.11
Date : Tue Sep 11 10:09:06 2001
****************************************

Attributes:
p - propagated_clock
G - Generated clock

Clock Period Waveform Attrs Sources

-------------------------------------------------------------
NX1 6.00 {0 3} {NX1}
NX2 12.00 {0 6} {NX2}

LBISTArchitect Reference Manual, v2017.3 159

September 2017
BIST-Ready Command Dictionary
Load Static_timing Report

Related Commands
Archive Test_points Restore Test_points
Delete MTPI Control_point Delete MTPI Observe_point
Write Static_timing Setup Set Clock Period

Command Summary

160 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Printenv

Printenv
Scope: All modes
Usage
PRIntenv
Description
Prints out the values of the UNIX variables in the environment.
The Printenv command makes the UNIX printenv command available as a common DFT
command for convenience in displaying UNIX environment variables. UNIX environment
variables are automatically available as variable references within LBISTArchitect.
For information on how to define, reference, and report on a variable’s value, see the Report
Variables command.
Examples
The following example prints out the values of the UNIX variables in the environment:
printenv

Related Commands
Report Variables

LBISTArchitect Reference Manual, v2017.3 161

September 2017
BIST-Ready Command Dictionary
Read Procfile

Read Procfile
Scope: All modes except Setup mode
Usage
REAd PRocfile proc_filename
Description
Reads the specified test procedure file.
The Read Procfile command reads the test procedure file specified by the proc_filename
argument. LBISTArchitect merges the procedure and timing data contained in the file with the
existing data loaded from previously loaded test procedure files. The information loaded with
this command is used by the Write Atpg Setup command.
Arguments
• proc_filename
A required string that specifies the path and filename of the test procedure file to read.
Example 1
The following example reads the test procedure file my_file.proc:
read procfile my_file.proc

Example 2
In the following example, the test procedure file orig.proc defines a simple timeplate as well as
a shift, load_unload, and named capture procedure cap1. The example reads in the procedure
file, then lists the current timeplates and procedures stored in the tool’s database (for brevity,
only the parts of the timeplates and procedures relevant to this example are shown):
add scan groups grp1 orig.proc
set system mode atpg
report timeplate

timeplate gen_tp1 =
...
end;

report procedure

procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
...
end;

procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
...
end;

162 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Read Procfile

procedure capture cap1 =

timeplate gen_tp1 ;
...
end;

Example 3
Assume a second test procedure file update.proc defines a new timeplate in addition to the
original one, revises the shift procedure to use the new timeplate, and defines a new named
capture procedure cap2. The following example adds the new timeplate, updates the timing in
the scan procedures, and adds the new named capture procedure. (The timeplate and procedure
changes resulting from the Read Procfile command are highlighted in bold in the output of the
reporting commands.)
read procfile update.proc
// The following occurred at line 46 in file update.proc:
// Procedure shift updates timing in same procedure from file orig.proc.
// (W14)
// Loaded new procedure file successfully.
// 1 new capture procedure is added.
// 2 total capture procedures are in the system.
// 2 capture procedures are active for test generation.

report timeplate
timeplate gen_tp1 =
...
end;

// Timeplate gen_tp1 has an old timeplate

// timeplate gen_tp1 =
// ...
// end;

timeplate gen_tp2 =
...
end;

report procedure
procedure shift =
scan_group grp1 ;
timeplate gen_tp2 ;
...
end;

procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
...
end;

procedure capture cap1 =

timeplate gen_tp1 ;
...
end;

LBISTArchitect Reference Manual, v2017.3 163

September 2017
BIST-Ready Command Dictionary
Read Procfile

procedure capture cap2 =

timeplate gen_tp2 ;
...
end;

If the Read Procfile command of the preceding example had included the -Replace switch, the
original NCP would have been replaced with the new one:
read procfile update.proc -replace
// The following occurred at line 46 in file update.proc:
// Procedure shift updates timing in same procedure from file orig.proc.
(W14)
// Loaded new procedure file successfully.
// 1 new capture procedure is added.
// 1 total capture procedure is in the system.
// 1 capture procedure is active for test generation.

report procedure
procedure shift =
scan_group grp1 ;
timeplate gen_tp2 ;
...
end;

procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
...
end;

procedure capture cap2 =

timeplate gen_tp2 ;
...
end;

Related Commands
Add Scan Groups Write Procfile
Report Timeplate

164 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report BIST Bounding

Report BIST Bounding

Scope: All modes
Usage
REPort BIst Bounding
Description
Displays bounding settings and lists any excluded input pins.
Examples
The following example turns on X bounding, performs bounding by tieing to a constrained
value, and then displays the bounding settings.
setup x_bounding -connect_to power_or_ground
report bist bounding
// X bounding: On
// X bounding method: Tie to constant value
// Scan drive limit: No limit
// Pin constraint synthesis: Off
// Verbose: Off
// Control pin: lbist_en

Related Commands
Setup X_bounding

Command Summary

LBISTArchitect Reference Manual, v2017.3 165

September 2017
BIST-Ready Command Dictionary
Report Black Box

Report Black Box

Scope: All modes
Usage
REPort BLack Box -Instance [ins_pathname] | -Module [module_name] | -All | -Undefined
Description
Displays information on blackboxes and undefined models.
The Report Black Box command reports on the status of any instance- or module-based
blackboxes, or undefined models that are not yet blackboxed. The report follows the following
format.
MODULE: module_name (default tie value = 0|1|X|Z)
SYSTEM: Inout|Output pin pin_name tied to 0|1|X|Z
USER: Inout|Output pin pin_name tied to 0|1|X|Z
INSTANCE: ins_name (default tie value = 0|1|X|Z)
SYSTEM: Inout|Output pin pin_name tied to 0|1|X|Z
USER: Inout|Output pin pin_name tied to 0|1|X|Z

For module-based blackboxes, the tool displays the string MODULE followed by the name of
the module and the default tie value (0, 1, X, or Z). The tool then displays a list of module pins.
For each pin, the tool displays either SYSTEM or USER followed by the direction type of the
pin (Inout or Output), the name of the pin, and its tied value. SYSTEM declares that the pin is
tied to the default value, by the system, while USER declares that you explicitly tied the pin to
the specified value.
For instance-based blackboxes, the report replaces the string MODULE with INSTANCE to
explicitly declare that it is an instance-based blackbox.
Arguments
• -Instance [ins_name]
A switch and optional string that specify for the tool to display information on instance-
based blackboxes. If you do not supply an ins_name, LBISTArchitect displays information
on all instance-based blackboxes. If you specify an instance pathname, it reports on that
single, instance-based blackbox.
• -Module [module_name]
A switch and optional string that specify for the tool to display information on module-
based blackboxes. If you do not supply a module_name, LBISTArchitect displays
information on all module-based blackboxes. If you specify a module_name, it reports on
that single, module-based blackbox.
• -All
A switch that specifies for the tool to display information on both defined blackboxes and
undefined models. This is the default.

166 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Black Box

• -Undefined
A switch that specifies for the tool to display information on undefined models which have
not yet been blackboxed. Use this switch to determine whether your design is complete, or is
missing library models. If you intend to blackbox undefined models, this report allows you
to verify that only the intended models are undefined.
Examples
The following example defines module- and instance- based blackboxes, then reports on them.
add black box -module core -pin do1 0 -pin io1 1
add black box -instance core1 1 -pin do0 0 -pin io0 0
report black box -all
MODULE: core (default tie value = X)
SYSTEM: Output pin do0 tied to X
USER: Output pin do1 tied to 0
SYSTEM: Inout pin io0 tied to X
USER: Inout pin io1 tied to 1
INSTANCE: core1 (default tie value = 1)
USER: Output pin do0 tied to 0
SYSTEM: Output pin do1 tied to 1
USER: Inout pin io0 tied to 0
SYSTEM: Inout pin io1 tied to 1

Related Commands
Add Black Box Report Tied Signals
Delete Black Box

LBISTArchitect Reference Manual, v2017.3 167

September 2017
BIST-Ready Command Dictionary
Report Buffer Insertion

Report Buffer Insertion

Scope: All modes
Usage
REPort BUffer Insertion
Description
Displays a list of all the different scan test pins and the corresponding fanout limit.
The Report Buffer Insertion command shows either the default setting (infinity) for each type of
scan test pin or the new limit you set with the Add Buffer Insertion command.
Examples
The following example changes the fanout limit with the Add Buffer Insertion command, then
reports the new setting; all the remaining settings are left at the default (infinity):
add buffer insertion 7 sen -model buf1a
report buffer insertion
scan_enable 7 buf1a
scan_clock <infinity>
test_enable <infinity>
test_clock <infinity>
scan_master_clock <infinity>
scan_slave_clock <infinity>
hold_enable <infinity>

Related Commands
Add Buffer Insertion Delete Buffer Insertion

168 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Cell Models

Report Cell Models

Scope: All modes
Usage
REPort CEll Models [-All | {-Type cell_model_type}]
Description
Displays a list of either all cell models or the DFT library models associated with the specified
cell type.
The Report Cell Models command displays the cell models that you either added with the Add
Cell Models command, or described in the DFT library with the cell_type attribute.
Arguments
• -All
An optional switch that specifies to display all cell model definitions that you added with the
Add Cell Models command. This is the default.
• -Type cell_model_type
An optional switch and literal pair that specifies to display a listing of all the cell models of
a particular type. The valid cell_model_types are as follows (with the minimum typing
characters shown in uppercase):
INV — A literal that specifies a one-input inverter gate.
And — A literal that specifies a two-input AND gate.
Buf — A literal that specifies a one-input buffer gate.
OR — A literal that specifies a two-input OR gate.
NAnd — A literal that specifies a two-input NAND gate.
NOr — A literal that specifies a two-input NOR gate.
Xor — A literal that specifies an exclusive OR gate.
INBuf — A literal that specifies a primary input buffer gate that LBISTArchitect
inserted whenever the tool added new input pins (such as the scan input or scan
enable pins).
OUtbuf — A literal that specifies a primary output buffer gate that LBISTArchitect
inserted whenever the tool added new output pins (such as the scan output pin).
Mux — A literal that specifies a 2-1 multiplexer.
Scancell — A literal that specifies a cell with four input pins (clock, data, scan in, and
scan enable), clocked scan cell with four inputs (clock, data, scan clock, and scan
enable), or LSSD scan cell with five inputs (clock, data, scan in, master clock, and
slave clock).
DFf — A literal that specifies a D flip-flop with two input pins (clock and data).

LBISTArchitect Reference Manual, v2017.3 169

September 2017
BIST-Ready Command Dictionary
Report Cell Models

DLat — A literal that specifies a D latch with two input pins (enable and data).
Examples
The following example displays a list of all added cell models:
report cell models

Related Commands
Add Cell Models Set Test Logic
Delete Cell Models

170 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Circuit Components

Report Circuit Components

Scope: All modes
Usage
REPort CIrcuit Components
{[-INStances] {[-INDent | -Noindent] [-Level integer]}} | [-Modules]
[{> | >>} file_pathname]
Description
Displays information about the components of the circuit as either modules or instances.
Note
Report Circuit Components reports only on components in the circuit; it does not report
on library components.

When you use the -Instances switch, the command prints out instance names, module names,
and the level of hierarchy at which they exist. The default formatting is Indent. Note that the
tool prints the string -top- as the name for the top-level instance.
When you use the -Modules switch, the command prints out the module names and the number
of instantiations of each module.
Arguments
• -INStances [-INDent | -Noindent] [-Level integer]
An optional switch with an optional switch and an optional switch and integer pair that
specify to report on the module instances in the design, based on the design hierarchy. This
is the invocation default.
-INDent — An optional switch that specifies to print the report using code-like
indention. This switch works only with the -Instances switch. -Indent is the default.
-Noindent — An optional switch that specifies to print the report without using
indention. This switch works only with the -Instances switch.
-Level — An optional switch and integer pair that specifies to filter the printing based on
the hierarchy level specified by integer. This switch works only with the -Instances
switch.
integer — An optional integer that specifies the hierarchy level at which you want
the report to start. The report will show all instances whose level number is
greater than integer, that is, levels that are at or lower in the hierarchy than
integer. The default value for integer is 0, the top level.
• -Modules
An optional switch that specifies to report on the modules, listing their names and the
number of instantiations of each module in the design.

LBISTArchitect Reference Manual, v2017.3 171

September 2017
BIST-Ready Command Dictionary
Report Circuit Components

• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays a circuit component report, in indented format, of instances at
and below level 0 in the hierarchy:
report circuit components
------------------------------------------------------------
Output Format: InstanceName (ModuleName) [HierarchyLevel]
------------------------------------------------------------
-top- (m8051) [0]
u10(m3s018bo) [1]
u11(m3s019bo) [1]
u5 (m3s006bo) [1]
u4 (m3s005bo) [1]
u3 (m3s004bo) [1]
u14 (m3s025bo) [1]
u13 (m3s023bo) [1]
u9 (m3s015bo) [1]
u4 (m3s016bo) [2]
u3 (m3s016bo) [2]
u2 (m3s016bo) [2]
u1 (m3s016bo) [2]
u12 (m3s020bo) [1]
u1 (m3s014bo) [2]
u7 (m3s008bo) [1]
u2 (m3s039bo) [2]
u1 (m3s009bo) [2]
u6 (m3s007bo) [1]
u2 (m3s003bo) [1]
u15 (m3s028bo) [1]
u8 (m3s010bo) [1]
select_program_source_gt_301 (m3s010bo_DW01_cmp2_8_0) [2]
u2 (m3s013bo) [2]
u1 (m3s011bo) [2]
u1 (m3s001bo) [1]

The following example displays a circuit component report, in non-indented format, of

instances at and below level 1 in the hierarchy:
report circuit components -instance -noindent -level 1
------------------------------------------------------------
Output Format: InstanceName (ModuleName) [HierarchyLevel]
------------------------------------------------------------
u10 (m3s018bo) [1]
u11 (m3s019bo) [1]
u5 (m3s006bo) [1]

172 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Circuit Components

u4 (m3s005bo) [1]
u3 (m3s004bo) [1]
u14 (m3s025bo) [1]
u13 (m3s023bo) [1]
u9 (m3s015bo) [1]
u4 (m3s016bo) [2]
u3 (m3s016bo) [2]
u2 (m3s016bo) [2]
u1 (m3s016bo) [2]
u12 (m3s020bo) [1]
u1 (m3s014bo) [2]
u7 (m3s008bo) [1]
u2 (m3s039bo) [2]
u1 (m3s009bo) [2]
u6 (m3s007bo) [1]
u2 (m3s003bo) [1]
u15 (m3s028bo) [1]
u8 (m3s010bo) [1]
select_program_source_gt_301 (m3s010bo_DW01_cmp2_8_0) [2]
u2 (m3s013bo) [2]
u1 (m3s011bo) [2]
u1 (m3s001bo) [1]

The following example displays a circuit component report of the design’s modules, and the
number of instantiations of each:
report circuit components -module
----------------------------------------------------
Output Format: ModuleName [NumberOfinstantiations]
----------------------------------------------------
m8051 [0]
m3s028bo [1]
m3s025bo [1]
m3s023bo [1]
m3s020bo [1]
m3s014bo [1]
m3s019bo [1]
m3s018bo [1]
m3s015bo [1]
m3s016bo [4]
m3s010bo [1]
m3s010bo_DW01_cmp2_8_0 [1]
m3s013bo [1]
m3s011bo [1]
m3s008bo [1]
m3s039bo [1]
m3s009bo [1]
m3s007bo [1]
m3s006bo [1]
m3s005bo [1]
m3s004bo [1]
m3s003bo [1]
m3s001bo [1]

LBISTArchitect Reference Manual, v2017.3 173

September 2017
BIST-Ready Command Dictionary
Report Clock Groups

Report Clock Groups

Scope: Dft mode
Usage
REPort CLock Groups
Description
Displays a list of all clock group definitions.
The Report Clock Groups command displays a list of all clock groups added with the Add
Clock Groups command.
Examples
The following example displays a list of clock groups after they have been added to the clock
list:
add clocks 1 clk1 clk2
add clocks 0 clr1 clr2 pre1 pre2
set system mode dft
…
add clock groups group1 clk1 clr1 pre1
add clock groups group2 clk2 clr2 pre2
report clock groups
group2: clk2 clr2 pre2
group1: clk1 clr1 pre1
all_clocks: clk3

Related Commands
Add Clock Groups Delete Clock Groups

174 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Clocks

Report Clocks
Scope: All modes
Usage
REPort CLocks [-Display {DEBug | DESign | DAta | ALl}]
Description
Displays a list of all clock definitions.
The Report Clocks command displays a list of all clocks added with the Add Clocks command.
Arguments
• -Display {DEBug | DESign | DAta | ALl}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DEBug — Debug window
DESign — Design window
DAta — Data window
ALl— A literal that displays the information in all of the preceding windows.
Examples
The following example displays a list of clocks after they have been added to the clock list:
add clocks 1 clk1
add clocks 0 clk0
report clocks
clk1, off_state 1
clk0, off_state 0

Related Commands
Add Clocks Delete Clocks

LBISTArchitect Reference Manual, v2017.3 175

September 2017
BIST-Ready Command Dictionary
Report Configuration_data Commands

Report Configuration_data Commands

Scope: All modes
Usage
REPort COnfiguration_data Commands
Description
Displays a list of the commands that the tool executes upon startup based on the available
configuration data file for that design.
LBISTArchitect uses binary configuration data files (metadata) to pass the necessary
information between the different invocation phases of the tool. The Bist-Ready and Bist-
Controller Generation phases both read a configuration data file at invocation and also execute
the commands associated with that file. This report lists the commands associated with that
configuration data file.
Example
The following example displays a brief sampling of commands that you might see in on of these
report commands.
report configuration_data commands
//
// Generated by LBISTArchitect (BIST-Ready
//
add scan groups grp1 .lbist_auto_scan_setup.testproc
add scan chains chain1 grp1 scan_in1 scan_out1
add scan chains chain2 grp1 scan_in2 scan_out2
add scan chains chain3 grp1 scan_in3 scan_out3
add scan chains chain4 grp1 scan_in4 scan_out4
add scan chains chain5 grp1 scan_in5 scan_out5
add clocks 0 NX1
add clocks 0 RST
add clocks 0 NX2

//**** Contents of testprocedure file .lbist_auto_scan_setup.dofile

//
// Generated by LBISTArchitect (BIST-Ready)
//
set time scale 1.000000 ns ;
timeplate gen_tp1 =
force_pi 0 ;
measure_po 10 ;
pulse NX1 20 10;
pulse NX2 20 10;
period 40 ;
end;
procedure shift =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force_sci ;

176 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Configuration_data Commands

measure_sco ;
pulse NX1 ;
pulse NX2 ;
end;
end;

procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force NX1 0 ;
force NX2 0 ;
force RST 0 ;
force scan_en 1 ;
end ;
apply shift 16;
end;

//**** End Contents of testprocedure file .lbist_auto_scan_setup.dofile

LBISTArchitect Reference Manual, v2017.3 177

September 2017
BIST-Ready Command Dictionary
Report Control Signals

Report Control Signals

Scope: Dft mode
Usage
REPort COntrol Signals {[-All] | {[pin_pathname…] [-Clock] [-Set] [-Reset] [-Write] [-Read]
[-Tristate_enable]} [-Verbose] [-NOSTABLE_High] [-NOSTABLE_Low]
Description
Displays the rules checking results for the specified control signals.
The Report Control Signals command displays the rules checking results for control signals
consisting of clocks added with the Add Clocks command and pins identified for gating
scannable memory elements with test logic.
Arguments
• -All
An optional switch that specifies to report on all control signals. This is the default.
• pin_pathname
An optional, repeatable string that specifies the pathnames of control signal signals for
which you want a report.
• -Clock
An optional switch that specifies to report on all clock control signals.
• -Set
An optional switch that specifies to report on all set control signals.
• -Reset
An optional switch that specifies to report on all reset control signals.
• -Write
An optional switch that specifies to report on all write control signals.
• -Read
An optional switch that specifies to report on all read control signals.
• -Tristate_enable
An optional switch that specifies to report on all tri-state enable signals.
• -Verbose
An optional switch that specifies to include all memory elements associated with each
control signal in the report.
• -NOSTABLE_High
An optional switch that specifies to not report on any stable-high memory elements.

178 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Control Signals

• -NOSTABLE_Low
An optional switch that specifies to not report on any stable-low memory elements.
Related Commands
Add Clocks Report Dft Check
Delete Clocks

LBISTArchitect Reference Manual, v2017.3 179

September 2017
BIST-Ready Command Dictionary
Report Dft Check

Report Dft Check

Scope: Dft mode
Usage
REPort DFt Check [-All | instance_pathname] [-FUll | -Scannable | -Nonscannable | {-Defined
{Scan | Nonscan} | -Identified | -Unidentified |
{-RUle {S1 | S2 | S3 | S4}} | -Tristate | -RAm] [{> | >>} file_pathname]
Description
Generates the scannability check results for non-scan instances.
The Report Dft Check command generates scannability check information for all non-scan
instances in the design, or within a specific hierarchical instance. The displayed or written
report includes six columns of information as described here:
• The first column displays whether the DFT Rules Checker identified the non-scan
instance as scannable or non-scannable.
• The second column displays whether the non-scan instance is unidentified, identified by
the scan identification process, or defined as non-scannable or scannable with the Add
Nonscan Instances and Add Scan Instances commands, respectively.
• The third column displays the clock that is associated with the non-scan instance, or
displays “Test-Logic” to specify that test logic will be added to make the instance
scannable. If the non-scan instance is identified as non-scannable, the third column
displays the design rule ID number, where the non-scan instance failed the clock rules.
The gate index number of the non-scannable instance is also shown, as well as the set,
reset, or clock primary inputs to the memory element that failed the rules checking.
• The fourth column displays the instance name of the non-scan instance.
• The fifth column displays the library model name associated with the instance.
• The sixth column displays “Stable-high” if the clock inputs of the non-scan instances are
at a one-state, with respect to the clock primary inputs.
An example of the output of this command, along with additional information, is covered in
“How to Report Scannability Information” in the Scan and ATPG User’s Manual.
Arguments
• -All
An optional switch that specifies to display all non-scan instances for the entire design. This
is the default.
• instance_pathname
An optional string that specifies to report scannability information for the specified instance.
If the instance pathname specifies a hierarchical instance, LBISTArchitect generates
scannability information for all instances within that hierarchical block. If the instance

180 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Dft Check

pathname specifies a particular sequential instance, LBISTArchitect generates scannability

information for only that instance.
• -Full
An optional switch that specifies to display the full scannability check information for all
non-scan instances. This is the default.
• -Scannable
An optional switch that specifies to display the non-scan instances that LBISTArchitect has
identified during the rules checking process to be scannable.
• -Nonscannable
An optional switch that specifies to display the non-scan instances that LBISTArchitect has
identified during the rules checking process to be non-scannable.
• -Defined Scan | Nonscan
An optional switch and literal pair that specifies whether to display user-defined scan or
non-scan instances. The valid literals are as follows:
Scan — A literal that specifies to display scan instances defined with the Add Scan
Instances command.
Nonscan — A literal that specifies to display non-scan instances defined with the Add
Nonscan Instances command.
• -Identified
An optional switch that specifies to display the non-scan instances that LBISTArchitect has
identified with the scan identification process.
• -Unidentified
An optional switch that specifies to display non-scan instances that remain to be identified
by the scan identification process.
• -RUle S1 | S2 | S3 | S4
An optional switch and literal specifying that nonscannable cells violating the specified rule
(S1, S2, S3, or S4) are reported.
• -Tristate
An optional switch that specifies to display the enable lines of tri-state gates that are
connected from the outputs of memory elements.
• -RAm
An optional switch that specifies to display the RAM gates that LBISTArchitect has
identified to be controllable through test logic insertion.
• > 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.

LBISTArchitect Reference Manual, v2017.3 181

September 2017
BIST-Ready Command Dictionary
Report Dft Check

• >> file_pathname
An optional redirection operator and pathname pair, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays the scannability check for all non-scan instances in the design:
add clocks 1 clk1
add clocks 0 clk0
set system mode dft
report dft check
SCANNABLE DEFINED-NONSCAN /CLK1 /U1 FD1
SCANNABLE IDENTIFIED /CLK1 /U2 FD1
SCANNABLE UNIDENTIFIED /CLK1 /U3 FD1
SCANNABLE DEFINED-SCAN /CLK1 /U4 FD1
SCANNABLE UNIDENTIFIED /CLK2 /U5 FD1
SCANNABLE IDENTIFIED /CLK2 /U6 FD1
NON-SCANNABLE UNIDENTIFIED S1 /U7 FD2 (34)
Clock #1: /CLK3 (11)
Number of non-scannable instances fails on S1 rule = 1
Number of instances found = 1
Number of instances reported = 1

Related Commands
Report Drc Rules

182 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Drc Rules

Report Drc Rules

Scope: All modes
Usage
REPort DRc Rules [-Fails_summary | -Summary |
rule_id… | rule_id-occurence#… | -All_fails]
[{> | >>} file_pathname]
D5 Usage
REPort DRc Rules D5
[ { [-TYpe {I0 | I1 | IX | T0 | T1 | TX | TLA}…]
[-NOType {I0 | I1 | IX | T0 | T1 | TX | TLA}…]
[-EDge_triggered | -LEvel_sensitive] } | -Summary]
[{> | >>} file_pathname]
Description
Displays either a summary of DRC violations (fails) or violation occurrence message(s).
The Report Drc Rules command displays data about design rules and DRC violations. It can
display a report in one of two formats:
• Summary report—Lists for each reported design rule, one line of data per rule, the
current number of DRC violations (fails), the violation handling, and a brief description
of the rule. When you request a summary of D5 violations, the report lists the number of
D5 violations of each type (INIT-0, INIT-1, INIT-X, TIE-0, TIE-1, TIE-X, TLA).
• Occurrence report—Lists one or more violation occurrence messages that give details of
specific DRC violations
Table 2-3 summarizes the available information and the arguments you use to obtain them.
Refer to the Arguments subsection for complete details about the arguments.

Table 2-3. Report DRC Rules Available Information and Arguments

Desired Display Rules/Occurrences Covered Argument
Summary Design rules that resulted in violations (fails) during -Fails_summary
report DRC
All design rules -Summary
Occurrence Specific rule, specific occurrence rule_id-occurence#
report 1
Specific rule, all occurrences rule_id
All occurrences -All_fails
1. Additional D5-specific arguments enable you to further customize the D5 information.

LBISTArchitect Reference Manual, v2017.3 183

September 2017
BIST-Ready Command Dictionary
Report Drc Rules

You can use the Set Drc Handling command to change the handling of many of the A (RAM), B
(BIST), C (clock), D (data), E (extra), T (trace), and W (timing) rules.
Arguments
• -Fails_Summary
A switch that specifies to display the following for each user-controllable rule that resulted
in a violation (fail) during DRC:
o Rule identification (ID)
o Number of failures of the rule
o Current handling status of the rule
o Brief description of the rule
This is the command’s default.
Note
This switch does not display anything if there are no rule violations, or if the tool has not
yet performed DRC.

• -Summary
A switch that specifies to display a summary report that varies depending on whether you
are reporting on all design rules or just on the D5 rule.
When you report on all rules (Report Drc Rules -Summary), the following is reported for
each user-controllable rule, whether or not it resulted in a violation (fail) during DRC:
o Rule identification (ID)
o Number of failures of the rule
o Current handling status of the rule
o Brief description of the rule
When you report on just the D5 rule (Report Drc Rules D5 -Summary) the tool displays the
number of non-scan memory elements of each type (INIT-0, INIT-1, INIT-X, TIE-0, TIE-1,
TIE-X or TLA) that resulted in a D5 violation during DRC. Refer to the description of the
-Type switch for the meaning of the types.

184 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Drc Rules

• rule_id
A repeatable string that specifies the identification literal (ID) of a particular design rule for
which you want to display all violation occurrence messages.
The design rules and their IDs divide into the following seven groups: A (RAM), B (BIST), C
(clock), D (data), E (extra), T (trace), and W (timing).
• rule_id-occurrence#
A repeatable string that specifies the identification literal (ID) of a particular design rule and
the violation occurrence for which you want to display the occurrence message. This
argument must include the specific design rule ID (rule_id), the specific occurrence number
of the violation, and the hyphen between them. For example, you can analyze the second
violation occurrence of the C3 rule by specifying C3-2. The tool assigns numbers to
occurrences of rule violations as it encounters them; you cannot change the number assigned
to a specific occurrence.
• -All_Fails
A switch that specifies to display all occurrence messages for all occurrences of rule
violations. The displayed information can be quite lengthy, as it is the same information you
would get if you consecutively entered a “report drc rules <rule_id>” command for each
rule that had a violation. Use this switch to output a report of all violation occurrences (most
likely to a log file) for later analysis.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
D5-only arguments
• -TYpe I0 | I1 | IX | T0 | T1 | TX | TLA
An optional switch and repeatable literal that displays D5 occurrence messages for only the
specified type(s) of non-scan sequential elements. The literal choices for the type of element
are as follows (the term you will see in occurrence messages for each type is shown in
parentheses):
I0 — If the element is at 0 at the beginning of the first capture cycle and may go to any
state during capture. (INIT-0)
I1 — If the element is at 1 at the beginning of the first capture cycle and may go to any
state during capture. (INIT-1)
IX — If the element’s state is unknown at the beginning of the first capture cycle and
may go to any state during capture. (INIT-X)
T0 — If the element is always at 0 during capture. (TIE-0)

LBISTArchitect Reference Manual, v2017.3 185

September 2017
BIST-Ready Command Dictionary
Report Drc Rules

T1 — If the element is always at 1 during capture. (TIE-1)

TX — If the element is always at an unknown state during capture. (TIE-X)
TLA — If the element is always transparent when its clock is at its off state. (TLA)

Tip: Except for TLAs, you can also direct the tool to display information for only those
D5 elements that are edge-triggered or level-sensitive. See the -Edge_triggered and
-Level_sensitive switch descriptions for details.

• -NOType I0 | I1 | IX | T0 | T1 | TX | TLA
An optional switch and repeatable literal that specify not to display occurrence messages for
the particular type(s) of D5 violations. See the description of the -Type switch for the
meaning of the literal choices.
• -EDge_triggered | -LEvel_sensitive
Optional switches that specify to display D5 occurrence messages either for edge-triggered
or level-sensitive elements only. The default (when neither option is specified) is to display
information for both edge-triggered and level-sensitive elements.
Examples
The following example displays a summary of the rules that resulted in violations during an
attempted run:
report drc rules
C3: #fails=2 handling=warning (clock may capture data affected by its
captured data)
C5: #fails=1 handling=error (clock is connected to multiple ports of same
latch)
C7: #fails=19 handling=warning (scan cell capture ability check)
C8: #fails=2 handling=warning (PO connected to a clock line)
C9: #fails=2 handling=warning (PO connected to a clock line gated by scan
cell that uses same clock)
D5: #fails=23 handling=warning (non-scan memory element)
D6: #fails=22 handling=warning (non-transparent non-scan latches)
D7: #fails=22 handling=warning (stable high edge-triggered clock ports)

This example displays the occurrence message for the two C3 violations, and the first C7, and
first D7 violation reported in the preceding example:
report drc rules c3 c7-1 d7-1
// Warning: Clock /sgst failed rule C3 on input 3 of /sp_b_i0.latch
(1501). (C3-1)
// Source of violation: input 3 of /sp_c_i1.slave (1482).
// Warning: Clock /sgst failed rule C3 on input 3 of /sp_c_i0.latch
(1527). (C3-2)
// Source of violation: input 3 of /sp_c_i1.slave (1482).
// Warning: Clock input 5 of /c8.master (1495) cannot capture data
with single clock on. (C7-1)
// Warning: Flipflop /FF1 (103) has clock port set to stable high. (D7-1)

186 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Drc Rules

This example displays the occurrence message for the D7 violation:

report drc rules d7-1
//Error: Flipflop /FF1 (103) has clock port set to stable high. (D7-1)

The next example displays a summary of the non-scan memory elements that resulted in D5 rule
violations:
report drc rules d5 -summary
// --------------------------------------------------------------------
// 44 non-scan memory elements are identified.
// --------------------------------------------------------------------
// 9 non-scan memory elements are identified as TIE-0. (D5)
// 2 non-scan memory elements are identified as TIE-1. (D5)
// 5 non-scan memory elements are identified as TIE-X. (D5)
// 3 non-scan memory elements are identified as INIT-0. (D5)
// 11 non-scan memory elements are identified as INIT-1. (D5)
// 4 non-scan memory elements are identified as INIT-X. (D5)
// 10 non-scan memory elements are identified as TLA. (D5)
// --------------------------------------------------------------------

The next example displays details about the preceding example’s D5 violations that occurred on
non-scan memory elements the tool identified as type INIT-X:
report drc rules d5 -type ix
// Warning: /U1 (78) is a non-scan flip-flop identified as INIT-x.(D5-1)
// Warning: /U6 (56) is a non-scan flip-flop identified as INIT-x.(D5-7)
// Warning: /U7 (82) is a non-scan flip-flop identified as INIT-x.(D5-8)
// Warning: /U9 (11) is a non-scan latch identified as INIT-x.(D5-9)
// Number of non-scan memory elements reported = 4.

The next example displays the information for just the INIT-X non-scan latch:
report drc rules d5 -type ix -level_sensitive
// Warning: /U9 (11) is a non-scan latch identified as INIT-x.(D5-9)
// Number of non-scan memory elements reported = 1.

You could obtain the same information using the -Notype switch:
report drc rules d5 -notype i1 i0 tx t1 t0 tla -level_sensitive
// Warning: /U9 (11) is a non-scan latch identified as INIT-x.(D5-9)
// Number of non-scan memory elements reported = 1.

Related Commands
Set Drc Handling

LBISTArchitect Reference Manual, v2017.3 187

September 2017
BIST-Ready Command Dictionary
Report Environment

Report Environment
Scope: All modes
Usage
REPort ENvironment [{> | >>} file_pathname]
Description
Displays the current values of all the “set” commands and the default names of the scan type
pins.
When you first invoke the BIST-Ready phase of LBISTArchitect, executing the Report
Environment command shows all of the default values of the “set” commands. By default, the
output of the command is written to the transcript window of the tool.
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example shows the BIST-Ready invocation default settings:
report environment
Top Module = m8051
Gate Level = design
Gate Report = normal
Net Resolution = wire
System Mode = setup
Tied Signal = x
Dofile Abort = on
Trace Report = off
Scan Type = mux_scan
Identification Model = clock:original disturb:on
Scan Identification = full_scan
Test_point Identification = control:100 observe:100
Transient Detection = on -verbose
Fault Sampling = 100.000000%
Scan-in Naming = prefix:scan_in initial:1 modifier:1 suffix:
Scan-out Naming = prefix:scan_out initial:1 modifier:1 suffix:
Test Enable Name = test_en active = high
Test Clock Name = test_clk
Scan Enable Name = scan_en active = high
Scan Clock Name = scan_clk
Scan Master Clock Name = scan_mclk
Scan Slave Clock Name = scan_sclk

188 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Environment

Set Name = scan_set muxed

Reset Name = scan_reset muxed
Write Clock Name = write_clk muxed
Read Clock Name = read_clk muxed
Hold Enable Name = hold_en
Control Input Name = phase_cntl
Observe Output Name = test_obs
Net Naming = net Instance Naming = uu
Test Logic = set:off reset:off clock:off tristate:off bidi:Scan
ram:off
Screen Display = on
Lockup Latch = off nolast first_clock
Latch Handling = none

Related Commands
Any of the “Set” commands.

LBISTArchitect Reference Manual, v2017.3 189

September 2017
BIST-Ready Command Dictionary
Report Faults

Report Faults
Scope: Dft mode
Usage
REPort FAults [-Class class_type] [-Stuck_at {01 | 0 | 1}] [-All | object_pathname…]
[-Hierarchy integer [-Min_count integer]] [-Noeq] [-VErilog] [-CEll_name]
Description
Displays fault information from the current fault list.
The Report Faults command displays faults from the fault list added using the Add Faults
command. You can use the optional arguments to narrow the focus of the report to only specific
stuck-at faults that occur on a specific object in a specific class. If you do not specify any
arguments, Report Faults displays information on all the known faults.
The Report Faults command displays the following columns of information for each fault:
• fault value - The fault value may be either 0 (for stuck-at-0) or 1 (for stuck-at-1).
• fault code - A code name that indicates the lowest level fault class assigned to the fault.
• fault site - The pin pathname of the fault site.
• cell name (optional) - The name of the cell corresponding to the fault (displayed only if
you include the -Cell_name argument).
You can use the -Hierarchy option to display a hierarchal summary of the selected faults. The
summary identifies the number of faults in each level of hierarchy whose level does not exceed
the specified level number. You can further specify the hierarchical summary by using the
-Min_count option which specifies the minimum number of faults that must be in a hierarchal
level before displaying.
Arguments
• -Class class_type
An optional switch and literal pair that specifies the class of faults that you want to display.
The class_type argument can be either a fault class code or a fault class name. If you do not
specify a class_type, the command displays all fault classes. Table 2-4 lists the valid fault
class codes and their associated fault class names; use either the code or the name when
specifying the class_type argument:

Table 2-4. Fault Class Codes and Names

Fault Class Codes Fault Class Names
FU Full
TE TEstable
DT DETEcted

190 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Faults

Table 2-4. Fault Class Codes and Names

Fault Class Codes Fault Class Names
DS DET_Simulation
DI DET_Implication
PD POSDET
PU POSDET_Untestable
PT POSDET_Testable
OU OSC_Untestable
OT OSC_Testable
HU HYP_Untestable
HT HYP_Testable
AU Atpg_untestable
UD UNDetected
UC UNControlled
UO UNObserved
UT UNTestable
UU UNUsed
TI TIed
BL Blocked
RE Redundant
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies the stuck-at faults that you want to display.
The stuck-at literal choices are as follows:
01 — A literal that displays both the “stuck-at-0” and “stuck-at-1” faults. This is the
default.
0 — A literal that displays the “stuck-at-0” faults.
1 — A literal that displays the “stuck-at-1” faults.
• -All
An optional switch that displays all of the faults on all model, netlist primitive, and top
module pins. This is the default.
• object_pathname
An optional repeatable string that specifies a list of pins or instances whose faults you want
to display.

LBISTArchitect Reference Manual, v2017.3 191

September 2017
BIST-Ready Command Dictionary
Report Faults

• -Hierarchy integer
An optional switch and integer pair that specifies the maximum fault class hierarchy level
for which you want to display a hierarchal summary of the faults.
• -Min_count integer
An optional switch and integer pair that you can use with the -Hierarchy option and that
specifies the minimum number of faults that must be in a hierarchal level to display the
hierarchal summary. The default is 1.
• -Noeq
An optional switch that displays the fault class of equivalent faults. When you do not
specify this switch, the tool displays an “EQ” as the fault class for any equivalent faults.
• -Verilog
An optional switch that outputs the fault paths in Verilog syntax, rather than using the
existing netlist independent format.
• -CEll_name
An optional switch that specifies to list, for each reported fault, the name of the
corresponding circuit element (ATPG library cell, Verilog primitive, primary input or
primary output) as summarized in Table 2-5. Cell names displayed for equivalent faults are
based on the cells associated with the equivalent faults, not the cells associated with the
representative faults. This switch is valid for the stuck-at, transition, toggle and IDDQ fault
models only.
Table 2-5. Name Conventions Used by Report Faults -Cell_name
Corresponding Circuit Element Listed Cell Name
ATPG library cell Name of the ATPG library cell
Supported Verilog primitive—see Name of the Verilog primitive
“Verilog Primitives” in the Tessent Cell
Library Manual
Primary input or output “primary_input” or “primary_output”

Examples
The following example displays all faults that have been added to the circuit before performing
a fault simulation and signature calculation run:
set system mode bist
add faults -all
report faults -all
run

192 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Feedback Paths

Report Feedback Paths

Scope: Dft mode
Prerequisites
You can only use this command after the tool performs the learning process, which happens
immediately after flattening a design to the simulation model. Flattening occurs when you first
attempt to exit Setup mode.
Usage
REPort FEedback Paths [-All | loop_id#…] [-Display {DEBug | DESign | DAta | ALl}] [{> |
>>} file_pathname]
Description
Displays a textual report of the currently identified feedback paths.
The Report Feedback Paths command displays any feedback paths the tool identified during the
last circuit learning process. By default, the command displays all currently identified feedback
paths and their identification numbers. Issuing the command with the identification numbers of
specific paths of interest will limit the display to just those paths.
Note
Feedback paths include, by default, any duplicated gates.

Arguments
• -ALl
An optional switch that specifies to report all currently identified feedback paths. This is the
default.
• loop_id#
An optional, repeatable, non-negative integer that specifies the identification number of a
particular feedback path to report. The tool assigns the numbers consecutively, starting with
0.
• -Display {DEBug | DESign | DAta | ALl}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DEBug — Debug window
DESign — Design window
DAta — Data window
ALl— A literal that displays the information in all of the preceding windows.

LBISTArchitect Reference Manual, v2017.3 193

September 2017
BIST-Ready Command Dictionary
Report Feedback Paths

• > 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 for appending to the contents of
file_pathname.
Examples
The following example leaves the Setup mode (which, among other things, flattens the
simulation model and performs the learning process) and displays the identification numbers of
any learned feedback paths:
set system mode dft
report feedback paths
Loop#=0, feedback_buffer=26, #gates_in_network=5
INV /I_956__I_582/ (51)
PBUS /I_956__I_582/N1/ (96)
ZVAL /I_956__I_582/N1/ (101)
INV /I_956__I_582/ (106)
TIEX /I_956__I_582/ (26)
Loop#=1, feedback_buffer=27, #gates_in_network=5
INV /I_962__I_582/ (52)
PBUS /I_962__I_582/N1/ (95)
ZVAL /I_962__I_582/N1/ (100)
INV /I_962__I_582/ (105)
TIEX /I_962__I_582/ (27)

Related Commands
Report Loops Set Loop Duplication

194 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Gates

Report Gates
Scope: All modes
Prerequisites
Although you can use this command in Setup or Dft mode, you can use it in the Setup mode
only after the netlist has been flattened. This happens when you first attempt to exit Setup mode.
Next time you return to Setup mode, you can use the command.
Usage
REPort GAtes {gate_id# | pin_pathname | instance_name}… | {-Type gate_type}…
Description
Displays the netlist information and simulation results for the specified gates.
The Report Gates command displays the netlist information for either the design-level or the
primitive-level gates you specify. You designate the gate by its gate identification number
(ID#), a pathname of a pin connected to a gate, an instance name (design level only), or a gate
type. You can specify a design cell by the pathname of a pin on the design cell. If you use a gate
ID# or gate type, the command always reports the primitive-level gate. You must flatten the
netlist before issuing this command.
The pin_pathname and instance_name arguments support regular expressions, which may
include any number of ‘*’ or ‘?’ wildcard characters embedded in the pathname string. The ‘*’
character matches any sequence of characters (including none) in a name, and the ‘?’ character
matches any single character. If a wildcard name is specified, the command will search for
matching instance names from the top library cell level, down to the primitive gates.
The format for the design level is:
instance_name cell_type
input_pin_name I (data) pin_pathname...
...
output_pin_name 0 (data) pin_pathname...
...

The format for the primitive level is:

instance_name (gate_ID#) gate_type
input_pin_name I (data) gate_ID#-pin_pathname...
...
output_pin_name O (data) gate_ID#-pin_pathname...
...

The list associated with the input and output pin names indicates the pins to which they are
connected. For the primitive-level, this also includes the gate index number of the connecting
gate and only includes the pin pathname if one exists at that point. There is a limitation on
reporting gates at the design-level. If some circuitry inside the design cell is completely isolated
from other circuitry, the command only reports the circuitry associated with the pin pathname.

LBISTArchitect Reference Manual, v2017.3 195

September 2017
BIST-Ready Command Dictionary
Report Gates

You can change the output of the Report Gates command by using the Set Gate Report
command. You must flatten the netlist before issuing this command.

Reporting on the First Input of a Gate

Report Gates provides a shortcut to display data on the gate connected to the first input of the
previously reported gate. This lets you quickly and easily trace backward through circuitry. To
use Report Gates in this manner, first report on a specific gate and then enter:

SETUP> b

The following example shows how to use Report Gate and B commands to trace backward
through the first input of the previously reported gate.

SETUP> rep gate 26

// /u1/inst__565_ff_d_1__13 (26) BUF
// "I0" I 269-
// "OUT" O 268- 75-

SETUP> b
// /u1/inst__565_ff_d_1__13 (269) LA
// "S" I 14-
// "R" I 145-
// SCLK I 4-/clk
// D I 265-/u1/_g32/X
// ACLK I 2-/scan_mclk
// SDI I 20-/u1/inst__565_ff_d_0__dff/Q2

// "OUT" O 26- 27-

SETUP> b
// /u1/inst__565_ff_d_1__13 (14) TIE0
// "OUT" O 269- 268-

Reporting on the First Fanout of a Gate

Similar to tracing backward through circuitry, you can also use a shortcut to trace forward
through the first fanout of the previously reported gate. To use Report Gates in this manner, first
report on a specific gate, and then enter:
SETUP> f

The following example shows how to use Report Gate and F commands to trace forward
through the first fanout of the previously reported gate.

SETUP> rep ga 269

// /u1/inst__565_ff_d_1__13 (269) LA
// "S" I 14-
// "R" I 145-
// SCLK I 4-/clk
// D I 265-/u1/_g32/X

196 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Gates

// ACLK I 2-/scan_mclk
// SDI I 20-/u1/inst__565_ff_d_0__dff/Q2
// "OUT" O 26- 27-

SETUP> f
// /u1/inst__565_ff_d_1__13 (26) BUF
// "I0" I 269-
// "OUT" O 268- 75-

SETUP> f
// /u1/inst__565_ff_d_1__13 (268) LA
// "S" I 14-
// "R" I 145-
// BCLK I 1-/scan_sclk
// "D0" I 26-
// "OUT" O 24- 25-

Arguments
• gate_id#
A repeatable integer that specifies the gate identification numbers of the objects for which
you want to display gate information. The value of the gate_id# argument is the unique
identification number that LBISTArchitect automatically assigns to every gate within the
design during the model flattening process.
• pin_pathname
A repeatable string that specifies the names of pins within the design for which you want to
display gate information.
• instance_name
A repeatable string that specifies the top-level boundary instance names within the design
for which you want to display gate information. This is used for the design-level only.
• -Type gate_type
A repeatable switch and name pair that specifies the gate types for which you want to
display the gate information. The supported gate_types are listed in Table 2-6.

Table 2-6. Report Gate Types

gate_type Description
BUF buffer
INV inverter
AND and
NAND inverted and
OR or
NOR inverted or

LBISTArchitect Reference Manual, v2017.3 197

September 2017
BIST-Ready Command Dictionary
Report Gates

Table 2-6. Report Gate Types (cont.)

gate_type Description
XOR exclusive-or
XNOR inverted exclusive-or
DFF D flip-flop, same as _dff library primitive
LA latch, same as _dlat library primitive
PI primary input
PO primary output
TIE0 tied low
TIE1 tied high
TIEX tied unknown
TIEZ tied high impedance
TLA transparent latch
TSH tri-state driver, first input is active high enable line
TSL tri-state driver, first input is active low enable line
BUS tri-state bus
Z2X Z converter gate, converts Z to X
WIRE undetermined wired gate
MUX 2-way multiplexer, first line is select line
RAM random access memory
ROM read only memory
XDET X detector, gives 1 when input is X
ZDET Z detector, gives 1 when input is Z

Examples
The following example displays the simulated values of the gate and its inputs.
set system mode dft
set gate report error_pattern
set gate level primitive
report gates i_1006/o
/P2.13P (20) NAND
A I 10-/LD.1
B I 7-/M1.1
Z O 30-/P2.2P/S

The gate report for the design level may look like the following:

198 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Gates

/P2.13P ND2
A I /LD.1
B I /M1.1
Z O /P2.2P/S

Related Commands
Set Gate Level Set Gate Report

LBISTArchitect Reference Manual, v2017.3 199

September 2017
BIST-Ready Command Dictionary
Report Instance

Report Instance
Scope: All modes
Usage
Report Instance instance_expression [{> | >>} file_pathname]
Description
Displays list of instances matched by instance expression.
The Report Instance command displays the list of instance pathnames. This command is used in
experimenting with instance expressions prior to their actual use in other commands.
The LBISTArchitect commands that support instance-expressions are:
Add Nonscan Instances
Add Notest Points
Add Scan Instances
Add Nofaults
Delete Nofaults
Delete Notest Points
Delete Nonscan Instances
Delete Scan Instances

Arguments
• instance_expression
A required string representing a list of instance pathnames. The string instance_expression
is defined as:
{ string | string * } ...

The asterisk (*) is a wildcard that allows you to match many instances in a design. Any
expression that contains no asterisk (*) will match exactly zero or one instance. See the
following examples for ways to use the asterisk (*) wildcard.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.

200 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Instance

Examples
The following example writes all instances (possibly a large number) into a file.
report instance * > all.list
... writing to file all.list

This example demonstrates how to do a prefix match:

report instance /u9/u2/LCT_reg*

=== search results size: 8 ===

/u9/u2/LCT_reg_0_
/u9/u2/LCT_reg_1_
/u9/u2/LCT_reg_2_
/u9/u2/LCT_reg_3_
/u9/u2/LCT_reg_4_
/u9/u2/LCT_reg_5_
/u9/u2/LCT_reg_6_
/u9/u2/LCT_reg_7_

This example demonstrates a suffix match:

report instance *LCT_reg_0_

=== search results size: 4 ===
/u9/u4/LCT_reg_0_
/u9/u3/LCT_reg_0_
/u9/u2/LCT_reg_0_
/u9/u1/LCT_reg_0_

This example demonstrates an exact match:

report instance /IMMDAT_reg_0_
=== search results size: 1 ===
/IMMDAT_reg_0_

As stated previously, any expression that contains no asterisk (*) will match exactly zero or one
instance.

This example demonstrates how to wildcard the 2nd level of hierarchy:

report instance /u9/*/LCT_reg_0_
=== search results size: 4 ===
/u9/u4/LCT_reg_0_
/u9/u3/LCT_reg_0_
/u9/u2/LCT_reg_0_
/u9/u1/LCT_reg_0_

LBISTArchitect Reference Manual, v2017.3 201

September 2017
BIST-Ready Command Dictionary
Report Instance

This example combines an asterisk (*) at the 2nd level of hierarchy with a prefix match:
report instance /u9/*/LCT_reg*
=== search results size: 32 ===
/u9/u4/LCT_reg_0_
/u9/u4/LCT_reg_1_
/u9/u4/LCT_reg_2_
/u9/u4/LCT_reg_3_
/u9/u4/LCT_reg_4_
/u9/u4/LCT_reg_5_
/u9/u4/LCT_reg_6_
/u9/u4/LCT_reg_7_
/u9/u3/LCT_reg_0_
/u9/u3/LCT_reg_1_
/u9/u3/LCT_reg_2_
/u9/u3/LCT_reg_3_
/u9/u3/LCT_reg_4_
/u9/u3/LCT_reg_5_
/u9/u3/LCT_reg_6_
/u9/u3/LCT_reg_7_
/u9/u2/LCT_reg_0_
/u9/u2/LCT_reg_1_
/u9/u2/LCT_reg_2_
/u9/u2/LCT_reg_3_
/u9/u2/LCT_reg_4_
/u9/u2/LCT_reg_5_
/u9/u2/LCT_reg_6_
/u9/u2/LCT_reg_7_
/u9/u1/LCT_reg_0_
/u9/u1/LCT_reg_1_
/u9/u1/LCT_reg_2_
/u9/u1/LCT_reg_3_
/u9/u1/LCT_reg_4_
/u9/u1/LCT_reg_5_
/u9/u1/LCT_reg_6_
/u9/u1/LCT_reg_7_

Related Commands
Add Nonscan Instances Delete Nofaults
Add Nofaults Delete Nonscan Instances
Add Notest Points Delete Notest Points
Add Scan Instances Delete Scan Instances

202 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Loops

Report Loops
Scope: Dft mode
Usage
REPort LOops [-All | loop_id#…] [-Display {DESign | DAta}] [{> | >>} file_pathname]
Description
Displays information about circuit loops.
The Report Loops command displays information about currently identified loops in the circuit.
For each loop, the report indicates whether the loop was broken by duplication. Loops that are
not broken by duplication are shown as being broken by a constant value, which means the loop
is either a coupling loop or has a single multiple fanout gate. The report also includes the pin
pathname and gate type of each gate in each loop.
You can write the loops report information to a file by using the command’s redirection
operators or the Write Loops command.
Arguments
• -ALl
An optional switch that specifies to report all the loops in the circuit. This is the default.
• loop_id#
An optional, repeatable, positive integer that specifies the identification number of a
particular loop to report. The tool assigns loop identification numbers consecutively,
starting with 1.
• -Display {DESign | DAta}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DESign — Design window
DAta — Data window
• > 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 for appending to the contents of
file_pathname.
Examples
The following example lists all the loops in the circuit:
set system mode dft
report loops

LBISTArchitect Reference Manual, v2017.3 203

September 2017
BIST-Ready Command Dictionary
Report Loops

Loop = 1: not_duplicated (coupling loop)

my_design/my_minibus (SBUS)
my_design/PAD (BUF)
my_design/my_minibus (Z2X)
Loop = 2: not_duplicated (coupling loop)
...
Loop = 8: not_duplicated (single multiple fanout)
my_design/al/pl/padx (BUF)
my_design/al/pl/pad (BUF)
my_design/pad (WIRE)

The next example displays loop 8 only:

report loops 8
Loop = 8: not_duplicated (single multiple fanout)
my_design/al/pl/padx (BUF)
my_design/al/pl/pad (BUF)
my_design/pad (WIRE)

The next example writes the display information for loop 8 to a new file named my_loop_file:
report loops 8 > my_loop_file
... writing to file my_loop_file

Related Commands
Report Feedback Paths Write Loops

204 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Mapping Definition

Report Mapping Definition

Scope: Setup and Dft modes
Usage
REPort MApping Definition -All | {object_name [-Instance | -Module]
[-Nonscan_model nonscan_model_name] [-Scan_model scan_model_name]
[-Output scan_ouput_pin_name]} [-Filename filename [-Replace]]
Description
Reports the nonscan to scan model mapping defined in the design.
The Report Mapping Definition command reports the mapping of nonscan models to scan
models. You can report the scan and output mapping for an individual instance, all instances
under a hierarchical instance, all instances in all occurrences of a module in the design, all
occurrences of the model in the entire design, or the entire design.
The report is always displayed in the transcript. You can optionally write it to a file using the -
Filename switch.
Arguments
• -All
A switch that specifies to report all scan and output mapping in the entire design.
• object_name
A string that specifies the name of the nonscan model you want to report on. You can also
specify an instance, hierarchical instance, module, or scan model.
o If this argument is the name of an instance or hierarchical instance, the -Instance
switch is required, and (optionally) the model can be specified with the -
Nonscan_model switch or -Scan_model switch.
o If this argument is the name of a module, then the -Module switch is required, and
(optionally) the model can be specified with the -Nonscan_model or -Scan_model
switch.
o If this argument is a scan model, then the -Output switch is required. Because you
specified a scan model, you can only report the scan output pin mapping.
• -Instance | -Module
An optional switch that specifies the type of the object_name argument. If neither switch is
specified, the object_name is a model (the default).
o If you specify -Instance and the instance is primitive, then the tool reports only the
named instance.
o If you specify -Instance and the instance is hierarchical, then the tool reports all
instances under that instance. Optionally, you can constrain the report to matching
the -Nonscan_model or (for output mapping) matching the -Scan_model.

LBISTArchitect Reference Manual, v2017.3 205

September 2017
BIST-Ready Command Dictionary
Report Mapping Definition

o If you specify -Module, then for all occurrences of that module, the tool reports all
instances within that module. Optionally, you can constrain the report to matching
the -Nonscan_model or (for output mapping) matching the -Scan_model.
• -Nonscan_model nonscan_model_name
A switch and string pair that specifies the name of the nonscan model that you want to report
on. This argument is required only if you specify -Instance or -Module switch and want to
constrain the report to objects matching the nonscan model; otherwise, you can specify the
nonscan model in the object_name argument.
• -Scan_model scan_model_name
A switch and string pair that specifies the name of the scan model to report on. This
argument is required when you want to further constrain the report, except when you are
only reporting the mapping of the scan output pin and specify the scan model in the
object_name argument.
• -Output [scan_ouput_pin_name]
An optional switch and string pair that specifies the name of the scan output pin. You can
use this to constrain the report. Specifying just the -Output switch reports all mapped scan
output pins for the specified scan model, while specifying the switch with a pin name,
reports the mapping for only scan models that use that pin for the scan output.
• -Filename filename [-Replace]
An optional switch and string that specifies that LBISTArchitect write the scan mapping
report to a file. The -Replace switch specifies that the file should be overwritten if it already
exists.
Examples
The following example reports the scan and output mapping for all occurrences the fd1 nonscan
model in the design:
report mapping definition fd1

The following example reports the mapping for each occurrence of the fd1 nonscan model
mapped to the fd1s scan model with the scan output pin mapped to “qn”:
report mapping definition fd1 -scan_model fd1s -output qn

The following example reports the mapping for each occurrence of the fd1s scan model in the
design:
report mapping definition fd1s -output

The following example reports the mapping for all instances under the hierarchical instance
“/top/counter1”:
report mapping definition /top/counter1 -instance

The following example reports the mapping for each occurrence of the fd1s scan model with the
scan output pin mapped to “qn” for all matching instances in the “counter” module and for all
occurrences of that module in the design:

206 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Mapping Definition

report mapping definition counter -module -scan_model fd1s -output qn

Related Commands
Add Mapping Definition Delete Mapping Definition

LBISTArchitect Reference Manual, v2017.3 207

September 2017
BIST-Ready Command Dictionary
Report Nofaults

Report Nofaults
Scope: All modes
Usage
REPort NOfaults {pathname… | -All} [-Instance] [-Stuck_at {01 | 0 | 1}]
Description
Displays the no-fault settings for the specified pin or instance pathnames.
The Report Nofaults command displays for pin pathnames or pin names of instances the nofault
settings that you previously specified with the Add Nofaults command.
Arguments
• pathname
A repeatable string that specifies the pin pathnames or the instance pathnames for which you
want to display the nofault settings. If you specify an instance pathname, you must also
specify the -Instance switch.
• -All
A switch that specifies to display the nofault settings on either all pin pathnames or, if you
also specify the -Instance switch, all pin names of instances.
• -Instance
An optional switch that specifies that the pathname or -All argument indicates instance
pathnames.
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies the stuck-at nofault settings which you want
to display. The valid stuck-at literals are as follows:
01 — A literal that specifies to display both the “stuck-at-0” and “stuck-at-1” nofault
settings. This is the default.
0 — A literal that specifies to only display the “stuck-at-0” nofault settings.
1 — A literal that specifies to only display the “stuck-at-1” nofault settings.
Examples
The following example displays all pin names of the instances that have the nofault settings:
add nofaults i_1006 i_1007 i_1008 -instance
report nofaults

Related Commands
Add Nofaults Delete Nofaults

208 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Nonscan Models

Report Nonscan Models

Scope: All modes
Usage
REPort NONscan Models [-Class {Full | User}]
Description
Displays the sequential non-scan model list.
The Report Nonscan Models command displays sequential models that you added by using the
Add Nonscan Models command
Arguments
• -Class Full | User
An optional switch and literal pair that specifies the source (or class) of the sequential non-
scan models that you want to display. The valid literals are as follows:
Full — A literal that specifies to display all the non-scan sequential models in the user
and system class. This is the default.
User — A literal that specifies to only display the non-scan sequential models that are
the result of the Add Nonscan Models command.
Examples
The following example displays all sequential non-scan models from the non-scan model list:
set system mode dft
add nonscan models d_flip_flop1 d_flip_flop2
report nonscan models

Related Commands
Add Nonscan Models Delete Nonscan Models

LBISTArchitect Reference Manual, v2017.3 209

September 2017
BIST-Ready Command Dictionary
Report Notest Points

Report Notest Points

Scope: Setup and Dft modes
Usage
REPort Notest Points [-Paths] [-Observe_scan_cell]
Description
Displays all the circuit points removed from consideration by LBISTArchitect as controllability
and observability insertion points.
The Report Notest Points command displays the circuit points added using the Add Notest
Points command and which, therefore, LBISTArchitect cannot use for testability insertion. You
can also list the critical path definitions that added notest points by using the -Paths switch, and
list scan cells that are excluded from being used as observation scan cells by using the -
Observe_scan_cell switch.
Arguments
• -Paths
An optional switch that displays the definitions for all currently loaded critical paths that
have marked notest points. If this switch is not specified, the tool reports only the resulting
notest points.
• -Observe_scan_cell
An optional switch that specifies to list the instances that cannot be used as an observation
scan cell.
Examples
The following example displays the list of all circuit points that LBISTArchitect cannot use for
testability insertion:
set system mode dft
add notest points tr_io
add notest points ts_i
report notest points

Related Commands
Add Notest Points Delete Notest Points

210 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Output Masks

Report Output Masks

Scope: All modes
Usage
REPort OUtput Masks
Description
Displays a list of the currently masked primary output pins.
The Report Output Masks command displays the primary output pins that you previously
masked by using the Add Output Masks command. When you mask a primary output pin, you
inform LBISTArchitect to mark that pin as an invalid observation point during the scan cell
identification process. LBISTArchitect uses all unmasked primary output pins as possible
observation points to which the effects of all faults propagate for detection.
Examples
The following example masks two primary outputs and then displays the results:
add output masks q1 -hold1
add output masks qb1 -hold 0
report output masks
q1 hold1
qb1 hold0

Related Commands
Add Output Masks Delete Output Masks
Analyze Output Observe Setup Output Masks

LBISTArchitect Reference Manual, v2017.3 211

September 2017
BIST-Ready Command Dictionary
Report Pin Constraints

Report Pin Constraints

Scope: All modes
Usage
REPort PIn Constraints [-All | primary_input_pin…] [-Display {DEBug | DESign | DAta |
ALl}]
Description
Displays the pin constraints of the primary inputs.
The Report Pin Constraints command displays the pin constraints that you previously added to
the primary inputs with the Add Pin Constraints command. You can change the constant value
constraints of the primary inputs by using the Add Pin Constraints or Setup Pin Constraints
commands.
Note
This reported information from this command has effects on other commands that relate
to fault simulation; this includes simulation-based and multiphase test points selection,
along with BIST pattern simulation (in BIST mode).

Arguments
• -All
An optional switch that specifies to display the current constraints for all primary input pins.
This is the default.
• primary_input_pin
An optional repeatable string that specifies a list of primary input pins whose constraints
you want to display.
• -Display {DEBug | DESign | DAta | ALl}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DEBug — Debug window
DESign — Design window
DAta — Data window
ALl— A literal that displays the information in all of the preceding windows.
Examples
The following example displays the cycle behavior constraints of all primary inputs.
add pin constraints ph1 c0
add pin constraints ph2 c1
report pin constraints -all

212 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Pin Constraints

Related Commands
Add Pin Constraints Setup Pin Constraints
Delete Pin Constraints Setup Scan Identification

LBISTArchitect Reference Manual, v2017.3 213

September 2017
BIST-Ready Command Dictionary
Report Pin Equivalences

Report Pin Equivalences

Scope: All modes
Usage
REPort PIn Equivalences
Description
Displays the pin equivalences of the primary inputs.
The Report Pin Equivalences command displays a list of primary inputs, which you previously
restricted to be at equivalent or complementary values, by using the Add Pin Equivalences
command.
Note
The reported information from this command has effects on other commands that relate
to fault simulation; this includes simulation-based and multiphase test points selection,
along with BIST pattern simulation (in BIST mode).

Examples
The following example displays all pin equivalences that have been added to the primary inputs:
add pin equivalences indata2 indata4
add pin equivalences indata3 -invert indata5
report pin equivalences

Related Commands
Add Pin Equivalences Delete Pin Equivalences

214 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Primary Inputs

Report Primary Inputs

Scope: All modes
Usage
REPort PRimary Inputs [-All | primary_input_pin…] [{> | >>} file_pathname]
Description
Displays the specified primary inputs.
The Report Primary Inputs command displays a list of either all the primary inputs of a circuit
or a specific list of primary inputs that you specify.
Arguments
• -All
An optional switch that specifies to display all the primary inputs. This is the default.
• primary_input_pin
An optional repeatable string that specifies a list of primary input pins that you want to
display.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays all of the primary inputs:
report primary inputs -all
SYSTEM: /clk
SYSTEM: /datain

Note
The label “system” means that these are primary inputs that LBISTArchitect
automatically recognizes because they were in the netlist. Because there is no Add
Primary Input command in LBISTArchitect, all primary inputs are of the system-defined
class.

Related Commands
Write Primary Inputs

LBISTArchitect Reference Manual, v2017.3 215

September 2017
BIST-Ready Command Dictionary
Report Primary Outputs

Report Primary Outputs

Scope: All modes
Usage
REPort PRimary Outputs [-All | primary_output_pin…] [{> | >>} file_pathname]
Description
Displays the specified primary outputs.
The Report Primary Outputs command displays a list of either all the primary outputs of a
circuit or a specific list of primary outputs that you specify.
Arguments
• -All
An optional switch that specifies to display all the primary outputs. This is the default.
• primary_output_pin
An optional repeatable string that specifies a list of primary output pins that you want to
display.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays all of the primary outputs:
report primary outputs -all
SYSTEM: /dataout
SYSTEM: /dataout1

Note
The label “system” means that these are primary outputs that LBISTArchitect
automatically recognizes because they were in the netlist. Because there is no Add
Primary Output command in LBISTArchitect, all primary outputs are of the system-
defined class.

Related Commands
Write Primary Outputs

216 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Read Controls

Report Read Controls

Scope: All modes
Usage
REPort REad Controls
Description
Displays all of the currently defined read control lines.
The Report Read Controls command displays all the read control lines that you previously
specified by using the Add Read Controls command. The display also includes the
corresponding off-state with each read control line.
Examples
The following example displays a list of the current read control lines:
add read controls 0 r1 r3
add read controls 1 r2 r4
report read controls

Related Commands
Add Read Controls Delete Read Controls

LBISTArchitect Reference Manual, v2017.3 217

September 2017
BIST-Ready Command Dictionary
Report Scan Cells

Report Scan Cells

Scope: Dft mode
Usage
REPort SCan CElls [-All | chain_name…] [-Display DEBug] [{> | >>} file_pathname]
Description
Displays a report or writes a file on the scan cells that reside in the specified scan chains.
The Report Scan Cells command provides a report on the scan cells within specific scan chains.
The following information is provided in the report for each scan cell:
• Chain cell index number (where 0 is the scan cell closest to the scan-out pin)
• Scan chain in which the scan cell resides (chain1, chain2,… are the default chain names,
if reporting scan cells on inserted scan chains)
• Scan group in which the scan chain resides (dummy is the default group name, if
reporting scan cells on inserted scan chains)
• Instance name of the scan cell
• Library model name of the scan cell (if -Filename is not specified)
• Scan output port name of the scan cell (if -Filename is not specified)
• Global clock for each scan cell (if -Filename is not specified)
• Polarity of the global clock, whether the clock is leading or trailing edge (if -Filename is
not specified)
• Associated lockup latch for each scan cell (if -Filename is not specified)
If you issue the command without specifying any arguments, LBISTArchitect displays a report
on the scan cells for all scan cells in existing scan chains, and also scan cells from the inserted
scan chains.
If you issue the command with the -Filename switch, then LBISTArchitect writes the scan cells
to a file in the format that can be read by the Insert Test Logic command. The format of the
written file is different than the format of the viewed report. You can optionally edit the scan
cell order in the file before reading the file with the Insert Test Logic command.
Arguments
• -All | chain_name…
An optional switch or repeatable string. The -All switch specifies to display the scan cells
for all scan chains. This is the default. The repeatable string specifies the scan chains whose
scan cells you want to display.

218 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Scan Cells

• -Display DEBug
A switch and literal that displays the reported information graphically in the debug
DFTVisualizer window.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays a list of all scan cells, in the DFT system mode:
add scan groups group1 scanfile
add scan chains chain1 group1 indata2 outdata4
set system mode dft
report scan cells
------------------------------------------------------------
CellNo ChainName GroupName Pathname CellName ScanOut Clock
ClockPolarity Lockup
------------------------------------------------------------
0 chain1 group1 /MQ_I400 sffr Q clk2 (-)
1 chain1 group1 /FH_I400 sffr QB clk2 (-)
2 chain1 group1 /FQ_I10 sffr QB clk2 (-)
3 chain1 group1 /RP_I10 sffr Q clk1 (+)
lockup1 FD4SQA
4 chain1 group1 /IS_I10 sffr Q clk1 (+)
5 chain1 group1 /CZ_I400 sffr QB clk1 (+)

Column 1 displays the chain cell index number; 0 is the scan cell closest to the scan-out pin.
Column 2 column displays the chain name where the scan cell resides.
Column 3 column displays the group name where the scan cell resides.
Column 4 column displays the gate name of the scan cell.
Column 5 column displays the library model name for the scan cell.
Column 6 column displays the scan out port of the scan cell.
Column 7 column displays the clock for the scan cell.
Column 8 column displays the polarity of the clock of the scan cell.
Column 9 displays “lockup”, if a lockup latch is inserted in the scan_out of this scan cell.
Related Commands
Add Scan Chains Report Sequential Instances
Add Scan Groups

LBISTArchitect Reference Manual, v2017.3 219

September 2017
BIST-Ready Command Dictionary
Report Scan Chains

Report Scan Chains

Scope: All modes
Usage
REPort SCan CHains [{> | >>} file_pathname]
Description
Displays a report on all the current scan chains.
By default, the output of the command is written to the transcript window of the tool. The
Report Scan Chains command provides the following information in a report for each scan
chain:
• Name of the scan chain
• Name of the scan chain group
• Scan chain input and output pins
• Length of the scan chain
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Related Commands
Add Scan Chains Delete Scan Chains

220 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Scan Enable

Report Scan Enable

Scope: DFT
Usage
REPort SCan Enable [{> | >>} file_pathname]
Description
Reports on scan_enable signals and associated scan chains. The following details are reported
for each scan enable signal:

• Primary input port (top-level scan enable port)

• Internal connection node (internal instance pin designated as the scan enable signal
driver)
• Associated scan chain(s)
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example reports the scan_enable details for each of four scan chains.
// command: report scan enable
--------------------------------------------------------
Primary Input Internal Connection Node Scan Chain
--------------------------------------------------------
/scan_en -- c3
c4
-------------------------------------------------------------
/SEN /I_IOPADS/I_SEN/I0/X c1
c2
-------------------------------------------------------------

Related Commands
Set Scan Enable Set Scan_enable Sharing

LBISTArchitect Reference Manual, v2017.3 221

September 2017
BIST-Ready Command Dictionary
Report Scan Groups

Report Scan Groups

Scope: All modes
Usage
REPort SCan Groups [{> | >>} file_pathname]
Description
Displays a report on all the current scan chain groups.
By default, the output of the command is written to the transcript window of the tool. The
Report Scan Groups command provides the following information in a report for each scan
chain group:
• Name of the scan chain group
• Number of scan chains within the scan chain group
• Number of shifts
• Name of the test procedure file, which contains the information for controlling the scan
chains in the reported scan chain group
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Related Commands
Add Scan Groups Delete Scan Groups

222 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Scan Models

Report Scan Models

Scope: All modes
Usage
REPort SCan Models
Description
Displays the sequential scan models currently in the scan model list.
The Report Scan Models command displays sequential models which you previously added to
the scan model list by using the Add Scan Models command.
Examples
The following example displays all the sequential scan models from the scan model list:
set system mode dft
add scan models d_flip_flop1 d_flip_flop2
report scan models

Related Commands
Add Scan Models Delete Scan Models

LBISTArchitect Reference Manual, v2017.3 223

September 2017
BIST-Ready Command Dictionary
Report Scan Pins

Report Scan Pins

Scope: All modes
Usage
REPort SCan PIns [{> | >>} file_pathname]
Description
Displays all previously assigned scan input, output, and clock names.
By default, the output of the command is written to the transcript window of the tool. The
Report Scan Pins command displays the user-specific names that you have added to the scan
input and scan output pins of the scan chains.
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays all scan input and scan output names for the scan chains.
add scan pins chain1 scan_in1 scan_out1
add scan pins chain2 scan_in2 scan_out2
report scan pins
List of scan chains, input and output pins:
chain1 scan_in1 scan_out1
chain2 scan_in2 scan_out2

Related Commands
Add Scan Pins Delete Scan Pins

224 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Sequential Instances

Report Sequential Instances

Scope: All modes
Usage
REPort SEquential Instances [-SCannable] [-NONscannable] [-DEFINED_Scan]
[-DEFINED_Nonscan] [-IDentified] [-Unidentified] [-STitched]
[{-Polarity + | -}] [{-CLock clockname…}] [{-CHain chainname…}]
[{-Library_model modelname…}] [{{-INstance | -Module} object_name…}] [-NOHeader]
[-NOFooter] [-NOVerbose] [{-Format format_code…}] [-DRiven_sen_info] [{> | >>}
file_pathname]
Description
Displays information and testability data for sequential instances.
The Report Sequential Instances command displays the sequential instances of the design with
various filtering options. It also displays the total number of the reported instances at the end of
the report.
This command has several filtering options. When you specify multiple filters, the command
prints only the sequential instances that satisfy every filtering condition. If you specify no
filters, the command prints all types of sequential instances in the design.
You can also control the output of the command, such as printing header and footer information,
and formatting the output columns.
Arguments
• -SCannable
An optional switch that specifies LBISTArchitect to print the sequential instances that can
be placed into scan chains.
• -NONscannable
An optional switch that specifies LBISTArchitect to print the sequential instances that
cannot be placed into scan chains. The scannability condition of a sequential instance is
determined by the DRC rule checker.
• -DEFINED_Scan
An optional switch that specifies LBISTArchitect to print the sequential instances that are
defined scannable by the user.
• -DEFINED_Nonscan
An optional switch that specifies LBISTArchitect to print the sequential instances that are
defined non-scannable by the user.

LBISTArchitect Reference Manual, v2017.3 225

September 2017
BIST-Ready Command Dictionary
Report Sequential Instances

• -IDentified
An optional switch that specifies LBISTArchitect to print the sequential instances that are
identified to be scannable by LBISTArchitect. This is only valid after executing a Run
command.
• -UNidentified
An optional switch that specifies LBISTArchitect to print the sequential instances that are
not identified to be scannable by LBISTArchitect.
• -STitched
An optional switch that specifies LBISTArchitect to print the sequential instances that are
already placed in scan chains. Such instances cannot hold the scannable or non-scannable
conditions.
• -Polarity + | -
An optional switch and a sign character that specify LBISTArchitect to print the sequential
instances that are clocked by stable_low (+) or stable_high (-) clocks.
• -INstance object_name…
An optional switch and a list of strings that specify LBISTArchitect to report the sequential
instances that reside under certain instances. The instances are specified by their pathname
in the list of strings.
• -Module object_name…
An optional switch and a list of strings that specify LBISTArchitect to report the sequential
instances that reside under certain modules. The modules are specified by their name in the
list of strings.
• -NOHeader
An optional switch that specifies LBISTArchitect to not print the header information in the
output.
• -NOFooter
An optional switch that specifies LBISTArchitect to not print the footer information in the
output. The footer information includes the total number of reported instances.
• -NOVerbose
An optional switch that specifies LBISTArchitect to not print the body of the report output,
which is all the information except the header and the footer.
• -Format format_code…
An optional switch and a list of strings that specify LBISTArchitect to print output columns
as specified in the list of format_codes. When this switch is used, only the columns specified
by their format_codes are printed. Also, they are printed in the order the format_codes are
specified in the list.

226 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Sequential Instances

The output of the command has possible seven columns of information. A format_code is
associated with each column as follows.

Table 2-7. Output Formatting

Format_code Description
PN Pathname
MN Module Name
GI Gate ID
CN Clock Name
CP Clock Polarity
TY Type
ST Status

The information contained in each column in Table 2-7 is described as follows:

o PN: Holds the instance pathname of the sequential instance.
o MN: Holds the library module name of the sequential instance.
o GI: Holds the flattened netlist gate ID of the sequential instance and therefore works
only in DFT mode while flattened netlist is not freed in the process (before test logic
insertion). This column is by default not included in the output.
o CN: Holds the name of the primary input pin that clocks the sequential instance. If
this pin is not identified by LBISTArchitect this column holds either “Unknown” or
“Test-logic”. The string “Test-logic” is printed if you issue the command “Set Test
Logic -clock ON -reset ON…” and the DRC rule checker determines that test logic
is needed for the sequential element to be scannable.
o CP: Holds the polarity information of the clock of the sequential instance.
o TY: Holds one of following strings for the sequential instance:
• “Unknown”, if in SETUP mode
• “Scannable”
• “Pos-scannable”
• “Non-scannable”
• “Ignored”
• “Trans-latch”
• “Constant”

LBISTArchitect Reference Manual, v2017.3 227

September 2017
BIST-Ready Command Dictionary
Report Sequential Instances

• chain name or “DFT”, after test logic insertion. If the sequential instance is part
of a scan chain, its chain name is printed. If the sequential instance is either a test
logic control/observe point or a lockup latch that is inserted by LBISTArchitect,
the string “DFT” is printed.
o ST: Holds either one of the following:
• “None” before scan identification process
• “Unidentified”, before scan identification process
• “Identified”, after scan identification process
• “Defined-scan”
• “Defined-nonscan”
• scan cell number, after test logic insertion
• -DRiven_sen_info
An optional switch that reports sequential instances with functionally-driven scan enable
pins. The scan enable pin is considered functionally driven if the driving pin is a PI pin or an
output pin of a library instance that is not an inverter or buffer. The driver and driven pins
can be at different levels of hierarchy where the buffers and inverters between them are
transparent to the tool. When functionally-driven sequential instances are found, they are
added to the non-scan instance list and a warning message displays.
This switch also writes out a dofile (delete_nonscan_instances_for_driven_sen.dofile) that
can be used to remove the functionally-driven sequential instances from the non-scan cell
list and include them back into scan insertion. This also preserves the original connection to
the driving scan enable signal for these sequential instances.
Alternately, if the reported global scan enable pin (driving pin) is common to all reported
sequential instances, you can define it as the global scan enable pin with the Set Scan Enable
command in a new LBISTArchitect session. Once defined, it will be used as the scan enable
signal during scan insertion.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays all types of sequential instances in the design.
report sequential Instances
-------------------------------------------------------------

228 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Sequential Instances

FORMAT: PathName ModelName ClockName ClockPolarity Type Status

-------------------------------------------------------------
k1/l1 dffr clk1 (+) Scannable Identified
k2/m2 dffr clk1 (-) NonScannable UserNonScan
-------------------------------------------------------------
Number of instances: 2

This example reports on instances using a specified output format:

report sequental inst -chain chn1 -inst /a1/b1 /a1/b2 -format ST TY PN CN CP
-------------------------------------------------------------
FORMAT: Status Type Pathname ClockName ClockPolarity
-------------------------------------------------------------
23 chn1 a1/b1/c1 clk1 (+)
24 chn1 a1/b1/c2 clk1 (+)
78 chn1 a1/b2/d1 clk1 (+)
96 chn1 a1/b2/d2 clk2 (-)
-------------------------------------------------------------
Number of instances: 4

Related Commands
Echo Report Scan Cells
Report Circuit Components Run
Report Dft Check Set Scan Enable

LBISTArchitect Reference Manual, v2017.3 229

September 2017
BIST-Ready Command Dictionary
Report Statistics

Report Statistics
Scope: All modes
Usage
REPort STAtistics [-Instance instance_pathname] [{> | >>} file_pathname]
Description
Displays a detailed report of the design’s statistics.
By default, the output of the command is written to the transcript window of the tool. The
Report Statistics command displays a detailed statistics report to the screen. The report includes
the following information when in Setup and Dft modes:
• Total number of sequential instances
• Number of defined non-scan instances
• Number of non-scan instances identified by the DRC
• Number of defined scan instances
• Number of scan instances identified by the DRC
• Number of identified scan instances
• Number of scannable instances with test logic
• Number of preexisting scan chains
The report includes the following fault simulation information when in Bist mode:
• The current number of collapsed and total faults in each class. The report does not
display fault classes with no members.
• The percentage of test coverage, fault coverage, and ATPG effectiveness for both
collapsed and total faults
• The total numbers for the following:
o Total patterns simulated in the preceding fault simulation process. This subgroup
may additionally contain total numbers for the following internal patterns sets:
basic scan patterns
Clock_po patterns
Ram_sequential patterns
Clock_sequential patterns
o Total patterns currently in the test pattern set
o Total CPU time

230 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Statistics

If a pattern type has no patterns, the report does not display the count for that type. If all patterns
are basic patterns, it will not display any count. And, it counts clock_sequential patterns that are
also clock_po only as clock_sequential patterns.
Arguments
• -Instance instance_pathname
An optional switch and string pair that allows fault statistics to be reported for a specific
instance. The instance_pathname is the name of a circuit block whose statistics you want to
report. Only fault statistics are affected by this option; pattern count statistics apply to the
entire design.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays the statistics report after performing the scan identification
process in Dft mode:
add clocks 0 clock
set system mode dft
run
report statistics
Total number of sequential instances =40
Number of defined nonscan instances =5 (12.50%)
Number of nonscan instances identified by drc =5 (12.50%)
Number of defined scan instances =5 (12.50%)
Number of scan instances identified by drc =5 (12.50%)
Number of identified scan instances =5 (12.50%)
Number of scannable instances =10
Number of scannable instances with test logic =5

LBISTArchitect Reference Manual, v2017.3 231

September 2017
BIST-Ready Command Dictionary
Report Subchain Clocks

Report Subchain Clocks

Scope: All modes
Usage
REport SUbchain CLocks subchain_name
Description
Reports on subchain clocks defined with the Add Subchain Clocks command.
Arguments
• subchain_name
A required string that specifies the name of a subchain.
Examples
add sub chains MULTIBITSFF3 chain1 SI SO 4 mux_scan S library_model
add subchain clocks chain1 0 RESET -reset
add subchain clocks chain1 0 SET -set
add subchain clocks 0 CK -first_cell_clock -leading_edge
add subchain clocks 0 CK -last_cell_clock -leading_edge
report subchain clocks chain1
// clock name type off_state edge
// ---------- ---- --------- -----
// RESET reset 0
// SET set 0
// CK first cell clock 0 leading edge
// CK last cell clock 0 leading edge

delete subchain clocks chain1 CK

report subchain clocks chain1
// clock name type off_state edge
// ---------- ----- --------- ------
// RESET reset 0
// SET set 0

Related Commands
Add Subchain Clocks Delete Subchain Clocks

232 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Test Logic

Report Test Logic

Scope: All modes
Prerequisites
You must first use either the Synthesize or the Insert Test Logic command to add the test logic
or test points.
Usage
REPort TEst Logic [-Instance | -Module | -Summary | -Location] [{> | >>} file_pathname]
Description
Displays the test logic added during the scan insertion process.
The Report Test Logic command displays information about the test logic that LBISTArchitect
added during the scan insertion process as a result of the Set Test Logic and Add Test Points
commands.
Arguments
• -Instance
An optional switch that displays the list of instance pathnames and the corresponding DFT
library model that LBISTArchitect inserted as test logic and test points. This option also
includes a summary of the number of each instance-based DFT library model that
LBISTArchitect inserted. This is the default.
• -Module
An optional switch that displays the list of module names, the list of instance pathnames,
and the corresponding DFT library models that LBISTArchitect inserted as test logic and
test points. This option also includes a summary of the number of each module-based DFT
library model that LBISTArchitect inserted.
• -Summary
An optional switch that displays a summary that contains the number of each module and
instance-based DFT library model that LBISTArchitect inserted.
• -Location
An optional switch that displays the pin pathname where LBISTArchitect inserted test logic
and identifies whether it was a result of the test logic settings or test points that you
specified.
• > 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.

LBISTArchitect Reference Manual, v2017.3 233

September 2017
BIST-Ready Command Dictionary
Report Test Logic

• >> file_pathname
An optional redirection operator and pathname pair, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example uses both test logic and test points. The report displays the locations
where LBISTArchitect inserted the test logic as a result of both the Add Test Point command
and the Set Test Logic command:
add cell models and2a -type and
add cell models inv1a -type inv
add cell models mux1a -type mux s a b
add test point /I_6_16/cp control and2a control_input
set test logic -set on -reset on
set system mode dft
run
synthesize
report test logic -location
/I_6_16/reset (test points)
/I_7_16/set (scan cell)

Related Commands
Add Test Points Echo
Delete Test Points Report Test Points

234 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Test Points

Report Test Points

Scope: All modes
Usage
REPort TEst Points [-Full | -Control | -Observe | -Lockup] [{> | >>} file_pathname]
Description
Displays the test point specifications you created with Add Test Points command and any test
points that you enabled LBISTArchitect to automatically identify.
The Report Test Point command displays the test point specifications for both user-defined and
system-defined test points. User-defined test points are those that you created by using the Add
Test Point command. However, LBISTArchitect does not actually generate the test point
circuitry until you issue either the Synthesize or the Insert Test Logic command.
System-defined test points are those that LBISTArchitect automatically identifies and inserts
based on the information you provide with the following commands:
• Setup Scan Identification
• Setup Test_point Identification
• Run
• Setup Test_point Insertion
• Insert Test Logic
• Synthesize
The report marks the system-defined test points with “[Selected]” prior to the test point
information.
Arguments
• -Full
An optional switch that specifies to display all of the information available on both control
and observe test points for both the user-defined and the system-defined test points. This is
the default.
• -Control
An optional switch that specifies to display all the test point definitions (both user- and
system-defined) that are for the purpose of enabling better test coverage in design areas
where, previously, LBISTArchitect could not force certain state values.
• -Observe
An optional switch that specifies to display all the test point definitions (both user- and
system-defined) that are for the purpose of enabling better test coverage by allowing the
tester access to certain fault effects.

LBISTArchitect Reference Manual, v2017.3 235

September 2017
BIST-Ready Command Dictionary
Report Test Points

• -Lockup
An optional switch that specifies to display all test points (both user- and system-defined)
with added lockup latches.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example creates one user-defined control point and one user-defined observe
point, and then reports their definitions:
add test points /I_7_16/q Observe observe_output
add cell models and2a -type and
add cell models sdff1a -type sdff clk data
add test points /I_6_16/reset control and2a control_input -new_scan_cell sdff1a
report test points
Control: /I_6_16/reset Control and2a control_input -New_scan_cell sdff1a
// (internal scan)
Observe: /I_7_16/q Observe observe_output

Related Commands
Add Test Points Report Test Logic
Delete Test Points Setup Scan Identification
Echo Setup Test_point Identification

236 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Testability Analysis

Report Testability Analysis

Scope: Dft mode
Prerequisites
You must first issue the Analyze Testability command to calculate the values on which to
report.
Usage
REPort TEstability Analysis [pathname] [-Controllability | -OBservability]
[{-Number integer} | {-Percent integer} | {-OVer integer}]
Description
Displays the results of the Analyze Testability command.
The Report Testability Analysis command displays a columnar list of either the controllability
or observability values for each pin in the flattened design. The -Controllability and
-Observability switches determine the column definitions.
The Analyze Testability command calculates the controllability and observability values for
each gate in the flattened design. If the design’s fault coverage, found in the Fault Simulation
phase, is lower than you desire, you can re-invoke the BIST-Ready phase to perform the
testability analysis, which allows you access to the controllability and observability values. You
can then generate test points (either manually or automatically) based on the results of the
testability analysis to help increase the design’s fault coverage.
If you are going to manually investigate the results of the testability analysis and insert user-
defined test points, you need to use the Add Test Points command. If you are going to have
LBISTArchitect automatically identify (system-defined) test points, you need to use a
combination of the Setup Scan Identification, Setup Test_point Identification, and Run
commands.
Arguments
• pathname
An optional string that specifies the instance name for whose pins you want LBISTArchitect
to display the controllability or observability values. The default is all pins for all instances.
• -Controllability
An optional switch that specifies for LBISTArchitect to only display the pin controllability
values. This is the default.

LBISTArchitect Reference Manual, v2017.3 237

September 2017
BIST-Ready Command Dictionary
Report Testability Analysis

The controllability report displays the following information in columnar format:

o The controllability value for the low logic state
o The controllability value for the high logic state
o The primitive gate type
o The gate identification number
o The pathname to the gate
If LBISTArchitect cannot control the inputs of a gate, the report displays NC (non-
controllable) for the corresponding logic state.
• -OBservability
An optional switch that specifies for LBISTArchitect to only display the pin observability
values. The observability report displays the following information in columnar format:
o The observability value
o The primitive gate type
o The gate identification number
o The pathname to the gate
If LBISTArchitect cannot observe the outputs of a gate at any observation point, the report
displays NO (non-observable).
• -Number integer
An optional switch and integer pair that specifies the maximum number of pins whose
values you want to display. If you specify the -Number switch, you must provide the
associated integer.
• -Percent integer
An optional switch and integer pair that specifies the percentage of the total number of
available design pins whose values you want to display. You determine the total number of
available design pins by whether you specify or do not specify the instance pathname
argument. If you specify the -Percent switch, you must provide the associated integer.
• -OVer integer
An optional switch and integer pair that specifies the minimum controllability or
observability values whose pins you want to display. If you specify the -Over switch, you
must provide the associated integer.

238 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Testability Analysis

Examples
The following example displays the controllability values of five percent of all the pins in the
design.
set system mode dft
setup scan identification none
analyze testability -scoap_only
setup test_point identification -control 1
run
// Performing test_point identification ...
// Number of control points to be identified = 1
// Number of observe points to be identified = 0
// 1: CV1=16458417 gate_index=3805 INV /CNTR/U783/ZN

report testability analysis -controllability -percent 5

NC 0 BUF 25 /I_6_16
0 NC INV 27 /I_7_14
100 1 BUF 39 /I_8_21

The report displays the controllability value for the low logic state (where NC means non-
controllable), the controllability value for the high logic state, the primitive gate type, the gate
identification number, and the pathname to the gate.
Related Commands
Analyze Testability

LBISTArchitect Reference Manual, v2017.3 239

September 2017
BIST-Ready Command Dictionary
Report Tied Signals

Report Tied Signals

Scope: All modes
Usage
REPort TIed Signals [-Class {Full | User | System}]
Description
Displays a list of the tied floating signals and pins.
The Report Tied Signals command displays either the user class, system class, or full classes of
tied floating signals and pins. If you do not specify a class, the command displays all the tied
floating signals and pins.
Arguments
• -Class Full | User | System
An optional switch and literal pair that specifies the source (or class) of the tied floating
signals or pins which you want to display. The valid literals are as follows:
Full — A literal that specifies to display all the tied floating signals or pins in the user
and system class. This is the default.
User — A literal that specifies to only display the tied floating signals or pins that you
created by using the Add Tied Signals command. This includes all instance-based
blackbox tied signals.
System — A literal that specifies to only display the tied floating signals or pins
described in the netlist.
Examples
The following example will display the tied signals from the user class.
add tied signals 1 vcc vdd
report tied signals -class user

Related Commands
Add Tied Signals Setup Tied Signals
Delete Tied Signals

240 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Timeplate

Report Timeplate
Scope: All modes except Setup mode
Usage
REPort TImeplate timeplate_name | -All
Description
Displays the specified timeplate.
The Report Timeplate command displays all timeplates or the specified timeplate.
Arguments
• timeplate_name
A string that specifies which timeplate to display.
• -All
A switch which specifies for the tool to display all timeplates. This is the default.
Related Commands
Add Scan Groups Write Procfile
Read Procfile

LBISTArchitect Reference Manual, v2017.3 241

September 2017
BIST-Ready Command Dictionary
Report Variables

Report Variables
Scope: All modes
Usage
REPort VAriables
Description
Displays user-defined variables and values.
The Report Variables command displays the list of user-defined variables and their
corresponding values. This list does not include environment variables defined in the parent
shell environment.
Variables are defined, referenced, and reported on in the following manner:
1. Definition — Use the following syntax to create and set a variable’s value. Variables
can be defined from the tool’s command line, throughout a dofile, or from a startup file.
$variable = value

2. Referencing — To refer to a variable causes its value to be substituted into a command.

Multiple variable references are allowed per tool command. Variables must be defined
before they are referenced.
${variable}

Note
If a variable is not meant to be concatenated with any other strings, it can simply be
referred to as $variable-name as in:
insert test logic -max_length $MAX_SCAN_LEN -scan on

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

1. Reporting — Use the Report Variables command to display user-defined variables and
values.
REPort VAriables

Examples
This first example defines four variables, refers to them within tool commands, and displays a
list of all variables:

242 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Report Variables

...
set system mode dft
$design_base_file = scan
$design_base_dir = /$USER/dft_scan_designs
$max_scan_len = 100
$revision = 1.42
run
synthesize
write netlist -verilog ${design_base_dir}/${design_base_file}.v
report variables
design_base_dir /$USER/dft_scan_designs
design_base_file scan
revision 1.42
max_scan_len 100

Note
As $USER is defined in the parent shell environment, it is available for use within the
tool and in other variable definitions.

This second example invokes LBISTArchitect with a parameterized dofile:

A UNIX script file can contain the variable settings:
#!/bin/csh
setenv MY_DESIGN m8051
setenv NUM_SCAN_CHAINS 8
lbistarchitect -verilog ${MY_DESIGN}.v -library atpg.lib -dofile scan.do

And the scan.do file can reference the variables:

echo "... processing $MY_DESIGN "

analyze control signals -auto_fix

set test logic -reset on -set on
set system mode dft
setup scan identification full_scan
run

echo "... insert $NUM_SCAN_CHAINS scan chains"

insert test logic -number $NUM_SCAN_CHAINS

report scan chains > reports/${MY_DESIGN}.chain.report

report test logic -summary >
reports/${MY_DESIGN}.testlogic.report

write netlist netlists/${MY_DESIGN}_scan.v -verilog -rep

write atpg setup scripts/${MY_DESIGN} -rep

exit

Related Commands
Printenv

LBISTArchitect Reference Manual, v2017.3 243

September 2017
BIST-Ready Command Dictionary
Report Write Controls

Report Write Controls

Scope: All modes
Usage
REPort WRite Controls
Description
Displays the currently defined write control lines and their off-states.
The Report Write Controls command displays the write control lines, with corresponding off-
states, that you previously added by using the Add Write Controls command.
Examples
The following example adds four write control lines and then displays a list of the control line
definitions:
add write controls 0 w1 w3
add write controls 1 w2 w4
report write controls

Related Commands
Add Write Controls Delete Write Controls

244 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Reset State

Reset State
Scope: All modes
Usage
RESet STate
Description
Removes all instances from both the scan identification and test point identification lists
identified during a run.
The Reset State command removes scan instances or test points identified with the Run
command. However, if you have stitched the scan chain or inserted test points, this command
has no effect.
Examples
The following example performs a full scan identification process, then removes the identified
scan instances and performs test point identification run:
set system mode dft
setup scan identification full_scan
run
report sequential instances
.
.
.
reset state
setup scan identification none
report sequential instances
run
.
.
.

LBISTArchitect Reference Manual, v2017.3 245

September 2017
BIST-Ready Command Dictionary
Restore Test_points

Restore Test_points
Scope: Dft mode
Usage
REStore TEst_points tpfile
Description
Reads in the specified MTPI test points information text file.
The Restore Test_points command is for use in a flow in which you have inserted test points
and are trying to achieve timing closure. Because following this flow could result in a reduction
in fault coverage, it is assumed that timing closure is the primary objective.
The flow consists of these steps:
1. Run MTPI and save the test point-inserted netlist. Archive the test point information to
tpfile with Archive Test_points.
2. Run static timing analysis on the saved netlist to identify new paths that violate timing.
Correlate those paths to the MTPI-inserted test points.
3. Re-invoke BIST-Ready on the original core netlist and read in tpfile with the Restore
Test_points command. Remove the test points associated with the timing violations
using the Delete MTPI Control_point or Delete MTPI Observe_point commands. Insert
test logic and save the netlist
Argument
• tpfile
A required string that specifies an MTPI test points file that you saved using the Archive
Test_points command. This is a plain text file, not a list of BIST-Ready commands.
Examples
The following example restores an archived test point file, removes a test point that causes a
timing violation, inserts the new test points, and writes out the new core netlist and the BIST
netlist for use by the BIST Controller Synthesis phase.
restore test_points mtpi1.arc
delete mtpi control_point u7/L_FA_reg_4_/Q or 3
insert test logic -test_point on -scan off
write netlist netlists/m8051_core_bist.v -verilog -rep
write bist setup netlists/m8051_top_bist.v -verilog rtl.setup -rep

246 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Restore Test_points

Related Commands
Archive Test_points Delete MTPI Observe_point
Delete MTPI Control_point Write Static_timing Setup
Load Static_timing Report

Command Summary

LBISTArchitect Reference Manual, v2017.3 247

September 2017
BIST-Ready Command Dictionary
Ripup Scan Chains

Ripup Scan Chains

Scope: Dft mode
Usage
RIPup SCan Chains {-All | chain_name…} [-Output] [-Keep_scancell [Off | Tied | Loop |
Buffer]] [-Model model_name]
Description
Removes the specified scan chains from the design.
The Ripup Scan Chains command removes scan chains that LBISTArchitect placed during the
scan insertion process. You can remove (rip up) either all the scan chains or individual scan
chains. You can also rip up the scan chain output pin.
If you only wish to remove a scan chain definition that you previously created with the Add
Scan Chains command, use the Delete Scan Chains command.
Note
If the design contains test logic in addition to scan circuitry, this command only removes
the scan circuitry, not the test logic.

Arguments
• -All
A switch that specifies to remove all scan chains.
• chain_name
A repeatable string that specifies the names of the scan chains that you want to remove.
• -Output
An optional switch that specifies that the existing scan chain output pins are to be ripped up
together with the scan chains.
• -Keep_scancell [Off | Tied | Loop | Buffer]
An optional switch and literal pair that specifies removal of the connection between the scan
input/output ports of each scan cell. The connections of all other ports are not altered and the
scan cells are not mapped to their nonscan models. If this switch is not specified, the default
is to remove the connections of all test ports and map the scan cells back to their original
nonscan model.
Off — LBISTArchitect disconnects the scan_out pin and scan_in pin and leaves them
dangling. This is the default.
Tied — LBISTArchitect disconnects the scan_out pin and scan_in pin and ties them to
ground.
Loop — LBISTArchitect disconnects the scan_out pin and scan_in pin and connects
them to each other as a self-loop for each scan cell.

248 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Ripup Scan Chains

Buffer —LBISTArchitect disconnects the scan_out pin and scan_in pin and connects
them to each other as a self-loop with a buffer in between for each scan cell.
• -Model model_name
An optional switch and string pair that specifies the name of a buffer in the DFT library for
LBISTArchitect to insert in the self-loop. This option is only valid if you specify the “-
Keep_scancell Buffer”. You must first identify the buffer with either the Add Cell Models
command or with the cell_type library attribute. If you do not specify the -Model switch, by
default, LBISTArchitect uses the first buffer model in the buffer cell model list (view with
the Report Cell Models command).
Examples
The following example performs the scan insertion process with unlimited scan chain lengths,
then removes those scan chains and re-runs the scan insertion process with a maximum scan
chain length of 100:
add clocks 0 clock
set system mode dft
setup scan identification full_scan
run
setup scan insertion -seb MY_SEN
insert test logic -nolimit
report scan chains
ripup scan chains -all
set system mode setup
set system mode dft
reset state
setup scan identification full_scan
run
insert test logic -max_length 100
report scan chains

Related Commands
Add Scan Chains Report Scan Chains

LBISTArchitect Reference Manual, v2017.3 249

September 2017
BIST-Ready Command Dictionary
Run

Run
Scope: Dft mode
Usage
RUN
Description
Runs the scan or test point identification process.
The Run command performs the scan or test_point identification process in Dft mode
depending on the identification type you set with the Setup Scan Identification command. The
Run command performs the scan identification process, as indicated by the Setup Scan
Identification command (if the identification type is set to -Sequential), and the test_point
identification process, as indicated by the Setup Test_point Identification command.
During the identification run, LBISTArchitect displays progress messages. The number
indicates the number of instances currently identified for scan (added to the scan candidate list).
Number of targeted sequential instances = 498
// Performing scan identification ...
// Total sequential instances identified = 498

Examples
The following example runs a scan identification process:
set system mode dft
setup scan identification full_scan
run
report scan identification

Related Commands
Setup Scan Identification Setup Test_point Identification

250 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Save History

Save History
Scope: All modes
Usage
SAVe HIstory filename [-Replace]
Description
Saves the command line history file to the specified file.
The Save History command saves the list of previously executed commands in the file that you
specify. You can then execute the file using the Dofile command.
Arguments
• filename
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.
history -nonumbers
add clocks 0 clock
set system mode dft
setup scan identification full_scan
run
setup scan insertion -seb MY_SEN
insert test logic -nolimit
report scan chains
ripup scan chains -all
set system mode setup
set system mode dft
reset state
setup scan identification full_scan
run
insert test logic -max_length 100
report scan chains
history -nonumbers

save history my_history -replace

Related Commands
Dofile
History

LBISTArchitect Reference Manual, v2017.3 251

September 2017
BIST-Ready Command Dictionary
Set Bidi Gating

Set Bidi Gating

Scope: Setup mode
Usage
SET BIdi Gating [OFf | ON | Scan] [-Control {SEn | TEn}] [-Direction {Input | Output}]
[-Top {ALl | primary_bidi_pin...}] [-Force_gating]
Description
Specifies how bidirectional (bidi) pins are controlled during scan chain shifting to prevent
potential bus contention or to ensure an on/off state during testing. When enabled, test logic is
inserted for bidi pins as necessary to control the enable signal and/or the input/output direction
as specified.
By default, when the enable signal of a bidi pin is directly controlled by a primary input, by
TIE0, or by TIE1, no gating is necessary and a force statement for the primary input is added to
the load_unload procedure in the new procedure file. This behavior can be overridden by using
the -Force_gating switch.

You can also specify which enable signal (TEN or SEN) enables bidi pins.
Arguments
• OFf | ON | Scan
Required literal that specifies whether to insert test logic to control the enable lines of bidi
pins during scan chain shifting. For more information on scan chain shifting, see “Test
Logic Insertion” in the Scan and ATPG User’s Manual. Literal options include:
OFf — no test logic is inserted to control bidi pins. Default setting.
ON — test logic is inserted as necessary to control bidi pins.
Scan — inserts test logic on the scan I/O bidi pins to control the direction of the bidi pin
for scan shifting and ensure the success of scan chain tracing. Scan output bidi pins
are gated to be in output mode while all other bidi pins are gated to be in input mode
(Z state on the tester).
• -Control SEn | TEn
An optional switch and literal pair that specifies the enable signal used to control bidi pins.
Options include:
SEn — scan_enable signal. Default setting.
TEn — test_enable signal.
• -Direction Input | Output
An optional switch and literal pair that specifies the direction of the bidi pins specified by
the -Top switch. Options include:
Input — bidi pins are gated so they are in input mode. Default setting.

252 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Bidi Gating

Output — bidi pins are gated so they are in output mode.

• -Top ALl | primary_bidi_pin...
An optional switch and literal or repeatable string pair that specifies which bidi pins are
controlled with the specified enable signal. Options include:
ALl — all bidi pins. Default setting.
primary_bidi_pin — a specified primary bidi pin. Test logic is inserted to ensure that
these bidi pins are controlled as specified.
• -Force_gating
An optional switch that adds test logic to the enable lines of bidirectional pins that are
directly controlled by primary inputs, by TIE1, or by TIE0. When the enable line is directly
controlled by a primary input, DFTAdvisor adds the force statement for this primary input
to the load_unload procedure in the procedure file.
Example 1
The following example uses the Set Bidi Gating command to insert test logic to control all bidi
pins used for scan I/O via the SEN signal, and reports the gated bidi pin.
add clocks 0 clk
setup scan identification full_scan
set tristate gating on
set bidi gating scan
add scan pins c1 bidi_in1/X blkB1/blkA/utri2/A -top io out1
set system mode dft
report dft check -full
-------------------------------------------------------------------------
Bidi Primitive Control Control
Tri-state State Direction Gating ID Signal Driver
-------------------------------------------------------------------------
/bidi_in1 OFF IN YES 20 SEN /or2/Y
/blkB1/blkA/utri3 OFF -- YES 15 SEN /udff0/Q
/blkB1/blkA/utri2 ON -- YES 17 SEN /or2/Y
/blkB1/blkA/utri1 OFF -- YES 16 SEN /or2/Y
-------------------------------------------------------------------------

Example 2
The following example uses the force_gating switch to insert gating logic controlled by the
TEN control signal on the enable line of /uio1 and reports the gated tri-state devices. /uio1 is a
bidirectional device driving primary inout port dinout[1]; its enable signal is directly controlled
by the primary input /io_control1.

set bidi gating on -control ten -direction input -top dinout[1] -force_gating
report dft check -tri

LBISTArchitect Reference Manual, v2017.3 253

September 2017
BIST-Ready Command Dictionary
Set Bidi Gating

-----------------------------------------------------------------------
Bidi Primitive Control Control
Tri-state State Direction Gating ID Signal Driver
-----------------------------------------------------------------------
/uioM OFF IN YES 84 TEN /udff20/QB
/uio3 ON OUT YES 77 SEN /io_control
/uio2 OFF IN NO 76 SEN /io_control
/uio1 OFF IN YES 75 TEN /io_control1
/uio0 OFF IN NO 73 SEN /io_control
-----------------------------------------------------------------------

Related Commands
Report Dft Check Set Test Logic
Report Test Logic Set Tristate Gating
Report Control Signals

254 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set BIST Enables

Set BIST Enables

Note
This command is auto-generated by the BIST-Ready phase and is not intended for
interactive use; it is documented for reference purposes only.

Usage
SET BIst Enables {-Lbist_enable xbnd_enable | -TEST_Obs obs_enable | -TEST_En
cntlpt_enable}…
Description
Specifies the names of the enable signals controlling control points, x-bounding multiplexers,
and observe sink points.
Arguments
For the following three arguments, you can pick one or more, but you must pick at least one.
You should not pick any one argument more than once.
• -Lbist_enable xbnd_enable
A switch and string pair that specifies the name of the signal that enables x-bounding
muxes.
• -TEST_Obs obs_enable
A switch and string pair that specifies the name of the signal that enables observe sink points
in existing scan cells.
• -TEST_En cntlpt_enable
A switch and string pair that specifies the name of the signal that enables control points.
Related Commands

Command Summary

LBISTArchitect Reference Manual, v2017.3 255

September 2017
BIST-Ready Command Dictionary
Set Clock Period

Set Clock Period

Scope: Setup and Dft modes
Prerequisites
You must already have added clkname with the Add Clocks command or the issued the Analyze
Control Signals command with the -auto_fix argument.
Usage
SET CLock Period clkname {{-Period period_in_ns | -Frequency freq_in_MHZ}
[-Waveform edgelist]} | -None
Description
Specifies setup arguments related to the timing of clocks and control signals, or removes all
timing associated with that signal.
You can use the Set Clock Period command to specify the period (frequency) of a clock or
control signal, and optionally you can specify the timing of the rising and falling edges within
the time period. Or, you can use the Set Clock Period command to remove all timing that you
have previously defined with the Set Clock Period command.
LBISTArchitect uses the Set Clock Period command to provide enhanced timing information
for driver file creation by the Write Static_timing Setup command as part of timing closure and
the hand-off to a static timing analysis tool. This value is also used to specify clock timing in the
Synopsys Design Compiler script that is generated during the Bist-Controller generation phase.
Also, the fastest clock as specified through this command, is used for the bist_master clock
during the BIST-Controller generation phase. If you do not specify the periods in the BIST-
Ready or BIST-Controller phases, then the tool uses the clock with the highest loading (number
of flip-flops it drives) as the master clock.
The following is an example of an enhanced driver file:
#DESC: Primetime driver file for static timing analysis in functional mode
#Generated by LBISTArchitect BIST_Ready at Tue May 13 09:56:24

#read design
read_file -f verilog m8051_mtpi.v
current_design m8051

#clock definitions
create_clock NX1 -period 80 -waveform { 0 40 }
create_clock NX2 -period 40 -waveform { 0 20 }

#mtpi signals
set_case_analysis 0 { phase_cntl1 phase_cntl2 phase_cntl3 }

#test enable signals (active high)

set_case_analysis 0 { test_en lbist_en obs_sink_en }

#scan enable signals (active high)

set_case_analysis 0 { scan_en }

256 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Clock Period

report_timing -slack_less 0.0 -max_paths 2000000 -nworst 10000 -nosplit >

m8051_mtpi_func_sta_slack0.rep
exit

Arguments
• clkname
A required string that specifies the name of the clock for which you are setting the period or
frequency.
• -Period period_in_ns
A switch and integer pair that specifies the period for the clock, clkname. The time unit is
nanoseconds (ns).
• -Frequency freq_in_MHZ
A switch and integer pair that specifies the frequency for the clock, clkname. The time unit
is megahertz (Mhz).
• -None
A switch that removes all clock timing information that you have previously defined for the
clock, clkname.
• -Waveform rise_edge fall_edge
An optional switch and double floating-point number triplet that specifies the rise and fall
edge times for the specified clock within the specified time period. If you do not use this
switch triplet, PrimeTime uses a default rising edge of 0 ns and a default falling edge of /2
ns.
Examples
The following example defines the clock, NX1, and the asynchronous reset, clr_input, then adds
timing details:
add clocks 0 NX1
add clocks 1 clr_input
set clock period NX1 -period 6 -waveform 0 3
set clock period clr_input -period 120 -waveform 30 35

Related Commands
Add Clocks Write Static_timing Setup
Analyze Control Signals Load Static_timing Report

Command Summary

LBISTArchitect Reference Manual, v2017.3 257

September 2017
BIST-Ready Command Dictionary
Set Dofile Abort

Set Dofile Abort

Scope: All modes
Usage
SET DOfile Abort ON | OFf | Exit
Description
Lets you specify that the tool complete processing of all commands in a dofile regardless of an
error detection.
By default, if an error occurs during the execution of a dofile, processing stops, and the line
number of the error in the dofile is reported. The Set Dofile Abort command lets you turn this
functionality off so that the tool continues to process all commands in the dofile.
Arguments
• ON
A literal that halts the execution of a dofile upon detection of an error. This is the invocation
default.
• OFf
A literal that forces dofile processing to complete all commands in a dofile regardless of
error detection.
• Exit
A required literal that directs the tool to exit if it detects an error while executing a dofile.
Use this setting to prevent a batch job from hanging at the application prompt when an error
occurs in a dofile.
Examples
The following example sets the Set Dofile Abort command off to ensure that all commands in
test1.dofile are executed.
set system mode dft
set dofile abort off
dofile test1.dofile

Related Commands
Dofile

258 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Drc Handling

Set Drc Handling

Scope: Setup and Dft modes
Usage
SET DRc Handling rule_id [Error | Warning | NOTe | Ignore] [NOVerbose | Verbose]
[NOAtpg_analysis | Atpg_analysis] [-Mode {Sequential | Combinational}]
Description
Specifies how LBISTArchitect globally handles design rule violations.
The Set Drc Handling command specifies the handling of the messages for scan cell RAM rules
checking, Clock rules checking, Data rules checking, Extra rules checking, procedure file
checking, and Trace rules checking. You can specify that the violation messages for these
checks be either error, warning, note, or ignore.
Note
The Set Drc Handling command does not support the scannability (S) rules.

Each rules violation has an associated occurrence message and summary message. The tool
displays only the occurrence message, either for error conditions, or if you specify the Verbose
option for that rule. The tool displays the rule identification number in all rules violation
messages.
The Atpg_analysis option provides full test generation analysis when performing rules checking
for some clock (C) rules, for some data (D) rules, and for some extra (E) rules. For example, if
you specify Atpg_analysis for clock rule C1 and the tool simulates a clock input to be X, the
rule violation occurs when it is possible for the test generator to create a test pattern while that
clock input is on, all defined clocks are set off, and constrained pins are set to their constrained
state.
Note
When you specify Atpg_analysis, the tool requires some additional CPU time and
memory to perform the full test generation analysis. (The Atpg_analysis option is enabled
by default for rules C1, E4, E10, E11 and E13; you can disable it for these rules by
specifying the Noatpg_analysis option.)

Arguments
• rule_id
A required literal that specifies the identification of the exact design rule violation whose
message handling you want to change.
The design rule violations and their identification literals are divided into the following
seven groups: RAM, BIST, Clock, Data, Extra, Procedure, and Trace rules violation IDs.

LBISTArchitect Reference Manual, v2017.3 259

September 2017
BIST-Ready Command Dictionary
Set Drc Handling

• Error
An optional literal that specifies for the tool to both display the error occurrence message
and immediately terminate the rules checking.
• Warning
An optional literal that specifies for the tool to display the warning summary message
indicating the number of times the rule was violated. If you also specify the Verbose option,
the tool also displays the occurrence message for each occurrence of the rules violation.
• NOTe
An optional literal that specifies for the tool to display the summary message indicating the
number of times the rule was violated. If you specify the Verbose option, the tool also
displays the occurrence message for each occurrence of the rules violation.
• Ignore
An optional literal that specifies that the tool not display any rule violation message. The
tool must still check some rules and they must pass to allow certain functions to be
performed later.
• NOVerbose
An optional literal that specifies for the tool to display the occurrence message only once for
the rules violation. This is the default.
• Verbose
An optional literal that specifies for the tool to display the occurrence message for each
occurrence of the rules violation.
• NOAtpg_analysis
An optional literal that specifies for the tool to not use full test generation analysis when
performing rules checking. This is the default.
• Atpg_analysis
An optional literal that specifies for the tool to use full test generation analysis when
performing rules checking for clock rules (like C1, C3, C4, and C5), some D rules (like D6
and D9), and some E rules (like E4, E5, E8, E10, E11, and E12).
Note
If you want the tool to use the constraint values during the D6 rule analysis, you need to
use the Atpg_analysis option.

• -Mode {Combinational | Sequential}

An optional switch and literal for the tool to use with the E10 rule. The Combination option
is the default upon invocation of LBISTArchitect. It performs bus contention mutual-
exclusivity checking. This checking differs from rule E4 in that it does not check for this
condition during test procedures.

260 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Drc Handling

The Sequential option considers the inputs to a single level of sequential cells behaving as
“staging” latches in the enable lines of tri-state drivers. All of the latches found in a back
trace must share the same clock. There must also be only a single clocked data port on each
cell, and both set and reset inputs must be tied (not pin constrained) to the inactive state.
This check ensures that there is no connectivity from the cells in the input cone of the
sequential cells and enables of the tri-state devices except through the sequential cells.
Examples
The following example specifies rule checking E4 to be an error:
add scan groups group1 scanfile
add scan chains chain1 group1 indata2 outdata4
add clocks 1 clock1
add clocks 0 clock2
set drc handling e4 error
set system mode dft

Related Commands
Report Drc Rules

LBISTArchitect Reference Manual, v2017.3 261

September 2017
BIST-Ready Command Dictionary
Set File Compression

Set File Compression

Scope: All modes
Usage
SET FIle Compression [ON | OFf]
Description
Controls whether the tools read and write files with .Z or .gz extensions as compressed files (the
default).
Files that contain large pattern sets consume a very large amount of disk space. Fault lists and
the design data itself also take up a lot of disk space. To conserve this space, the tools normally
store files in one of two compressed formats when you provide a filename with the appropriate
extension, as follows:
• “.Z” specifies to compress the file using the UNIX compress command.
• “.gz” specifies to compress the file using the GNU gzip command. You can control the
type of GNU compression with the Set Gzip Options command.
When compressed file handling is enabled and you provide a filename with either of the above
extensions, a tool will automatically decompress (for reading) or compress (for writing) the
specified file.
The Set File Compression command allows you to turn off the tool’s normal compressed file
handling functionality. This is useful in rare cases where files have either of the compressed file
extensions, but should not be saved or read as compressed files.
Arguments
• ON
An optional literal that enables compressed file handling. This is the default.
• OFf
An optional literal that disables compressed file handling. When set to off, the tools process
.Z or .gz files without using compression.
Examples
Suppose the file testpat.ascii.gz is not a compressed file. The following example disables
compressed file handling so the tool will read testpat.ascii.gz as a normal file rather than as a
compressed file:
set file compression off

The next example re-enables compressed file handling, then saves the file fault.pat in GNU
format:
set file compression on
write netlist verilog.scan.gz -verilog

262 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set File Compression

Related Commands
Set Gzip Options

LBISTArchitect Reference Manual, v2017.3 263

September 2017
BIST-Ready Command Dictionary
Set Gate Level

Set Gate Level

Scope: All modes
Usage
SET GAte Level Primitive | Design | Low_design
Description
Specifies the hierarchical level of gate reporting and displaying.
The Set Gate Level command specifies the hierarchical gate level at which the tool reports and
schematically displays gate information. Once you set the gate level, the tool processes all
subsequent report and display commands using the new gate level.
Arguments
• Primitive
A literal that specifies to display gate information at the built-in primitive gate level.
• Design
A literal that specifies to display gate information at the design library hierarchical gate
level. These are the top level cells of the design library which are instantiated in your design.
This is the default upon invocation of the tool.
• Low_design
A literal that specifies to display gate information at the pseudo-hierarchical gate level. A
pseudo-hierarchical gate is a cluster gate that contains primitive gates and is at the lowest
hierarchy level in the design library. These gates only differ from design level gates if the
library contains macro cells.
Examples
The following example sets the gate report level so that simulated values of the gate and its
inputs are shown (assuming a rules checking error occurred when exiting the Setup system
mode):
add clocks 0 clock
set system mode dft
set gate level primitive
set gate report error_pattern
report gates i_1006/o

Related Commands
Report Gates Set Gate Report

264 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Gate Report

Set Gate Report

Scope: All modes
Usage
SET GAte REport {Normal | Trace | Error_pattern | TIe_value | Constrain_value |
{Drc_pattern procedure_name [time | -All]}
Description
Specifies the additional display information for the Report Gates command.
The Set Gate Report command controls the type of additional information that the Report Gates
command displays. Each Set Gate Report option causes the Report Gates command to provide
different details regarding the gates on which it reports.
When you exit the Setup system mode, the trace and any rules-checking error pattern results
will not be available with the usage of this command.
For information on the format output by the different options in this command, refer to “Report
Gates” on page 195.
Arguments
• Normal
A literal that specifies for the Report Gates command to only display its standard
information. This is the default mode upon invocation of the tool.
• Trace
A literal that specifies for the Report Gates command to display the simulated values of the
gates for the shift patterns. Use the Trace option to determine why a scan chain was not
properly sensitized during the shift procedure.
• Error_pattern
A literal that specifies for the Report Gates command to display the simulated value of the
gates and its inputs for the pattern at which an audit error occurred.
• TIe_value
A literal that specifies for the Report Gates command to display the simulated values that
result from all natural tied gates and learned constant value non-scan cells.
• Constrain_value
A literal that specifies for the Report Gates command to display the simulated values that
result from all natural tied gates, learned constant value non-scan cells, constrained pins,
and constrained cells.
The Report Gates command displays three values which are separated by a slash (/). These
values are the gate constrained value (0, 1, X, or Z), the gate forbidden values (-, 0, 1, Z, or
any combination of 01Z), and the fault blockage status (- or B, where B indicates all fault
effects of this gate are blocked).

LBISTArchitect Reference Manual, v2017.3 265

September 2017
BIST-Ready Command Dictionary
Set Gate Report

• Drc_pattern procedure_name [-All | time]

Two literals and an optional time triplet that specifies the name of the procedure and the
time in the test procedure file that the Report Gates command uses to display a gate’s
simulated value.
You must set the Drc_pattern prior to rules checking and you must re-execute the design
rules checking process, otherwise no data (-) from this option will be available for gate
reporting.
The valid options for use with Drc_pattern are as follows:
procedure_name — A required literal that specifies a procedure in the test procedure
file that you want the Report Gates command to use when displaying the value of a
gate. The valid literals for the procedure_name option are as follows:
Test_setup — this optional procedure sets the state of non-scan elements for the
load_unload procedure.
Load_unload — this required procedure describes how to load and unload data in
the scan chains.
SHIft — this required procedure describes how to shift data one position down the
scan chain.
SKew_load — this optional procedure describes how to propagate the output value
of the preceding scan cell into the master memory element of the current cell
(without changing the slave), for all scan cells.
SHADOW_Control — this optional procedure describes how to load the contents
of a scan cell into the associated shadow.
Master_observe — this procedure describes how to place the contents of a master
into the output of its scan cell.
SHADOW_Observe — this optional procedure describes how to place the contents
of a shadow into the output of its scan cell.
-All — An optional switch that specifies to use all times in the test procedure file. This is
the default.
time — An optional positive integer greater than 0 that specifies a time in the test
procedure file.
Examples
The following example sets the gate report so that simulated values of the gate and its inputs are
shown (assuming a rules checking error occurred when exiting the setup system mode):
set gate report trace
set system mode dft
report gates I_1006/O

Related Commands
Report Gates Set Gate Level

266 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Gzip Options

Set Gzip Options

Scope: All modes
Usage
SET GZip Options [-Path gzip_path] [-Fast | -Best | -integer]
Description
Specifies GNU gzip options to use with the GNU gzip command.
The Set Gzip Options command specifies GNU gzip options the tool will use when compressing
or decompressing files using the GNU gzip command. When file compression handling is
enabled (as described under the Set File Compression command), the tool uses GNU gzip when
processing files having a .gz extension.
Arguments
• -Path gzip_path
An optional literal that specifies the full path gzip_path to a gzip executable file. You need
to provide this pathname only if gzip is not in your normal UNIX search path. If you have
specified a pathname with this option, you can restore the default behavior of using your
UNIX path to find gzip by issuing the command with the -Path gzip option.
The following switches all control the speed of compression:
• -Fast
An optional switch that specifies to use the fastest compression method, which yields the
least compression and corresponds to the gzip -1 option. This is the default.
• -Best
An optional switch that specifies to use the slowest compression method, which yields the
most compression. This corresponds to the gzip -9 option.
The default compression is -6.
• -digit
An optional switch that specifies an integer from 1 to 9 that the tool passes to gzip to control
the rate of compression. You obtain the least amount of compression with -1, the greatest
amount of compression with -9.
Examples
The following example ensures file compression is enabled, sets gzip compression to the fastest
method, then saves a file using the .gz file naming extension in order to activate gzip file
compression handling:
set file compression on
set gzip options -fast
write netlist verilog.scan.gz -verilog

LBISTArchitect Reference Manual, v2017.3 267

September 2017
BIST-Ready Command Dictionary
Set Gzip Options

Related Commands
Set File Compression

268 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Identification Model

Set Identification Model

Scope: Setup mode
Usage
SET IDentification Model [-Clock {Original | None | Extra}] [-Disturb {ON | OFf}]
Description
Specifies the simulation model that LBISTArchitect uses to imitate the scan operation during
the scan identification process.
The Set Identification Model command specifies a simulation model needed to imitate scan
operation during scan identification; before real scan chains are inserted.
In normal scan operation, after LBISTArchitect loads values into the scan cells, a scan memory
element should not change its scan-in value until the loaded value is used. To achieve this scan
cell stability, all the clocks of a scan cell should be at their off-state. However, because the
implementation of scan chains is not done yet, LBISTArchitect does not yet know its ability to
control all the clocks. Therefore, the Set Identification Model command allows you three -Clock
options, along with the -Disturb argument, to specify how LBISTArchitect is to handle scan
operation during the scan identification process.
The scan identification process is performed with the Run command and this is the time when
LBISTArchitect selects the non-scan cells that are to be replaced with the corresponding scan
cell. If you want to display the current settings for the scan identification model, you can use the
Report Environment command.
During the scan identification process, LBISTArchitect automatically decides which nonscan
cells require extra logic to fix their clock behavior. When LBISTArchitect performs the scan
identification, it processes each nonscan cell separately. By default, the scan identification
model specifies for LBISTArchitect to use the -Clock Original option for nonscan cells that do
not require the extra logic to control its clocks, and the -Clock Extra option for the non-scan
cells that do require the extra logic for clock controllability.
Arguments
• -Clock Original | None | Extra
An optional switch and literal pair that determines the effect of the clocks on scan memory
elements values. The three -Clock options are as follows:
Original — A literal specifying that scan memory elements operate as their current clock
configuration. This is the default for nonscan cells that LBISTArchitect determines
do not require extra logic for controllability of that nonscan cell’s clocks. If you
specify this option, then LBISTArchitect does not add any extra logic, and uses the
original clock configuration for each nonscan cell on a global design-wide basis.
None — A literal specifying that after scan loading, scan memory elements can hold
their value for one time frame, regardless of their clock values.

LBISTArchitect Reference Manual, v2017.3 269

September 2017
BIST-Ready Command Dictionary
Set Identification Model

Extra — A literal specifying that external controllable clocks replace the original clocks
so that the scan cells are capable of holding their scan values right after scan loading.
This option is the default for nonscan cells that LBISTArchitect determines do
require extra logic for controllability of that nonscan cell’s clocks. If you specify this
option, then LBISTArchitect adds extra logic to every nonscan cell on a global
design-wide basis.
• -Disturb ON | OFf
An optional switch and literal pair that determines the effect of scan loading on non-scan
memory elements. The two -Disturb options are as follows.
ON — A literal specifying that the value of the non-scan memory elements can be
disturbed by scan loading operations. This is the default. If the disturb option is on,
LBISTArchitect sets the states of non-scan memory elements to the unknown (X)
state after the scan loading operation.
OFf — A literal specifying that the value of non-scan memory elements cannot be
disturbed by scan loading. When the disturb option is off, the states of the non-scan
memory elements are the same as before the scan loading operation.
Examples
The following example forces LBISTArchitect to add extra primary input pins to replace the
original clocks on a global design-wide basis:
set identification model -clock extra
set system mode dft
setup scan identification full_scan
run

Related Commands
Report Environment

270 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Internal Fault

Set Internal Fault

Scope: Setup mode
Usage
SET INternal Fault ON | OFf
Description
Specifies whether the tool allows faults within or on the boundary of library models.
The Set Internal Fault command specifies whether the tool will allow faults on internal nodes of
library models or only on the library model boundary. The default upon invocation of the tool is
to allow faults only on the library model boundary.
Arguments
• ON
A literal that specifies to allow faults on the internal nodes of library models.
• OFf
A literal that specifies to allow faults only on the boundary of the library models. This is the
default upon invocation of the tool.
Examples
The following example invokes the scan identification process such that LBISTArchitect takes
into consideration any internal faults when calculating the efficiency percentage:
set internal fault on
set system mode dft
setup scan identification full_scan
run

LBISTArchitect Reference Manual, v2017.3 271

September 2017
BIST-Ready Command Dictionary
Set Io Insertion

Set Io Insertion
Scope: All modes
Prerequisites
Input and output buffers must be defined in either the DFT library or by using the Add Cell
Models command.
Usage
SET IO Insertion OFf | ON | {[TEn] [Ram] [SEn] [TClks] [SIns] [SOuts] [Control]
[OBserve] [-Model model_name]}
Description
Specifies whether to insert I/O buffers.
The Set IO Insertion command specifies whether LBISTArchitect should insert I/O buffers
automatically during scan insertion. By having automatic I/O buffer insertion turned off (the
default), you can perform scan insertion at the block level, or insert the I/O buffers manually
after inserting scan at the design level.
If you defined I/O buffers in the DFT library or used the Add Cell Models command to define
them, when you set this command to “on”, LBISTArchitect will automatically insert the I/O
buffers during scan insertion.
You can specify which test control signals should have I/O buffers added. You can specify one
or more of the test signal literal arguments. The specified signals can be internal signals (output
port of a library cell) or new pins generated by LBISTArchitect.
The Set IO Insertion command is additive. This means that each time you issue the command, it
adds any new options to those already defined.
Arguments
• OFf | ON
A required literal that specifies whether to insert I/O buffers for all test signals. If you are
not turning On or Off all test signals, you must specify at least one of the test signal
arguments. If you want to remove any existing I/O buffer signals from the list of signals to
buffer, you turn off I/O buffer insertion (Set IO Insertion off). The default upon invocation
is off.
• TEn
A literal that specifies to buffer the test_enable pin.
• Ram
A literal that specifies to buffer the ram_write_control and ram_read_control pins.
• SEn
A literal that specifies to buffer the scan_enable pin(s).

272 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Io Insertion

• TClks
A literal that specifies to buffer all test clock pins, including clock, set, and reset.
• SIns
A literal that specifies to buffer all scan_in pins of inserted scan chains.
• SOuts
A literal that specifies to buffer all scan_out pins of inserted scan chains. No buffer is
inserted unless a buffer has been defined with the “-Type outbuf” option of the Add Cell
Models command, or if you have used the -Model switch, and specified a buffer as part of
this command.
• Control
A literal that specifies to buffer all test point control pins, if no scan cell is requested with
the Setup Test_point Insertion command.
• OBserve
A literal that specifies to buffer all test point observe pins, if no scan cell is requested with
the Setup Test_point Insertion command.
• -Model model_name
An optional switch and string pair that specifies the name of a buffer in the DFT library for
LBISTArchitect to insert on the test pins. You must first identify the buffer with either the
Add Cell Models command or with the cell_type library attribute. The specified model
should be the OUTBUF type for scan outputs and the INBUF type for all scan inputs and
test signals.
If you do not use the -Model switch, by default, LBISTArchitect uses the first buffer model
in the buffer cell model list (which you can see with the Report Cell Models command).
Examples
The following example shows how to enable the adding of I/O buffers automatically to all test
control signals:
set io insertion on

To enable the adding of I/O buffers to only the scan in, scan out, control, and observe signals,
enter:

set io insertion sins souts control observe

Related Commands
Add Buffer Insertion Add Cell Models

LBISTArchitect Reference Manual, v2017.3 273

September 2017
BIST-Ready Command Dictionary
Set Latch Handling

Set Latch Handling

Scope: Setup mode
Usage
SET LAtch Handling None | Scan
Description
Specifies whether the tool considers non-transparent latches for scan insertion while test logic is
turned on.
The Set Latch Handling command specifies whether the tool can consider non-transparent
latches as candidates for scan insertion. If you determine that the tool is to consider non-
transparent latches as candidates for scan insertion, you must turn on the appropriate Set Test
Logic command settings before LBISTArchitect performs the rules checking process.
If you use the Set Drc Handling command to set the D6 rule to error or warning, D6 checks the
non-scannable latches for transparency. By default, if they are not transparent and you turned
test logic insertion on, LBISTArchitect does not consider the non-transparent latches for scan
insertion. However, if you use the Scan argument with the Set Latch Handling command,
LBISTArchitect will consider the non-transparent latches for scan insertion.
If you use the Set Drc Handling command to ignore the D6 rule, then rules checking does not
check the non-scannable latches for transparency and LBISTArchitect will automatically
consider all non-scannable latches, whose test logic you turned on, for scan insertion.
Arguments
• None
A literal that specifies to give no consideration to non-transparent latches for scan insertion.
This is the default upon invocation of LBISTArchitect.
• Scan
A literal that specifies to consider non-transparent latches for scan insertion when test logic
is turned on.
Related Commands
Set Drc Handling Set Test Logic

274 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Lockup Latch

Set Lockup Latch

Scope: Dft mode
Prerequisites
You must first specify the latch model(s) that you want LBISTArchitect to use with the Add
Cell Models command.
Usage
SET LOckup Latch {ON | OFf} [-Nolast | -Last] [-First_clock | -SEcond_clock]
[-NOInternal | -Internal]
Description
Specifies for LBISTArchitect to insert latches between different clock domains to synchronize
the clocks within a scan chain.
If you specify for LBISTArchitect to merge scan cells with different shift clocks into the same
scan chain with the Insert Test Logic command, then you can synchronize the clock edges by
inserting latches between the scan cells that are in different clock domains.
Before you can issue the Set Lockup Latch command, you must identify the latch model(s) you
want LBISTArchitect to use with the -Type DLAT option to the Add Cell Models command.
LBISTArchitect determines which latch model to use for different polarity clock domains based
on the information shown in Table 2-8.The table illustrates the logic LBISTArchitect inserts
between two clock domains.

Table 2-8. Latch Use for Different Polarity Clock Domains

Clock Domain Polarity Specified Add Cell Model Arguments Latch Chosen
(two domains) (the logic inserted
between the domains)
stable_low (active high) add cell model lat1 -type dlat g d -active lat1 (inverted clock)
high
stable_low (active high) add cell model lat1 -type dlat g d -active lat1
low
stable_low (active high) add cell model lat1 -type dlat g1 d1 -
active high lat2
add cell model lat2 -type dlat g2 d2 -
active low
stable_high (active low) add cell model lat -type dlat g d -active lat1
high
stable_high (active low) add cell model lat -type dlat g d -active lat1 (inverted clock)
low

LBISTArchitect Reference Manual, v2017.3 275

September 2017
BIST-Ready Command Dictionary
Set Lockup Latch

Table 2-8. Latch Use for Different Polarity Clock Domains (cont.)
Clock Domain Polarity Specified Add Cell Model Arguments Latch Chosen
(two domains) (the logic inserted
between the domains)
stable_high (active low) add cell model lat1 -type dlat g1 d1 -
active high lat1
add cell model lat2 -type dlat g2 d2 -
active low
To add a stable_low clock, clk1, you would use the command:
add clock 0 clk1

Note
If you define any lockup latches in the cell order file, this command is not used. If no
lockup latches are defined in that file, LBISTArchitect uses the settings in this command.
For more information on the cell order file, refer to the Insert Test Logic command.

Arguments
• ON | OFf
A literal that specifies whether LBISTArchitect should insert latches between different
clock groups within a scan chain. The default behavior upon invocation is OFf.
• -Nolast | -Last
An optional switch that specifies whether LBISTArchitect should insert a latch between the
last scan cell and the scan out pin of a scan chain. The default behavior upon invocation of
LBISTArchitect is -Nolast.
Note
Last is not a recommended option, because it complicates proper lockup latch insertion
when concatenating scan chains for topup ATPG.

• -First_clock | -SEcond_clock
An optional switch that specifies for LBISTArchitect to connect either the clock of the first
set of scan cells or the clock of the second set of scan cells to the clock input of the lockup
latch. The default behavior upon invocation of LBISTArchitect is -First_clock.
• -NOInternal | -Internal
An optional switch that specifies for LBISTArchitect to insert lockup latches between
different, internally-generated clocks. This is often used with sub-chains that have internal
clocks that are not driven. A clock must not have a path to a primary input clock for it to be
considered an internal clock. This includes clocks that are accessible at the primary input
clock through test logic (muxes) or sensitized gates. The default behavior upon invocation
of LBISTArchitect is -Nointernal.

276 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Lockup Latch

Examples
The following example defines two different groups of clocks, identifies the latch that
LBISTArchitect is to insert if the clocks need synchronization, enables lockup latch insertion,
and performs the insertions. The -Clock Merge option informs LBISTArchitect to combine the
scan cells that are associated with the clocks (that are in the same clock group) together into a
single scan chain.
add clocks 0 clk1 clk2 clk3
add clocks 1 clk4 clk5 clk6
add clock groups group1 clk1 clk2 clk3
add clock groups group2 clk4 clk5 clk6
add cell model dlat1a -type dlat enable data
set lockup latch on
insert test logic -scan on -clock merge

LBISTArchitect inserts lockup latches between clk1 and clk2, clk2 and clk3, clk4 and clk5, and
clk5 and clk6. Insert Test Logic is the command that actually causes LBISTArchitect to
substitute the identified non-scan cells with the scan replacements and also place the lockup
latches into the design.
Note
The previous example causes LBISTArchitect to create two scan chains because there are
two clock groups.

Related Commands
Add Cell Models Delete Test Points
Add Clock Groups Insert Test Logic
Add Test Points Report Test Points

LBISTArchitect Reference Manual, v2017.3 277

September 2017
BIST-Ready Command Dictionary
Set Logfile Handling

Set Logfile Handling

Scope: All modes
Usage
SET LOgfile Handling [-RESume | {filename [-Replace | -Append]}
Description
Specifies for LBISTArchitect to direct the transcript information to a file.
The Set Logfile Handling command causes LBISTArchitect to write the transcript information,
which includes the commands and the corresponding output (if any), into the file you specify.
You can execute the Set Logfile Handling command at any time within the BIST-Ready phase,
and you can also execute it multiple times.
In the logfile, all commands that LBISTArchitect executes are preceded with the command
keyword. You can easily search for the commands you executed, and then you can generate a
separate dofile containing those commands which you can rerun within LBISTArchitect.
When you set the logfile handling, LBISTArchitect still writes the same information to the
session transcript window in addition to the logfile. However, you can disable the writing of the
information to the transcript window with the Set Screen Display command.
If you want LBISTArchitect to stop writing to a logfile, issue the Set Logfile Handling
command with no options, which closes the appropriate files.
Arguments
• -Resume
An optional switch that specifies for the tool to resume writing transcript output to the
logfile specified at invocation with the -Logfile invocation switch. You do not need to
include the name of the invocation logfile with this switch; the tool will remember the name.
• filename
An optional string that specifies the name of the file where you want LBISTArchitect to
write the transcript output. This string can be a full pathname or a leafname. If you only
specify a leafname, the tool creates the file in the directory from which you invoked the tool.
If you do not specify a filename, the tool discontinues writing logfiles and closes the
appropriate files.
• -Replace
An optional switch that forces LBISTArchitect to overwrite the file, if a file by that name
already exists.
• -Append
An optional switch that causes LBISTArchitect to begin writing the transcript at the end of
the specified file.

278 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Logfile Handling

Examples
The following example specifies for LBISTArchitect to write a logfile and to disable the writing
of the transcript:
set logfile handling /user/designs/setup_logfile
set screen display off
add clocks 0 clk
add clocks 1 pre clr
report clocks

The following information shows what the logfile contains after running the preceding set of
commands:
// command: set scr d off
// command: add clocks 0 clk
// command: add clocks 1 pre clr
// command: report clocks
PRE, off_state 1
CLR, off_state 1
CLK, off_state 0

Related Commands
Set Screen Display

LBISTArchitect Reference Manual, v2017.3 279

September 2017
BIST-Ready Command Dictionary
Set Loop Duplication

Set Loop Duplication

Scope: All modes
Prerequisites
You must use this command before the tool performs the learning process, which happens
immediately after flattening a design to the simulation model. Flattening occurs when you first
attempt to exit Setup mode.
Usage
SET LOop Duplication [ON | OFf]
Description
Specifies whether to include duplicate gates in feedback paths which are generated during the
circuit flattening process.
The Set Loop Duplication command determines whether the flattening process generates
duplicate gates within an identified feedback path. By default, the feedback paths include any
duplicated gates. You suppress the duplicated gates by turning the loop duplication off prior to
initiating the circuit flattening process. You use this command in conjunction with the Report
Feedback Paths command.
Arguments
• ON
An optional literal that specifies for the circuit flattening process to generate duplicate gates
within any identified feedback paths. This is the default.
• OFf
An optional literal that specifies for the circuit flattening process to not generate duplicate
gates within any identified feedback paths.
Examples
The following example turns off loop duplication, leaves the Setup mode which among other
things flattens the simulation model and performs the learning process, and displays the
identification numbers of any learned feedback paths:
set loop duplication off
set system mode dft
report feedback paths
Loop#=0, feedback_buffer=26, #gates_in_network=5
INV /I_956__I_582/ (51)
PBUS /I_956__I_582/N1/ (96)
ZVAL /I_956__I_582/N1/ (101)
INV /I_956__I_582/ (106)
TIEX /I_956__I_582/ (26)
Loop#=1, feedback_buffer=27, #gates_in_network=5
INV /I_962__I_582/ (52)
PBUS /I_962__I_582/N1/ (95)

280 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Loop Duplication

ZVAL /I_962__I_582/N1/ (100)

INV /I_962__I_582/ (105)
TIEX /I_962__I_582/ (27)

LBISTArchitect Reference Manual, v2017.3 281

September 2017
BIST-Ready Command Dictionary
Set Net Resolution

Set Net Resolution

Scope: Setup mode
Usage
SET NEt Resolution Wire | And | Or
Description
Specifies the behavior of multi-driver nets.
The Set Net Resolution command specifies the behavior of non-tri-state multi-driver nets. The
default upon invocation of the tool is Wire, which requires all inputs be at the same value to
achieve a value. If possible, you should specify the And or Or option, otherwise some loss of
test coverage results.
Arguments
• Wire
A literal that specifies for the tool to use unknown behavior for non-tri-state multi-driver
nets. This requires all inputs to be at the same value to achieve a value other than X. This is
the default upon invocation of the tool.
• And
A literal that specifies for the tool to use wired-AND behavior.
• Or
A literal that specifies for the tool to use wired-OR behavior.
Examples
The following example specifies that the behavior of non-tri-state multi-driver nets is wired-
AND during the scan identification process.
set net resolution and
add clocks 0 clock
set system mode dft
run
report scan identification

282 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Nonscan Handling

Set Nonscan Handling

Scope: Setup mode
Usage
SET NOnscan Handling Nocheck | Check
Description
Specifies whether to check the nonscan instances for scannability.
The Set Nonscan Handling command specifies whether the added nonscan instances are
checked for scannability. Nonscan instances are defined by the Add Nonscan Instances
command, Add Nonscan Models command, or the nonscan models due to no scan equivalents.
These nonscan instances are not checked because the instances cannot be selected for scan
insertion.
You can enable checking on nonscan instances by using this command with the Check option.
Arguments
• Nocheck | Check
A required literal that specifies whether to check the nonscan instances for scannability. The
invocation default is Nocheck.
Examples
The following example shows how to check all added nonscan instances:
set nonscan handling check

Related Commands
Add Nonscan Instances Set Drc Handling
Add Nonscan Models

LBISTArchitect Reference Manual, v2017.3 283

September 2017
BIST-Ready Command Dictionary
Set Scan Enable

Set Scan Enable

Scope: Setup and DFT modes
Prerequisites: mux-DFF scan type
Usage
SET Scan Enable [scan_enable_pin_pathname [-isolate]] [primary_input]
[-Active {High | Low}]
[-Chain chain_name...
|{-Wrapper_chain {chain_name... | -INput | -OUTput}} | -Partition partition_name...]
[-Clock clock_pin]
Description
Assigns scan_enable signals to specific scan chains. Scan chains can be specified by either
name, wrapper chain type, scan partition, or clock domain. If no scan chains are specified, the
specified scan_enable signal is assigned to all scan chains.

The Set Scan Enable command can be issued in a sequence to either refine the scan enable
signals assignments or overwrite the previous assignments (see the example section for this
command). In general, the following rules are applied to determine how signal assignments are
affected by subsequent commands:
• The most recent command that assigns a scan_enable signal takes precedence.
• If the most recent command operates on a disjoint set of scan chains, then the previous
scan enable signal assignments remain intact.
• If the most recent command operates on previously specified scan chains, then previous
scan_enable signal assignments are overwritten.
Arguments
• scan_enable_pin_pathname [-Isolate]
An optional string that specifies a pin pathname for the scan_enable signal driver. The
specified pin can be either a top-level scan enable port or an internal instance pin
(connection node). If an internal instance pin is specified, it must trace back to a primary
input via a simple path (only inverters or buffers) or the primary_input argument.
-Isolate — Isolates new fanouts of the specified scan enable signal. Each new fanout
connection is gated by an AND or NOR gate and controlled by the global test enable
signal.
If no scan_enable signal driver is specified, the default scan enable name is used: scan_en,
scan_en_in, scan_en_out.
• primary_input
An optional string that specifies a top-level scan_enable port. This argument supplies a
primary input/top-level port for an internal instance pin specified by the
scan_enable_pin_pathname argument. The specified top-level port is used when generating

284 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Scan Enable

the ATPG dofile and test procedure files. If the specified top-level port does not exist, it is
created. The specified top-level port must be a primary input port.
• -Active {High | Low}
An optional switch and literal pair that specifies whether the scan_enable signal is active
low or high.
• -CHain chain_name…
An optional switch and a repeatable string that identifies individual scan chains to assign the
specified scan_enable signal to.
• -Wrapper_chain [chain_name… | -INPut | -OUTput]
An optional switch and a repeatable string or literal pair that identifies the wrapper chains to
assign a specified scan_enable signal to. Options include:
chain_name... — Specifies one or more wrapper chain names.
-INPut — Specifies all input wrapper chains when two-domain distribution is used.
-OUTput — Specifies all output wrapper chains when two-domain distribution is used.
The -Input | -Output options should be used if the specified scan enable signal will be
associated with either all input wrapper chains or all output wrapper chains, respectively.
When the -Wrapper_chain switch is issued without arguments, the specified scan enable
signal is assigned to all wrapper chains when one-domain distribution is used.
Wrapper chain creation must be enabled. For more information on distribution modes and
creating wrapper chains, see the Setup Partition Scan command.
This switch, along with either the -Input or -Output option, can be used in conjunction with
the -Clock switch. In this case, the specified scan enable signal is assigned only to the
wrapper chains that belong to both the specified type of wrapper chains and the specified
clock domain.
• -Partition partition_name…
An optional switch and repeatable string pair that specifies names of scan partitions added
using the Add Scan Partition command. Use this option to assign a specified scan_enable
signal to the scan chains created within one or more partitions.
This option can be used in conjunction with the -Clock switch. In this case, the specified
scan enable signal is assigned only to the scan chains that belong to both the specified scan
partition and the specified clock domain.
• -Clock clock_pin
An optional switch and string pair that associates the specified scan enable signal with the
specified clock (clock domain). Clock_pin can be either an existing top level port (primary
input pin) or an existing internal pin pathname.
This switch can be used in conjunction with either the -Wrapper_chain or -Partition option,
in which case a unique scan enable signal is generated just for the scan chains that belong to

LBISTArchitect Reference Manual, v2017.3 285

September 2017
BIST-Ready Command Dictionary
Set Scan Enable

both the specified wrapper chain type or partition and the specified clock domain. This
switch is ignored when it is used in conjunction with the -Chain option.
An error message is issued when this switch is specified with either the -Clock Merge or the
filename -Fixed option of the Insert Test Logic command.
This switch can be used in conjunction with the -Edge Merge option of the Insert Test Logic
command.
Example 1
Assuming two-domain distribution of the identified wrapper cells, the following example uses a
sequence of Set Scan Enable commands to make all input wrapper chains controllable via the
insen1 signal, and all output wrapper chains controllable via the outsen1 signal. All of the
commands operate on disjoint sets of scan chains; therefore, each command affects different
scan chains and does not override scan_enable assignments made by the previous command.
Set Scan Enable insen1 -wrapper_chain -input
Set Scan Enable outsen1 -wrapper_chain -output

Example 2
The following example defines two scan partitions: partA and partB. A single scan chain is
inserted by default for partA and two scan chains are inserted for partB. Two scan chains are
inserted for the remaining cells in the default scan partition, as specified by the -number
argument of the Insert Test Logic command.
Set System Mode dft
Add Scan Partition partA -instance udff1 umodA/udff2 umodB/udff3 // 1 chain
Add Scan Partition partB -instance umodC -number 2 // 2 chains

Set Scan Enable sen

Set Scan Enable senPartA -partition partA
Set Scan Enable senPartB -partition partB

Insert Test Logic -number 2 // 2 chains inserted for the default partition

The first Set Scan Enable command makes all scan chains controllable via the sen scan enable
signal. The second Set Scan Enable command refines the first command and makes scan chains
of partA controllable via the senPartA scan enable signal. The third Set Scan Enable command
further refines the first command and makes scan chains of partB controllable via the senPartB
scan enable signal.
The second command operates on a set of scan chains that is entirely within the set specified in
the first command; therefore, the scan chains that are in both sets will get the most recent
assignment. The third command operates on a set of scan chains that is disjoint from the set in
the second command but is entirely contained within the first set; therefore, the scan chains that
are in both the first and the third sets get the most recent assignment.
Example 3
The following example defines two scan partitions: partA and partB. The first Set Scan Enable
command makes all scan chains controllable via the sen scan enable signal. The second Set
Scan Enable command specifies an internal pin, /modX/i_sen/x, associated with the primary

286 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Scan Enable

input, senPartA, as a driver of the scan enable signal controlling all scan chains of partA. The
third Set Scan Enable command specifies an internal pin, /modY/i_sen/x, associated with the
primary input, senPartB, as driver of the scan enable signal controlling all scan chains of partB.
Add Clock 0 /clkInput
Set System Mode dft
Add Scan Partition partA -instance udff1 umodA/udff2 umodB/udff3 // 1 chain
Add Scan Partition partB -instance umodC -number 2 // 2 chains
Set Scan Enable sen
Set Scan Enable /modX/i_sen/x senPartA -partition partA
Set Scan Enable /modY/i_sen/x senPartB -partition partB

Set Scan Enable senClk -clock clkInput

Insert Test Logic -number 2 // 2 chains inserted for the default partition

The last Set Scan Enable command specifies that all scan chains in the clkInput clock domain
are controllable by the senClk scan enable signal. The second and the third Set Scan Enable
commands overwrite the assignments of the first Set Scan Enable command affecting chains
that are in partA and partB. Since the second and the third Set Scan Enable commands operate
on disjoint sets, they do not affect previous assignments.

The fourth command will overwrite some of the assignments of the second and the third
commands for scan chains that are in partA and partB and also in the clkInput clock domain. If
it is desirable to restrict the clock domain's assignments to a specific partition, the -Partition and
-Clock options should be issued in conjunction in the same Set Scan Enable call as shown in
Example 4.

Example 4
In this example, two scan partitions are defined: partA and partB. This example uses a Set
Scan_enable Sharing command to make all scan chains within each scan partition controllable
via a unique scan enable signal partSenN where N is a unique number for each partition. Next,
the Set Scan Enable command specifies to assign a unique scan enable signal, clkSen, to only
the scan chains inside the partB scan partition that are also in the clock1 clock domain. The
second call operates on a set of scan chains that is the same as the set of scan chains in the first
call; therefore, certain previous assignments that are subject to the most recent assignment are
overwritten.

Add Clock 0 clk1

Set System Mode dft
Add Scan Partition partA -instance udff1 umodA/udff2 umodB/udff3 // 1 chain
Add Scan Partition partB -instance umodC -number 2 // 2 chains
Set Scan_enable Sharing -Prefix partSen -Scan_partition
Set Scan Enable clkSen -Partiton partB -Clock clock1

LBISTArchitect Reference Manual, v2017.3 287

September 2017
BIST-Ready Command Dictionary
Set Scan Enable

Related Commands
Report Scan Enable Setup Partition Scan
Set Scan_enable Sharing Setup Scan Insertion

288 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Scan_enable Sharing

Set Scan_enable Sharing

Scope: Setup and DFT modes
Prerequisites: mux-DFF scan type
Usage
SET SCan_enable Sharing [-Prefix base_name] [-Active {High | Low}]
{[-Max_number_of_chains integer]
[-Input_wrapper_chain | -Output_wrapper_chain | -Scan_partition] [-Clock_domain]}
Description
Divides all scan chains into specified groups and assigns a unique scan_ enable signal to each
group. Scan chains can be grouped by:
• Specifying a maximum number of chains in each group, by wrapper chain types, by scan
partitions, or by clock domains.
• Specifying a maximum number of chains within groups there were created by wrapper
chain types, by scan partitions, or by clock domains.
• Clock domains within groups created by wrapper chain types or by scan partitions.
The Set Scan_enable Sharing command can be issued in a sequence to either refine the scan
enable signals assignments or overwrite the previous assignments (see the example section for
this command). In general, the following rules are applied to determine how signal assignments
are affected by subsequent commands:
• The most recent command that assigns a scan_enable signal takes precedence.
• If the most recent command operates on a disjoint set of scan chains, then the previous
scan enable signal assignments remain intact.
• If the most recent command operates on previously specified scan chains, then previous
scan_enable signal assignments are overwritten.
Arguments
• -Prefix base_name
An optional switch and string pair that specifies a base name (prefix) used in combination
with sequential numbers to automatically generate unique top-level scan_enable signals
(base_nameN) for specified groups of scan chains.
If this option is not specified, an appropriate default scan enable name (scan_en,
scan_en_in, scan_en_out) is used as the base name (prefix).
• -Active {High | Low}
An optional switch and literal pair that specifies whether the scan_enable signal is active
low or high.

LBISTArchitect Reference Manual, v2017.3 289

September 2017
BIST-Ready Command Dictionary
Set Scan_enable Sharing

• -Max_number_of_chains integer
A required switch and integer or literal pair that divides scan chains into groups. Options
include:
integer — Groups chains by a specified integer, where each group cannot have more
than the integer number of scan chains. A unique scan_enable signal is then generated
and assigned to each group.
• -Input_wrapper_chain | -Output_wrapper_chain
Optional switches specifying to generate a unique scan enable signal for either all input
wrapper chains or all output wrapper chains. When the switches are used in conjunction
with the -Max_number_of_chains option, the number specified by integer is applied only to
the specified type of wrapper chains. The generated scan enable signals are treated as
SEN_IN or SEN_OUT type, respectively.
-Input_wrapper_chain — Used to specify grouping for input wrapper chains. When this
switch is used in conjunction with the the -max_number_of_chains switch, the
number specified by integer is applied to only input wrapper chains. Only valid when
input wrapper chains are defined. For more information, see the Setup Partition Scan
command.
-Output_wrapper_chain — Used to specify grouping for output wrapper chains. When
this switch is used in conjunction with the the -max_number_of_chains switch, the
number specified by integer is applied to only output wrapper chains. Only valid
when output wrapper chains are defined. For more information, see the Setup
Partition Scan command.
These switches can be used in conjunction with the -Clock_domain switch.
• -Scan_partition
An optional switch that specifies groupings for each scan partition added using the Add
Scan Partition command.
With this switch, a unique scan enable signal is generated for every scan partition (that is,
for scan chains within each partition). When this switch is used in conjunction with the
-Max_number_of_chains switch, the number specified by integer is applied to each scan
partition.
This switch can be used in conjunction with the -Clock_domain switch.
• -Clock_domain
An optional switch that specifies to generate a unique scan enable signal for each clock
domain. When this switch is used in conjunction with the -Max_number_of_chains switch,
the number specified by integer is applied to each clock domain.
This switch can be used in conjunction with either the -Input_wrapper_chain or
-Output_wrapper_chain option; in this case a unique scan enable signal is generated only for
each clock domain within the input or output wrapper chains.
This switch cannot be used in conjunction with the -Clock Merge or the filename
-Fixed switches of the Insert Test Logic command; in this case an error message is issued.

290 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Scan_enable Sharing

This switch can be used in conjunction with the -Edge Merge switch of the Insert Test Logic
command.
Example 1
The following example uses a sequence of Set Scan_enable Sharing commands to make every
group of 3 input wrapper chains controllable via a unique scan_enable signal, insenN, and every
group of 5 output wrapper chains controllable via a unique scan enable_signal, outsenN.
Set Scan_enable Sharing -Prefix insen -Max_number_of_chains 3 -Input_wrapper_chain
Set Scan_enable Sharing -Prefix outsen -Max_number_of_chains 5 -Output_wrapper_chain

The second command operates on a set of scan chains that is disjoint from the set of scan chains
operated on by in the first command, so the previous assignments remain intact.
Example 2
The following example defines 3 scan partitions: spar1, spar2, spar3. Two scan chains are
created for spar1, 6 scan chains for spar2, and 3 scan chains for spar3. Two scan chains are
created in the default scan partition for the remaining cells, as specified by the -number
argument of the Insert Test Logic command.
add scan partition spar1 -ins a2/e* -verbose // 2 chains: chain1, chain2
add scan partition spar2 -ins a1/b2 a1/b1/e2 -max_length 2 -verbose // 6 chains: chain3, chain4,
chain5, chain6, chain7, chain8
add scan partition spar3 -mod C -number 3 -verbose // 3 chains: chain9, chain10, chain11
set scan_enable sharing -prefix SENPAR -scan_partition
insert test logic -number 2 // 2 chains for the default partition: chain12, chain13
report scan enable
-------------------------------------------------------------------------
--
// command: report scan enable
-------------------------------------------------------------------------
--
Primary Input Internal Connection Node Scan Chain
-------------------------------------------------------------------------
--
/SENPAR1 -- chain12
chain13
-------------------------------------------------------------------------
--
/SENPAR2 -- chain1
chain2
-------------------------------------------------------------------------
--
/SENPAR3 -- chain3
chain4
chain5
chain6
chain7
chain8
-------------------------------------------------------------------------
--
/SENPAR4 -- chain9
chain10
chain11

LBISTArchitect Reference Manual, v2017.3 291

September 2017
BIST-Ready Command Dictionary
Set Scan_enable Sharing

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

A unique scan_enable signal, SENPARN, is generated and assigned to all core scan chains.
Example 3
The following example uses a sequence of Set Scan_enable Sharing commands to make every
group of three input wrapper chains controllable via a unique scan enable signal insenN, where
N is a unique number for each group, and every group of five output wrapper chains
controllable via a unique scan enable signal outsenN, where N is a unique number of each
group.

Set Scan_enable Sharing -Prefix insen -Max_number_of_chains 3 -Input_wrapper_chain

Set Scan_enable Sharing -Prefix outsen -Max_number_of_chains 5 -Output_wrapper_chain

The second command operates on a set of scan chains that is disjoint from the set of scan chains
in the first command; therefore, the previous assignments are not affected by the subsequent
assignments.

Example 4
In this example, two scan partitions are defined: partA and partB. This example uses a Set
Scan_enable Sharing command to make all scan chains within each scan partition controllable
via a unique scan enable signal partSenN, where N is a unique number for each partition. Next,
the Set Scan Enable command specifies to assign a unique scan enable signal, clkSen, to only
the scan chains inside the partB scan partition that are also in the clock1 clock domain. The Set
Scan Enable command operates on a set of scan chains that is the same as the set of scan chains
in the Set Scan_enable Sharing command; therefore, certain previous assignments that are
subject to the most recent assignment are overwritten.

Add Clock 0 clk1

Set System Mode dft
Add Scan Partition partA -instance udff1 umodA/udff2 umodB/udff3 // 1 chain
Add Scan Partition partB -instance umodC -number 2 // 2 chains
Set Scan_enable Sharing -Prefix partSen -Scan_partition
Set Scan Enable clkSen -Partition partB -Clock clock1

Related Commands
Report Scan Enable Setup Partition Scan
Set Scan Enable Setup Scan Insertion

292 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Screen Display

Set Screen Display

Scope: All modes
Usage
SET SCreen Display ON | OFf
Description
Specifies whether LBISTArchitect writes the transcript to the session window.
If you create a logfile with the Set Logfile Handling command, you may want to disable
LBISTArchitect from writing the same information to the session transcript window.
Arguments
• ON
A literal that specifies to enable the tool to write the session information to the transcript
window. This is the default behavior upon invocation.
• OFf
A literal that specifies to disable the tool from writing any of the session information to the
transcript window, including error messages.
Examples
The following example shows how to use the logfile functionality to capture the transcript in a
file and then disable LBISTArchitect from writing to the display:
set logfile handling /user/design/setup_file
set screen display off

Related Commands
Report Environment Set Logfile Handling

LBISTArchitect Reference Manual, v2017.3 293

September 2017
BIST-Ready Command Dictionary
Set Sensitization Checking

Set Sensitization Checking

Scope: All modes
Usage
SET SEnsitization Checking OFf | ON
Description
Specifies whether DRC checking attempts to verify a suspected C3 rules violation.
The Set Sensitization Checking command specifies whether the DRC verifies that the path from
the source and sink of a suspected C3 violation exists when the source and sink clocks are on
and all other clocks are off. If sensitization checking is on and the paths associated with the
violation meet these conditions, the DRC reports the C3 violation.
Arguments
• OFf
A literal that disables the C3 DRC sensitization check. This is the default behavior upon
invocation.
• ON
A literal that enables the C3 DRC sensitization check.
Related Commands
Set Drc Handling

294 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set System Mode

Set System Mode

Scope: All modes
Usage
SET SYstem Mode Setup | Dft
Description
Specifies the next system mode for the tool to enter.
The Set System Mode command directs the BIST-Ready phase to a specific system mode,
which includes scan insertion (Dft) or the default system mode of Setup.
When switching from the Setup mode to any other mode, LBISTArchitect builds a flat, gate-
level simulation model. After the initial building of the flat, gate-level simulation model, if you
return to Setup mode, issue any of the following commands and then switch to another mode, a
new simulation model is built:
Add Nofaults Set Internal Fault
Add Tied Signals Set Internal Name
Delete Nofaults Setup Tied Signals
Delete Tied Signals

Arguments
• Setup
A literal that specifies for the tool to enter the Setup system mode.
• Dft
A literal that specifies for the tool to enter the Scan Insertion system mode.
Examples
The following example will change the system mode so you can perform a scan identification
run.
add tied signals 1 vcc
add tied signals 0 vss
add clocks 0 clock
set system mode dft
run
report scan identification

LBISTArchitect Reference Manual, v2017.3 295

September 2017
BIST-Ready Command Dictionary
Set Test Logic

Set Test Logic

Scope: Setup mode
Usage
SET TEst Logic {-Set {ON | OFf} | -REset {ON | OFf} | -Clock {ON | OFf} | -RAm {ON |
OFf}}…
Description
Specifies which types of control lines LBISTArchitect makes controllable during the DFT rules
checking.
The Set Test Logic command specifies whether LBISTArchitect makes set, reset, clock, enable,
or write control lines controllable. This, in turn, makes them scannable by inserting test logic to
those lines when you insert scan chains. Before inserting scan chains, you must specify the cell
models with the Add Cell Models command. You can use the Report Dft Check command to
display the lines where you can insert test logic to make the lines controllable.
The default behavior upon invocation of the BIST-Ready phase of LBISTArchitect is for all the
Set Test Logic command switches to be Off. You can use the Report Environment command to
display the current test logic settings.
If all enable lines of a bus are driven purely by combinational logic, then no additional test logic
is added, because there will not be a problem of contention due to scan shifting.
For tri-state buses, there are two options, Decoder and ONE_hot, that guarantee that only one
tri-state driver is active at any one time. However, ONE_hot is the recommended option,
because it assures that all drivers are activated for a certain number of patterns in the BIST run,
which gives better fault coverage.
The control signals for the ONE_hot option get routed up through the design and become new
primary inputs to the core, which are named appropriately to identify their corresponding bus
controls
Arguments
• -Set ON | OFf
A switch and literal pair that specifies whether LBISTArchitect makes the set lines
controllable during the DFT rules checking. The default upon invocation of LBISTArchitect
is Off.
• -REset ON | OFf
A switch and literal pair that specifies whether LBISTArchitect makes the reset lines
controllable during the DFT rules checking. The default upon invocation of LBISTArchitect
is Off.

296 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Test Logic

• -Clock ON | OFf
A switch and literal pair that specifies whether LBISTArchitect makes the clock lines
controllable during the DFT rules checking. The default upon invocation of LBISTArchitect
is Off.
• -RAm ON | OFf
A switch and literal pair that specifies whether LBISTArchitect makes the write control
lines controllable during the DFT rules checking. This option does not handle the set and
reset lines of the RAM. The default upon invocation of LBISTArchitect is Off.
Examples
The following example checks the set and clock lines of uncontrollable memory elements and
makes them controllable with the addition of test logic:
add clocks 0 clk
set test logic -set on -clock on
set system mode dft
report dft check
add cell models and2 -type and
add cell models or2 -type or
add cell models mux21h -type mux s a b
add cell models nor2 -type nor
report cell models
insert test logic

Related Commands
Add Cell Models Report Cell Models
Delete Cell Models Set Latch Handling

LBISTArchitect Reference Manual, v2017.3 297

September 2017
BIST-Ready Command Dictionary
Set Tristate Gating

Set Tristate Gating

Scope: Setup mode
Usage
SET TRistate Gating { OFf | ON | Busdrivers | Scan | primary_input_or _output... | Decoded}
[-Control {SEn | TEn}] [-Force_gating]
Description
Specifies how tri-state devices are controlled during scan chain shifting. The Set Tristate Gating
command ensures tri-state devices are controlled to either prevent bus contention or be turned
on during testing. If the necessary test logic already exists, none is inserted.
When enabled, test logic is inserted that controls tri-state devices as follows:
• Multiple tri-state gates driving nets (bus net) — One gate is turned on and the rest are
turned off during testing.
• Single tri-state gates driving nets (primary net or an internal net) — All single tri-
state gates are turned on for testing.
You can also specify which signal (SEN or TEN) controls the enable lines of tri-state devices.
By default, when the enable signal of a tri-state device is directly controlled by a primary input,
by TIE0, or by TIE1, no gating is necessary and a force statement for the primary input is added
to the load_unload procedure in the new procedure file. This behavior can be overridden by
using the -Force_gating switch.

Arguments
• {OFf | ON | Busdrivers | Scan | primary_input_or _output... | Decoded}
Required literal or repeatable string that specifies which tri-state devices to control during
scan shifting. The default setting is off. Options include:
OFf — no test logic is inserted to control tri-state devices. Default setting.
ON — test logic is inserted when necessary to control all tri-state devices.
Busdrivers — test logic is inserted to control tri-state devices driving bus nets.
Scan — test logic is inserted to control tri-state devices used as scan inputs/outputs.
primary_input_or _output — specifies a primary input or output pin. Test logic is
inserted to control the tri-state devices driving the specified primary output pin(s) or
driven by the specified primary input pin(s).
Decoded — test logic is inserted to control tri-state devices with the TEN signal to
ensure test logic structures are valid only in test mode.
• -Control SEn | TEn
An optional switch and literal pair that specifies the enable signal used to control tri-state
devices. Literal options include:

298 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Set Tristate Gating

SEn — scan_enable signal. Default setting.

TEn — test_enable signal.
• -Force_gating
An optional switch that adds test logic to the enable lines of tri-states devices when these
lines are directly controlled by primary inputs, or by TIE1, or by TIE0. When the enable line
is directly controlled by a primary input, DFTAdvisor adds the force statement for this
primary input to the load_unload procedure in the procedure file.
Example 1
The following example uses the Set Tristate Gating command to insert test logic and make all
tri-state devices driving bus nets controllable via the SEN signal; it then reports the gated
tri-state devices.
add clocks 0 clk
setup scan identification full_scan
set tristate gating on
set bidi gating scan
add scan pins c1 bidi_in1/X blkB1/blkA/utri2/A -top io out1
set system mode dft
report dft check -tristate
-------------------------------------------------------------------------
Bidi Primitive Control Control
Tri-state State Direction Gating ID Signal Driver
-------------------------------------------------------------------------
/bidi_in1 OFF IN YES 20 SEN /or2/Y
/blkB1/blkA/utri3 OFF -- YES 15 SEN /udff0/Q
/blkB1/blkA/utri2 ON -- YES 17 SEN /or2/Y
/blkB1/blkA/utri1 OFF -- YES 16 SEN /or2/Y
-------------------------------------------------------------------------

Example 2
The following example uses the force_gating switch to insert test logic controlled by the SEN
control signal on the enable line of /tpin_2. /tpin_2 is a tristate device driving primary output
out4; its enable signal is directly controlled by the primary input /io_control1.

set tristate gating out4 -force_gating

report dft check -tri

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

LBISTArchitect Reference Manual, v2017.3 299

September 2017
BIST-Ready Command Dictionary
Set Tristate Gating

Bidi Primitive Control Control

Tri-state State Direction Gating ID Signal Driver
----------------------------------------------------------------------
/tpin_1 ON -- NO 44 SEN /io_control
/tpin_2 ON -- YES 43 SEN /io_control1
/bidi_1 ON OUT NO 45 SEN /io_control
/bidi_2 ON OUT NO 46 SEN /io_control
/bidi_3 ON OUT NO 41 SEN /io_control
----------------------------------------------------------------------

Related Commands
Report Dft Check Set Bidi Gating
Report Test Logic Set Test Logic
Report Control Signals

300 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Naming

Setup Naming
Scope: All modes
Usage
SETup NAming [{-Net prefix_name} | {-Instance {[Tristate | Xbound | Lockup |
CONTROL_Flop | CONTROL_Point | OBSERVE_Flop | OBSERVE_Point]
prefix_name}…}]
Description
Explicitly defines the default names for nets and instances, and reports current or modified
settings.
The Setup Naming command serves two purposes. You can use it to change the default prefix
that LBISTArchitect uses to name certain types of added test logic, and you can change the
default the tool uses to name nets.
If you invoke the command without an argument, it automatically reports on the current settings
for all prefixes. If you make any changes, it reports the modified settings. Table 2-9 shows the
invocation defaults for particular logic instance types:
Table 2-9. Instance Type Prefix Defaults
Object Type Default Prefix Name Instance Literal
Tri-state control tcntl Tristate
X bounding xbnd Xbound
Lockup latches lckup Lockup
Control point flip-flop ctlff CONTROL_Flop
Control point logic ctlpt CONTROL_Point
Observe point flip-flop obsff OBSERVE_Flop
Observe point logic obspt OBSERVE_Point
Other logic uu

Arguments
• -Net prefix_name
An optional switch and string pair that specifies the prefix_name you want as the default
prefix for naming nets. The invocation default prefix is net
• -Instance [Tristate | Xbound | Lockup | CONTROL_Flop | CONTROL_Point |
OBSERVE_Flop | OBSERVE_Point] prefix_name
An optional switch, with an optional, repeatable literal and string pair, that specifies the
prefix_name you want as the default prefix for the object type specified by the literal. If you

LBISTArchitect Reference Manual, v2017.3 301

September 2017
BIST-Ready Command Dictionary
Setup Naming

do not specify an object type literal, prefix_name applies to all added test logic not covered
by one of the object type literals. The default prefix for this other logic is uu.
Tristate — An optional literal that specifies to apply the prefix_name as the default for
the logic object type tri-state control. The default prefix is tcntl
Xbound — An optional literal that specifies to apply the prefix_name as the default for
the logic object type X bound control. The default prefix is xbnd
Lockup — An optional literal that specifies to apply the prefix_name as the default for
the logic object type lockup latch. The default prefix is lckup
CONTROL_Flop — An optional literal that specifies to apply the prefix_name as the
default for the logic object type control-point flip-flop. The default prefix is ctlff
CONTROL_Point — An optional literal that specifies to apply the prefix_name as the
default for the logic object type control-point logic. The default prefix is ctlpt
OBSERVE_Flop — An optional literal that specifies to apply the prefix_name as the
default for the logic object type observe-point flip-flop. The default prefix is obsff
OBSERVE_Point — An optional literal that specifies to apply the prefix_name as the
default for the logic object type observe-point logic. The default prefix is obspt
Examples
The following example resets the default prefix name for tri-state control logic to “tric” and for
lockup latches to “lockl”:
setup naming -instance tristate tric lockup lockl

LBISTArchitect will change the prefix names and issue the following report:
// Setup naming prefixes:
// nets : net
// tristates : tric
// xbounding : xbnd
// lockup latches : lockl
// observe flops : obsff
// observe points : obspt
// control flops : ctlff
// control points : ctlpt
// other instances: uu

Related Commands
Insert Test Logic Set Test Logic

Command Summary

302 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Output Masks

Setup Output Masks

Scope: Setup mode
Usage
SETup OUtput Masks OFf | {ON [-Bidi_exclude] [-Lbist_exclude] [-Exclude
primary_output_pin…]}
Description
Sets the default mask for all output and bidirectional pins.
The Setup Output Masks command masks all the output and bidirectional pins specified. This
default mask is present on the output pin, unless overridden by the Add Output Masks
command.
LBISTArchitect uses primary output pins as the observe points during the scan and test point
identification process. When you mask a primary output pin, you inform LBISTArchitect to
mark that pin as an invalid observation point during the scan and test point identification
process.

Tip: In a test environment where the primary outputs cannot be observed during test, you
can make the primary outputs observable by inserting observe points using the Setup
Test_point Identification command with the -Primary_outputs switch.

You can exclude bidirectional pins, scan output pins, and any specified pins.
You use the Off literal to remove all default masks defined with this command.
You can add a hold value to a default mask with the Add Output Masks command, or remove a
hold value using the Delete Output Masks command. You can also use the Add Output Masks
command to add a mask to any of the output pins excluded with the Setup Output Masks
command.
Note
In the BIST-Ready run that contains the Setup Test_point Insertion command, the session
defaults for this command are:
setup output masks on -lbist_exclude

Arguments
• OFf | ON
A required literal that specifies to set or remove the current default mask setting for all
primary output pins. When turning masking on, you can exclude pins from the mask. In the
BIST-Ready run that contains the Setup Test_point Insertion command, the session default
for this command is ON. The tool invocation default setting is no masks.

LBISTArchitect Reference Manual, v2017.3 303

September 2017
BIST-Ready Command Dictionary
Setup Output Masks

• -Bidi_exclude
An optional switch that specifies to exclude bidirectional pins from the mask setting.
• -Lbist_exclude
An optional switch that specifies to exclude scan output pins from the mask setting.
• -Exclude primary_output_pin
An optional switch and repeatable string that specifies to exclude the specified primary
output pins from the mask setting.
Examples
The following example defines the default mask for all but the scan output pins, then adds two
additional pin masks with a hold value of 1:
setup output masks on -lbist_exclude
add output masks out1 out2 -hold 1

Related Commands
Add Output Masks Report Output Masks
Delete Output Masks Setup Test_point Identification

304 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Partition Scan

Setup Partition Scan

Scope: Setup mode
Usage
SETup PArtition Scan [-Exclude pin_names…]
Description
Specifies a partition scan run.
The Setup Partition Scan command sets up a partition scan run. This command defaults all that
is necessary to:
• Turn lockup latch and clock merge processing on.
• Automatically specify all primary input and output signals except clocks and other
control signals.
• Automatically default to 1 scan chain, no testpoints, and clock merge during inserting of
test logic.
Arguments
• -Exclude pin_names
An optional switch and repeatable string that specifies which I/O pins you do not want
included.
Examples
The following example performs a partition scan run:
set system mode setup
setup partition scan
...
set system mode dft
run
...
synthesize

Related Commands
Setup Scan Identification Write Netlist
Synthesize

LBISTArchitect Reference Manual, v2017.3 305

September 2017
BIST-Ready Command Dictionary
Setup Pin Constraints

Setup Pin Constraints

Scope: Setup mode
Usage
SETup PIn Constraints None | {{C0 | C1 | CZ | CX} [-Bidi_exclude] [-Lbist_exclude]
[-Exclude primary_input_pin…]} {[-SYnthesize | -SImulate {ATPG | BIST | ALL}]}
Description
Sets the default pin constraint value for all input pins.
When creating a BIST controller, the Setup Pin Constraints command constrains all input pins
to the specified default value. You use this command to constrain the input during the mode you
specify in order to avoid the inputs being tied to X and propagating to the MISR, thus corrupting
the signature. The value you set is the default that will be present on valid input pins (not clocks
and scan signals), unless overridden by the Add Pin Constraints command.
You can exclude all primary input and bidirectional pins except the following logic BIST
related pins (which you can never constrain):
• clocks
• scan inputs, scan outputs, and scan enables
• multi-phase test points
You use the None literal to remove all default settings defined with this command.
Arguments
• None
A required string that specifies to remove all the current default constraints for all primary
input and bidirectional pins. You must specify this literal or one of the “C” literals. This is
the tool invocation default.
• C0 | C1 | CZ | CX
A literal that specifies the default constant value constraint for the primary_input pins,
except for any pins excluded by the specified exclude options. You must specify one of
these literals or the None literal. The constraint choices are as follows:
C0 — A literal that specifies application of the constant 0 to the chosen primary input
pins.
C1 — A literal that specifies application of the constant 1 to the chosen primary input
pins.
CZ — A literal that specifies application of the constant Z (high-impedance) to the
chosen primary input pins.
CX — A literal that specifies application of the constant X (unknown) to the chosen
primary input pins.

306 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Pin Constraints

• -Bidi_exclude
An optional switch that specifies to exclude bidirectional pins from the setup setting.
• -Lbist_exclude
An optional switch that specifies to exclude BIST Controller-related input pins from the
setup setting. These pins include clocks, RAM/ROM read signals, RAM/ROM write
signals, sets, resets, and known scan inputs.
• -Exclude primary_input_pin
An optional switch and repeatable string that specifies to exclude the specified primary
input pins from the setup setting.
• -SYnthesize
An optional switch that specifies for the tool to add hardware that constrains all non-clock
and non-scan pins to a constant value, which also means that these signals are not
considered for X-bounding. The CZ and CX constant values cannot be used with the -
Synthesize switch.
• -SImulate {ATPG | BIST | ALL}
Specifies for LBISTArchitect to constrain the pins in the test procedure, test bench, and test
vector files. These signals must be driven with the appropriate values any time a logic BIST
test is active. This may cause problem for board/system test applications.
The ATPG literal specifies for the tool to constrain the pins during ATPG topup pattern
generation, the BIST literal specifies for the tool to constrain the pins in the BIST
simulation, and the ALL literal specifies for the tool to constrain the pins during both ATPG
and BIST.
Examples
The following example defines the default pin constraints for all but the BIST Controller-related
control and data pins, then adds two additional pin constraints that override the default:
setup pin constraints c0 -lbist_exclude
add pin constraints kgmt c1
add pin constraints ckgmt c1

Related Commands
Add Pin Constraints Delete Pin Constraints
Analyze Input Control Report Pin Constraints

LBISTArchitect Reference Manual, v2017.3 307

September 2017
BIST-Ready Command Dictionary
Setup Registered IO

Setup Registered IO
Scope: All modes
Prerequisites
You must first identify model_name with the Add Cell Models command before using either the
-Input_model or -Output_model switch.
Usage
SETup REgistered IO [-All] [-Input_model model_name] [-Output_model model_name]
[-Exclude pin_names…]
Description
Registers the primary inputs and outputs of a core design.
The Setup Registered IO command replaces manual techniques for registering the I/O of a
design. Although partial support for this function existed (for primary outputs) with the Setup
Test_point Identification command, the Setup Registered IO command adds new scan cells (as
control points for primary inputs, and observe points for primary outputs) that serve to register
the I/Os, and puts them in their own partition scan chain. Moreover, with the addition of the
wrapcell type to the Add Cell Models command, you can now specify a generic wrapper scan
cell that provides the flexibility to create a variety of partition scan architectures.
Note
This feature does not address stitching of multiple cores, but rather the insertion of a scan
partition in a single core.

Arguments
• -All
An optional switch that specifies to register all inputs and outputs, regardless of whether a
registering flip-flop already exists. The default is to register only those primary inputs and
outputs that do not have a flip-flop in their path. In either case, this does not include clock or
scan-related I/O pins.
• -Input_model model_name
An optional switch and string pair that specifies to use model_name cells for registering
primary inputs. You must first define model_name with the Add Cell Models command.
• -Output_model model_name
An optional switch and string pair that specifies to use model_name cells for registering
primary outputs You must first define model_name with the Add Cell Models command.
• -Exclude pin_names
An optional switch and repeatable string that specifies which primary I/O pins you do not
want registered. Note that clock and scan-related pins are automatically excluded.

308 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Registered IO

Examples
The Setup Registered IO command is intended for setting up a run to register the inputs and
outputs of a core. The following is a simple example:
add cell model FD1SQA -type scancell CLK D
add cell model MUX21HA -type mux S A B
setup registered IO
set system mode dft
run
synthesize

These commands identify primary inputs and outputs that are not connected to existing scan
cells and create control (for input pins) and observe (for output pins) testpoints for those pins
using a single scan cell per testpoint. These scan cells serve to register the IO of the design and
LBISTArchitect places them in a single scan chain. The inserted logic would look something
like the following:
PI
functional path
supply 1 or 0 Q
D

Scan cell test_enable

scan_input
scan_enable
functional path PO
scan_output Scan cell
D Q scan_output

scan_input scan_enable

If your design requires more sophisticated logic, you can define a wrapper cell with the Add
Cell Models command’s wrapcell type:
add cell model SC1_A -type wrapcell CLK D
setup registered IO

LBISTArchitect Reference Manual, v2017.3 309

September 2017
BIST-Ready Command Dictionary
Setup Registered IO

In this case, because it is the only cell you added, LBISTArchitect uses the SC1_A wrapper cell
to register the IO. The architecture is now flexible, because you can define the scan cell
architecture in the library. The following is an example of a wrapcell type:

SE SC1_A TE

PI(1) DIN 0
DOUT functional path
SCAN_IN 1 Q 1
SI
D
0
V SO
CLK_IN CLK

SE SC1_A TE

functional path DIN 0

1 DOUT PO(N)
SI Q 1
D
0
V SO SCAN_OUT
CLK

The additional test enable signal (TE) is routed to the top of the design. An example library cell
must define both the scan_enable and test_enable attributes in the scan definition:
model SC1_A(DOUT, SO, DIN, CLK, SI, SE, TE) (
scan_definition(
type = mux_scan;
scan_out = SO;
scan_in = SI;
scan_enable = SE;
test_enable = TE;
non_scan_model = DFF(DOUT, DIN, CLK);
)
input(DIN, CLK, SI, SE, TE) ()
intern(tied1) (primitive = _tie1 UT1 (tied1);)
intern(QQ) (primitive = _buf UP1 (SO, QQ);)
output(SO) (instance = FF_Q UD1 (SO, Y, CLK);)
// out 0 1 sel
intern(Y) (instance = MUX21 UD2 (Y, DOUT, SI, SE);)
output(DOUT) (instance = MUX21 UD3 (DOUT, DIN, QQ, TE);)
)

When the test-enable signal (TE) is asserted, the core is in core test mode. To implement your
core test strategy, you must create any required core test controller logic at a higher level.
Related Commands
Add Cell Models

310 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Scan Identification

Setup Scan Identification

Scope: All modes
Usage
SETup SCan Identification Full_scan | None | {[-MAx_length integer] | [-NUmber [integer]]}
Description
Specifies whether or not to use the full scan identification methodology during the
LBISTArchitect identification run.
The Setup Scan Identification command controls the scan identification run. You can choose
either full scan or none.
Full Scan Arguments
• Full_scan
A literal that specifies to use full scan for scan identification. Full scan is the fastest
identification method, converting all scannable sequential elements to scan. This is the
default upon invocation of the tool.
• None
A literal that specifies to not perform scan identification. You use this option in combination
with the Add Test Points or Setup Test_point Identification command if you only want to
insert test points (and not scan) in your design. If you want to insert both test points and
scan, you should always do the scan identification before the test point identification to
ensure an optimal test point selection.
• -MAx_length integer | -NUmber integer
Two optional, mutually-exclusive switch and integer pairs that specify one of the following:
-MAx_length integer
Specifies the maximum number of scan cells that the tool can stitch into a scan
chain. LBISTArchitect evenly divides the scan cells into scan chains that are
smaller than the max_length integer. Final results depend upon the number of
scan candidates.
-NUmber integer
Specifies the exact number of scan chains that you want the tool to insert. Final
results depend upon the number of scan candidates. The default number of chains
is 1.

LBISTArchitect Reference Manual, v2017.3 311

September 2017
BIST-Ready Command Dictionary
Setup Scan Identification

Examples
The following example sets up for a test point only run:
setup scan identification none
setup test_point identification -control 10 -observe 5
run

Related Commands
Add Test Points Setup Test_point Identification
Report Sequential Instances Synthesize
Run Write Scan Identification
Setup Partition Scan

312 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Scan Insertion

Setup Scan Insertion

Scope: All modes
Usage
SETup SCan INsertion
[{-SEN name [-Isolate] | -TEn name} {-Active {High | Low}}] [-TClk name]
[-SClk name] [-SMclk name] [-SSclk name] [{{-SET name} | {-RESet name} |
{-Write name} | {-REAd name}}… {-Muxed | -Disabled | -Gated}]
Description
Sets up the parameters for the Insert Test Logic command.
The Setup Scan Insertion command allows you to either change or set the pin names that
LBISTArchitect assigns during the Insert Test Logic command. The default names upon
invocation of LBISTArchitect, which you can change, are listed in Table 2-10.

Table 2-10. Scan Insertion Invocation Default Pin Names

Switch Description Default Name
-SEN Scan Enable for mux-DFF type scan_en
-TEn Test Enable for all scan types test_en
-TClk New Scan Clock for all scan types test_clk
-SClk Scan Clock for clock-scan type scan_clk
-SMclk Scan Master Clock for LSSD type scan_mclk
-SSclk Scan Slave Clock for LSSD type scan_sclk
-SET Global Set scan_set
-RESet Global Reset scan_reset
-Write RAM Write Control write_clk
-REAd RAM Read Control read_clk

LBISTArchitect uses the set and reset names when gating the set and reset pins of flip-flops or
latches. Furthermore, you can use the -Disable or -Muxed switches to specify whether
LBISTArchitect uses an AND gate or MUX gate when performing the gating. If you specify the
-Disabled option, then for gating purposes, LBISTArchitect uses the test enable signal to disable
the set and reset inputs of flip-flops. If you specify the -Muxed option, then for muxing
purposes, LBISTArchitect uses any set and reset pins which are defined as clocks to multiplex
with the original signal.
LBISTArchitect uses the write control and read control pins when inserting test logic for
RAMs. After you have added the write control lines in the Setup system mode and switched to
the DFT system mode, the Design Rules Checker checks whether the RAMs can be held off

LBISTArchitect Reference Manual, v2017.3 313

September 2017
BIST-Ready Command Dictionary
Setup Scan Insertion

when the write control pin is off. Those RAMs that cannot be held off are candidates for
inserting test logic.
If the new scan design is intended for Fault Simulation, and if the write clock input of the RAM
is not controllable, it will be muxed out by a new write clock and the selector to the mux will be
the test enable pin.
If the new scan design is intended for Sequential Fault Simulation, and if the original write
clock is not to be muxed and the RAM is just to hold during the shifting of the scan chain data,
then you need to specify the -Disabled option. Thus, LBISTArchitect will use the scan enable
pin to gate the original write clock input of the RAM.
In addition, you can use instance pin pathnames to define the scan enable, test enable, and so on,
pin names. If you specify an internal pin pathname and LBISTArchitect cannot trace through a
simple path (only through inverters or buffers) back to a primary input/output of the design, it
cannot generate the test procedure file and the dofile with the Write Atpg Setup command.
Therefore, you must manually develop these two files before running with either the Fault
Simulation or Sequential Fault Simulation phases.
If you specify the -Isolate option, when the scan enable capability is added to the design,
LBISTArchitect checks the global scan enable signal to determine if it already has fanouts. If
this is true, then an AND or OR gate is inserted with the second input controlled by the global
test enable signal. The output of this gate is connected to all the new fanouts of the scan enable
pin. The output of this gate is active for test mode and inactive for system mode. In test mode,
the output of this gate is identical to the scan enable signal; the gate acts as a buffer.
Arguments
• -SEN name
An optional switch and string pair specifying the leading scan enable pin name that you
want the scan insertion process to use when creating the scan enable. The default scan
enable pin name upon invocation of LBISTArchitect is “scan_en”.
You can use the -Active switch to specify whether the scan enable pin is active low or active
high.
You can use the -Isolate switch to isolate any newly added fanouts of this signal.
• -Isolate
An optional switch to the -Sen switch that specifies to isolate all new fanouts of the
scan_enable signal specified by the -Sen option. An additional AND or OR gate is inserted
during scan insertion with the output connected to all the new fanouts of the scan_enable
pin. The inputs of this new gate are the scan enable and the global test enable signals. The
default is to not isolate the new fanouts.
• -TEn name
An optional switch and string pair specifying the leading test enable pin name that you want
the scan insertion process to use when creating the test enable. The default test enable pin
name upon invocation of LBISTArchitect is “test_en”.

314 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Scan Insertion

You can use the -Active switch to specify whether the test enable pin is active low or active
high.
• -Active High | Low
An optional switch and literal pair that specifies whether the scan enable or test enable pin is
active high or active low. You can only use this switch with the -Sen or -Ten switch. The
default upon invocation of LBISTArchitect is active high.
• -TClk name
An optional switch and string pair specifying the name of a new scan clock pin that you
want LBISTArchitect to create if a a scan clock is not already predefined.
If you have predefined a scan clock, LBISTArchitect will use it. Otherwise, LBISTArchitect
creates a new pin with the specified name during the scan insertion process. If neither of
these conditions exist, LBISTArchitect creates a new test clock pin using the invocation
default name of “test_clk”.
• -SClk name
An optional switch and string pair specifying the leading scan clock pin name that you want
the scan insertion process to use when creating the scan clock. LBISTArchitect only creates
the scan clock pin for the scan clock port in the dual-port type mux scan. The default scan
clock pin name upon invocation of LBISTArchitect is “scan_clk”.
• -SMclk name
An optional switch and string pair specifying the leading scan master clock pin name that
you want the scan insertion process to use when creating the scan master clock. The default
scan master clock pin name upon invocation of LBISTArchitect is “scan_mclk”.
• -SSclk name
An optional switch and string pair specifying the leading scan slave clock pin name that you
want the scan insertion process to use when creating the scan slave clock. The default scan
slave clock pin name upon invocation of LBISTArchitect is “scan_sclk”.
• -SET name
An optional switch and string pair specifying the set pin name that you want
LBISTArchitect to use for the flip-flop or latch when inserting test logic. The default set pin
name upon invocation of LBISTArchitect is “scan_set”.
• -RESet name
An optional switch and string pair specifying the reset pin name that you want
LBISTArchitect to use for the flip-flop or latch when inserting test logic. The default reset
pin name upon invocation of LBISTArchitect is “scan_reset”.
• -Write name
An optional switch and string pair specifying the write control pin name that you want
LBISTArchitect to use for the RAM when inserting test logic. The default write control pin
name upon invocation of LBISTArchitect is “write_clk”.

LBISTArchitect Reference Manual, v2017.3 315

September 2017
BIST-Ready Command Dictionary
Setup Scan Insertion

• -REAd name
An optional switch and string pair specifying the read control pin name that you want
LBISTArchitect to use for the RAM when inserting test logic. The default read control pin
name upon invocation of LBISTArchitect is “read_clk”.
• -Muxed
An optional switch that specifies for LBISTArchitect to multiplex the set, reset, write
control, or read control lines. This is the default. If you specify the -Muxed option, then for
muxing purposes, LBISTArchitect will multiplex any set and reset pins which are defined as
clocks with the original signal.
• -Disabled
An optional switch that specifies for LBISTArchitect to gate the set, reset, write clock, or
read clock lines. If you specify the -Disabled option, then for gating purposes,
LBISTArchitect will use the test enable signal to disable set and reset inputs of flip-flops
and the scan enable signal to disable the write and read clocks.
• -Gated
An optional switch that specifies for LBISTArchitect to gate the set, reset, write control, or
read control lines. If you specify the -Gated option, then for gating purposes,
LBISTArchitect will use any set and reset pins defined as clock or use the write and read
clocks to disable the set and reset inputs of flip-flops.
Examples
The following example renames the test enable pin name to test_en_L and specifies for the pin
to be active low during the scan insertion process:
add clocks 0 clock
set system mode dft
setup scan identification full_scan
run
setup scan insertion -ten test_en_L -active low
insert test logic -max_length 10

The following example shows how to set different controls using successive Set Scan Insertion
commands:

setup scan insertion -ten TEST_MODE -active high// test enable

setup scan insertion -sen SCAN_MODE// scan enable
setup scan insertion -tclk TEST_CLK// test clock
setup scan insertion -reset RESET -mux// global reset
setup scan insertion -set SCAN_SET -disable// global set
setup scan insertion -write SCAN_WRT_INH -mux// RAM write controls
setup scan insertion -read SCAN_READ_INH -mux// RAM read controls

Related Commands
Insert Test Logic

316 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Scan Pins

Setup Scan Pins

Scope: All modes
Usage
SETup SCan Pins {Input | Output} [-INDexed | -Bused] [-Prefix base_name] [-INItial index#]
[-Modifier incr_index#] [-Suffix suffix_name]
Description
Changes the scan-in or scan-out pin naming parameters to index or bus format.
The Setup Scan Pins command specifies the index or bus naming conventions for scan-in or
scan-out pins. The Report Environment command displays the names and values that
LBISTArchitect uses for scan-in and scan-out pins when inserting scan chains. Once you have
inserted scan chains, you can use the Report Scan Chains command to display the chosen index
or bus naming convention for the scan-in pins and/or scan-out pins.
Indexed names are in the form:

base_name + index# + suffix_name

Bused names are in the form:

base_name + [index#]

Arguments
• Input
A literal specifying that LBISTArchitect apply the index or bus format on the scan-in pins.
• Output
A literal specifying that LBISTArchitect apply the index or bus format on the scan-out pins.
• -INDexed
An optional switch specifying that LBISTArchitect apply the index format to the scan-in or
scan-out pin names. This is the default.
• -Bused
An optional switch specifying that LBISTArchitect apply the bus format to the scan-in or
scan-out pin names.
• -Prefix base_name
An optional switch and string pair that specifies the root name of the scan-in
or scan-out pin. The default name is scan_in.
• -INItial index#
An optional switch and integer pair that specifies the initial index value of the scan-in or
scan-out pin name. The default value is 1.

LBISTArchitect Reference Manual, v2017.3 317

September 2017
BIST-Ready Command Dictionary
Setup Scan Pins

• -Modifier incr_index#
An optional switch and integer pair that specifies the incremental value that to add to the
index# when creating additional names with the same base_name. The default is 1.
• -Suffix suffix_name
An optional switch and string pair that specifies the name that you want to place after the
index#. LBISTArchitect only uses this for indexed naming. The default is null.
Examples
The following example configures scan insertion to use bus names for the scan-in pins and scan-
out pins, with the index number starting at 5 and incrementing by 2 for scan-in pins, and the
index number starting at 4 and incrementing by 2 for scan-out pins:
add clocks 0 clock
set system mode dft
run
setup scan pins input -bused -prefix scin -initial 5 -modifier 2
setup scan pins output -bused -prefix scout -initial 4 -modifier 2
insert test logic -number 7

Related Commands
Insert Test Logic

318 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Test_point Identification

Setup Test_point Identification

Scope: Setup mode
Prerequisites
If you want only test points (and not scan) identified, use the Setup Scan Identification
command’s None option.
Usage
SETup TEst_point IDentification [-COntrol integer] [-Minimum integer]
[-OBserve integer [-Primary_outputs [-EXClude pins…]]]
[-PATterns integer] [-Test_coverage percent] [-PHases integer] [-BPc_threshold integer]
[-Sig_prob_threshold percent] [-NUm_detections integer] [-OP_cost multiplier]
[-Rcp_cost multiplier] [-Verbose | -NOVerbose]
Description
Specifies the number of control and observe test points that LBISTArchitect flags during the
identification run.
You must be in Setup mode when issuing the Setup Test_point Identification command. Then,
using its proprietary, multiphase-based test point insertion technique, LBISTArchitect
calculates the controllability and observability values for each pin in the flattened design. Based
on this calculation, LBISTArchitect identifies test point candidates and inserts the test points.
This technique divides the total number of pseudorandom patterns into the same number of
groups as the number of phases you specify (using the -Phases argument).
The number of phases you specify with the Setup Test_point Identification command must be
2n, while the number of patterns should be 2n - 1. This setup means that you should simulate
8191 patterns instead of 8000 and 32767 patterns instead of 32000. LBISTArchitect
automatically changes a pattern count setting (such as from 32000 to 32767) to meet this
requirement.
Once you enable LBISTArchitect to identify the optimum test point locations (with the Setup
Scan Identification command) and set the number of each type of test point that LBISTArchitect
is to locate (with the Setup Test_point Identification command), you need to enter Dft mode
(with the Set System Mode command). After successfully entering Dft mode, you perform the
test point analysis with the Run command. While performing the analysis, LBISTArchitect lists
the test point locations that it identifies.
Arguments
• -COntrol integer
An optional switch and integer pair that specifies how many test points you want
LBISTArchitect to identify to aid in increasing the controllability of the design. The default
upon invocation of LBISTArchitect for identifying test points for controllability is 100.

LBISTArchitect Reference Manual, v2017.3 319

September 2017
BIST-Ready Command Dictionary
Setup Test_point Identification

• -Minimum integer
An optional switch and integer pair that specifies how many control points LBISTArchitect
must insert, per phase (not to exceed the number of control points originally allocated to the
given phase), regardless of any other switch settings. The default is 1 per phase.
• -OBserve integer [-Primary_outputs [-EXClude pins…]]
An optional switch and integer pair that specifies how many test points you want
LBISTArchitect to identify to aid in increasing the observability of the design. The default
upon invocation of LBISTArchitect for identifying test points for observability is 100.
-Primary_outputs — An optional switch that specifies to add observe points to primary
outputs. The implementation of the observe points depends on the settings you
specify for the Setup Test_point Insertion command. This option is useful if the test
environment dissallows observation of the primary outputs; that is, if the outputs have
been masked by the Setup Output Masks command.
-EXClude pins — An optional switch and repeatable string that causes
LBISTArchitect to exclude the specified primary output pins from use as observe
points.
• -PATterns integer
An optional switch and integer pair that specifies how many patterns you want
LBISTArchitect to simulate to determine controllability and observability of the test points.
The recommended number of patterns is 2n - 1. LBISTArchitect uses this number to
synthesize a minimal phase decoder. If the number is not 2n - 1, it is automatically changed
to the closest 2n - 1 number (either higher or lower) and LBISTArchitect issues a warning.
The default number of patterns upon invocation of LBISTArchitect is 32767.
• -Test_coverage percent
An optional switch and floating point number that specifies the percentage of target fault
coverage. Once LBISTArchitect reaches your target coverage, it ceases to add test points.
The default value upon invocation of LBISTArchitect is 100.0.
• -PHases integer
An optional switch and integer that specifies the number of phases into which you want
LBISTArchitect to partition the entire test. The integer value must be in a power of 2. For
example, 2, 4, or 8. Two phases is recommended for the start of analysis. Four and eight
phase runs should be tried if the design is relatively large. In most cases, the later phases
have decreased benefits and, therefore, a higher number of phases should be tried only if
you require very high test coverage (greater than 99%). The default value upon invocation
of LBISTArchitect is 4.
• -BPc_threshold integer
An optional switch and integer that specifies the minimum benefit-per-cost (BPC)
threshold. That is, the minimum number of faults that a test point should detect.
LBISTArchitect uses this during the selection of control and observe points. For
LBISTArchitect to select a test point, the test point must detect at least this number of faults.
The default value upon invocation of LBISTArchitect is 5.

320 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Test_point Identification

• -Sig_prob_threshold percent
An optional switch and floating point number that specifies the minimum percentage of
patterns necessary to cause a circuit node to become 0 or 1. LBISTArchitect checks this
during the preliminary analysis to determine control point candidates. Nodes for which a 0
or 1 pattern percentage falls below the threshold are called either zero-failing or one-failing,
respectively. LBISTArchitect selects these zero-failing and one-failing nodes as candidates
for control test point insertion. When the remaining-fault list is still relatively large,
increasing this percentage can have the effect of better control point selection. For a value of
15 percent, enter “0.15”. The default value upon invocation of LBISTArchitect is 0.10 (10
percent). The maximum value is 25 percent. Using the default (10 percent) for 1000 patterns
simulated, 100 of the 1000 patterns must be able to control a gate to 0 or 1, otherwise the
node is considered a candidate for control point insertion.
• -NUm_detections integer
An optional switch and integer pair that specifies your confidence level that the insertion of
a test point that uses BIST patterns will detect a fault. The integer range is 1 to 6. The default
value upon invocation of LBISTArchitect is 4.
• -OP_cost multiplier
An optional switch and floating-point-number multiplier that specifies the cost of
implementing an observe point, rather than a new control point. The observe point cost is
calculated as a multiple of a new control point (each control point is either a 2-input AND or
OR gate). The tool considers only gates with at least (BPCThreshold * OPCost) estimated
faults. LBISTArchitect uses this cost multiple to determine the overall value of inserting
observe points. You should specify this integer according to whether observe point
implementation is by a new scan cell (high cost) or primary output (low cost). The default
value upon invocation of LBISTArchitect is 4.0.
• -Rcp_cost multiplier
An optional switch and floating point number multiplier that specifies the cost of re-
enabling an existing control point inserted in a previous phase versus adding a new control
point. LBISTArchitect calculates this cost of re-enabling as a multiplier of a new control
point with a cost of 1. It then adds an additional 2-input AND or OR gate each time it
reactivates an AND or OR control point. The default value upon invocation of
LBISTArchitect is 1.0.
• -Verbose | -NOVerbose
An optional switch that specifies the amount of information that LBISTArchitect displays
during test point generation.
Examples
The following example shows the flow for multiphase test point selection.
setup test_point identification -control 10-observe 10 -patterns 8191
-verbose -phases 4 -bpc_threshold 5 -sig_prob_threshold 0.1

LBISTArchitect Reference Manual, v2017.3 321

September 2017
BIST-Ready Command Dictionary
Setup Test_point Identification

// The # of patterns for the 4 phases are: 255 256 256 256
// The # of requested control points for the phases are: 0 2
2 2

set system mode dft

. . .
run
// Performing test_point identification ...
// Number of control points to be identified = 10
// Number of observe points to be identified = 10
. . .

report test points

Control [Selected]: /u3/U54/Z AND phase_cntl_3_and
Control [Selected]: /u9/u2/U34/Z AND phase_cntl_3_and
Control [Selected]: /u3/U145/Z AND phase_cntl_3_and
Control [Selected]: /u3/U219/Z AND phase_cntl_2_and
Control [Selected]: /u9/u3/U36/Z OR phase_cntl_2_or
Control [Selected]: /u3/U297/Z AND phase_cntl_2_and
Control [Selected]: /u9/u3/U40/Z OR phase_cntl_1_or
Control [Selected]: /u3/U268/Z AND phase_cntl_1_and
Control [Selected]: /u9/u4/U36/Z OR phase_cntl_1_or
Control [Selected]: /u3/U226/Z AND phase_cntl_1_and
Observe [Selected]: /u8/U253/Z
Observe [Selected]: /u5/U144/Z
Observe [Selected]: /u13/U419/Z
Observe [Selected]: /u13/U426/Z
Observe [Selected]: /u13/U425/Z
Observe [Selected]: /u13/U424/Z
Observe [Selected]: /u13/U423/Z
Observe [Selected]: /u13/U421/Z
Observe [Selected]: /u13/U420/Z
Observe [Selected]: /u12/u1/U45/Z

Related Commands
Add Cell Models Report Test Points
Add Test Points Setup Scan Identification
Insert Test Logic Setup Scan Insertion

322 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Test_point Insertion

Setup Test_point Insertion

Scope: All modes
Prerequisites
You must identify model_name, and the models for use with the -New_scan_cell option, with
the Add Cell Models command before using the -Model or -New_scan_cell switch.
Usage

Control Point Usage

SETup TEst_point INsertion [-Control {pin_pathname -None}]

Observe Point Usage

SETup TEst_point INsertion [-Observe [{observe_enable -Existing_scan_cell} |
{pin_pathname -None} | -New_scan_cell | {-Model model_name}]]
[-REconvergence {OFf | ON}] [-CShare integer] [-OShare integer]
[-Time_based_capture {OFf | ON}]
Description
Specifies how LBISTArchitect configures the inputs for the control test points and the outputs
for the observe test points.
The Setup Test_point Insertion command modifies how the Insert Test Logic command inserts
test points. By default, the Insert Test Logic command creates primary inputs for the control test
points, named “phase_cntlN”, and connects observe test points to existing scan cells. You can
change the default names with the pin_pathname argument.
When you specify that you want new scan cells inserted for test points (-Model or
-New_scan_cell switch), LBISTArchitect inserts these new scan cells locally on the module
where the observe point resides. If you specify that you want an XOR tree (-Oshare), then the
tool analyzes the list of new observe points and groups them based on hierarchical information.
It then inserts the resulting observe scan cell in the module where the XOR tree emerges.
LBISTArchitect fits each new scan cell into nearby existing scan chains that do not exceed the
chain length limit. The clock for each new scan cell is the same as the clock of the scan cell it
feeds in the chain. If it cannot find a nearby chain, then it drops the observe point.
If you want LBISTArchitect to automatically identify test points, you can use the Setup Scan
Identification command in combination with the Setup Test_point Identification and Run
commands. After LBISTArchitect identifies the optimum test points, you then insert those test
points with the Insert Test Logic command.

LBISTArchitect Reference Manual, v2017.3 323

September 2017
BIST-Ready Command Dictionary
Setup Test_point Insertion

Arguments
• -Control
An optional switch that specifies how to configure the inputs for control test points.
The default -None switch causes LBISTArchitect to control the test point it inserts with the
pin specified by the “prefix” name, pin_pathname, as shown in Figure 2-5. The default for
pin_pathname is phase_cntlN.

Figure 2-5. Control Point Example for -None

/I$21 /I$23
PI
pin_pathnameN

• -Observe
An optional switch that specifies how to configure the outputs for observe test points.
Figure 2-6 shows that if you use the -Existing_scan_cell switch (the default) in combination
with the -Observe switch, LBISTArchitect controls the test point by adding control logic to
an existing, nearby scan cell when it synthesizes the logic. The observe_enable specifies the
name of the observe enable signal that controls the input to the scan cell.

Figure 2-6. Observe Point Example with -Existing_scan_cell

Connected by
“Insert Test Logic”
/I$21 /I$23

AND
XOR

Observe enable D Q
(if -Existing_scan_cell) si so
se
clk
Existing functional path
Existing scan cell

324 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Test_point Insertion

If you use the -None switch in combination with -Observe, LBISTArchitect controls the test
point it inserts with the pin specified by the “prefix” name, pin_pathname, as shown in
Figure 2-7.

Figure 2-7. Observe Point Example for -None and -Model

PO
pin_pathnameN
(if -None, default)
/I$21 /I$23

(if -Model)
model_name
D Q
Connected by si so next scan
“Insert Test Logic” se cell
existing scan clk
chain clock New scan cell

If you use the -Model switch in combination with the -Observe switch, LBISTArchitect
controls the test point by adding an additional scan cell when the test logic is synthesized, as
shown in Figure 2-7. The tool fits each of the new scan cells into a nearby existing scan
chain that does not exceed the chain length limit. The clock for each new scan cell is the
same as the scan cell it feeds in the chain. If LBISTArchitect cannot find a nearby chain,
then it drops the observe point.
If you use the -New_scan_cell switch in combination with -Observe, it behaves much the
same as when using -Model, except LBISTArchitect will choose the new cell to be edge
compatible with the existing scan cells in the target scan chain when the test logic is
synthesized (Figure 2-8). This matching of the rising/falling edge attribute will prevent D7-
type DRC violations. The tool fits each of the new scan cells into nearby existing scan
chains that do not exceed the chain length limit. The clock for each new scan cell is the same
as the scan cell it feeds in the same chain. If a nearby chain cannot be found, then it drops
the observe point.

LBISTArchitect Reference Manual, v2017.3 325

September 2017
BIST-Ready Command Dictionary
Setup Test_point Insertion

Figure 2-8. Observe Point Example with -New_scan_cell

Connected by
“Insert Test Logic”
/I$21 /I$23

(if -New_scan_cell)
D Q
Connected by si so next scan
“Insert Test Logic” se cell
existing scan clk
chain clock New edge-compatible
scan cell

• pin_pathname -None
An optional string and switch pair that specifies for LBISTArchitect to only insert the test
point without inserting an additional scan cell, as shown in Figure 2-5 and Figure 2-7. This
is the default for control points.
• observe_enable -Existing_scan_cell
An optional switch and string pair that specifies for LBISTArchitect to use nearby scan cells
for observation points, as shown in Figure 2-6. The observe_enable string specifies the
name of the observe enable signal that controls the input to the scan cell. This is the default
for observe points
The tool propagates the observe point to a nearby scan cell and multiplexes it with the cell’s
functional-path D input. In this case, you must specify the “data_in” parameter in the
scan_definition section of the model for all scan cells used in the design. This option is only
valid with the -Observe switch.
• -New_scan_cell — An optional switch that specifies for LBISTArchitect to determine the
rising/falling edge of scan cells in use in the nearby target scan chain, and to use an edge-
compatible scan cell model for the new scan cell. You must identify the type of the scan cell
models with the Add Cell Models command or have the type assigned in the library models
before using this switch. See Figure 2-8.
• -Model modelname
An optional switch and string pair that specifies for LBISTArchitect to insert a cell along
with the test point, as shown in Figure 2-5 and Figure 2-7. The specified model must be of
type SCANCELL. You must identify the type of the modelname with the Add Cell Models
command or have the type assigned in the library model before using this switch.
Note
When in MTPI mode, scan cells cannot be used for control points, thus you cannot use
the -Model option.

326 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Test_point Insertion

• -REconvergence {OFf | ON}

An optional switch and literal pair that enables the sharing of test points based on
reconvergence analysis. LBISTArchitect performs reconvergence analysis to determine
which test points can share the same pin and scan cell. If the backward cones of observe
points or the forward cones of control points intersect, the test points are not shared. When
this option is On, the amount of sharing is limited, which guarantees that no fault masking
can occur due to sharing (often a negligible phenomenon). The sharing is also influenced by
the existence of scan chains inside of modules when new scan cells are used for testpoints.
In this case, a nearby scan chain may be used for the new scan cell created by the shared tree
of test points. The default is Off.
• -OShare integer
An optional switch and integer pair that specifies the maximum number of observe points
you want LBISTArchitect to share with a single scan cell. The default maximum number of
observe points that LBISTArchitect will allow to share a single scan cell upon invocation is
16.
Not all observe points can share a single scan cell. If you enable the -Reconvergence option
and the backward trace of any two observe points intersect, they must use separate scan
cells. This may result in less than the maximum number of observe points sharing any given
scan cell.
• -CShare integer
An optional switch and integer pair that specifies the maximum number of X-sources or
control points that the tool can drive from each new scan cell. This switch affects X-
bounding when you use the “Setup X_bounding -Connect_to new_scan_cell” command,
and affects the control points that you create manually with the Add Test Points command.
This switch does not affect the MTPI control points since they are not driven by the scan
cells.
• -Time_based_capture {OFf | ON}
An optional switch that specifies for the tool to take into account both the clock edge timing,
and the clock frequency when selecting capture flip-flops for observe points, and for the
clocking of the new scan cells used for X-bounding when issuing the “Setup X_bounding
-Connect_to new_scan_cell” command.
The tool uses the following rules to deal with clock edge relationships:
• If all inputs are positive edge-based, the tool uses a positive edge flip-flop at the observe
point.
• If all inputs are negative edge-based, the tool also sets the output to negative-edge.
• When an observe point is driven by both positive and negative edge logic, the choice of
the clock edge for the observe point is arbitrary.
The tool always sets the output frequency to the lowest value from the inputs.

LBISTArchitect Reference Manual, v2017.3 327

September 2017
BIST-Ready Command Dictionary
Setup Test_point Insertion

Examples
The following example shows the flow of having LBISTArchitect automatically identify and
insert two test points for controllability:
set system mode dft
setup scan identification none
setup test_point identification -control 2
run
// Performing test_point identification ...
// Number of control points to be identified = 2
// Number of observe points to be identified = 0
// 1: CV1=16458424 gate_index=3805 INV /CNTR/U783/ZN
// 2: CV1=16458417 gate_index=1058 BUF /ADDR/U23/D1

add cell models dffslp -type scancell CK D SDI SE

add cell models or2a -type or
add cell models and2a -type and
setup test_point insertion -control test_cntrl1
insert test logic -test_point on
report test points
Control [Selected]: /CNTR/U783/ZN and2a test_cntl1
Control [Selected]: /ADDR/U23/D1 or2a test_cntl1

Related Commands
Add Cell Models Setup Scan Identification
Insert Test Logic Setup Test_point Identification
Add Notest Points

328 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Tied Signals

Setup Tied Signals

Scope: Setup mode
Usage
SETup TIed Signals 0 | 1 | X | Z
Description
Changes the default value for floating pins and floating nets that do not have assigned values.
The Setup Tied Signals command specifies the default value that the tool ties to all floating nets
and floating pins that are not specified with the Add Tied Signals command. Upon invocation of
the tool, if you do not assign a specific value, the tool assumes the default value is unknown.
If the model is already flattened and then you use this command, you must delete and recreate
the flattened model.
Arguments
• 0
A literal that specifies to tie the floating nets or pins to logic 0 (low to ground).
• 1
A literal that specifies to tie the floating nets or pins to logic 1 (high to voltage source).
• X
A literal that specifies to tie the floating nets or pins to unknown.
• Z
A literal that specifies to tie the floating nets or pins to high-impedance
Examples
The following example ties floating net vcc to logic 1 and ties the remaining unspecified
floating nets and pins to logic 0, then performs a scan identification run.
setup tied signals 0
add tied signals 1 vcc
set system mode dft
run

Related Commands
Add Tied Signals Report Tied Signals
Delete Tied Signals

LBISTArchitect Reference Manual, v2017.3 329

September 2017
BIST-Ready Command Dictionary
Setup Wrapper Chains

Setup Wrapper Chains

Scope: Setup mode
Usage
SETup WRapper Chains [-EXClude pin_names…] [{-INPUT_NUMber integer}
| {-INPUT_MAX_length integer}] [{-OUTPUT_NUMber integer}
| {-OUTPUT_MAX_length integer}] [-INPUT_Threshold {integer | Nolimit}]
[-OUTPUT_Threshold {integer | Nolimit}]
[{-No_internal_feedback | -Allow_internal_feedback | -Test_points}] [-Verbose]
Description
Specifies wrapper chains for scan insertion as follows:
• Setup Pin Constraints CX -Lbist_exclude
• Setup Output Masks On -Lbist_exclude
• Setup Scan Identification Wrapper_chains
Wrapper cells are sequential elements used as input/output registration cells (cells only
accessible via combinational logic from primary inputs or primary outputs). Depending on the
specified switches, wrapper cells are identified and distributed to scan chains in either
one-domain or two domains.
Wrapper cell distribution is determined by the switches: -Input_number, -Input_max_length, -
Output_number, or -Output_max_length.
If any of these switches are specified, two-domain distribution is used. If none are specified,
one-domain distribution is used.
• One-domain distribution — Wrapper cells are distributed to scan chains as specified
by the -number, -max_length, and -nolimit arguments of the Insert Test Logic command.
The SEN type scan_enable signal is used for both one-domain wrapper chains and core
chains.
• Two-domain distribution — Input and output wrapper cells are distributed separately
to input wrapper chains and output wrapper chains. When two-domain distribution is
enabled, the -Number, -Max_length, and -Nolimit arguments of the Insert Test Logic
command are ignored and separate, dedicated scan enable signals are used; SEN_IN
type for input, SEN_OUT type for output, and SEN for core chains.
You can modify the scan enable signals with the Set Scan_enable Sharing command and the Set
Scan Enable command.
You can specify how wrapper cells are identified with the -No_internal_feedback,
-Allow_internal_feedback, and -Test_points switches. By default, the tool identifies the wrapper
cells by structurally tracing forward from the primary inputs until the first level of memory cells
is reached and then, traces backward from the primary outputs until the last level of memory

330 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Wrapper Chains

cells is reached. Figure 2-9 illustrates the default tracing where the traced logic and identified
wrapper cells are shown in bold.

Figure 2-9. I/O Identification Default Tracing Mode

To control all the inputs of the combinational logic traced from the primary inputs, use the -
Allow_internal_feedback switch. Figure 2-10 shows the gate inputs with feedback connections
marked as a and b. Tracing backward from these inputs identifies one additional cell from the
second level of memory cells to include in the input wrapper chains.

Figure 2-10. All Input Logic Tracing

Depending on the circuit topology, tracing such internal feedback may include an impractical
number of core cells (not first or last level memory cells). In that case, you can control the
feedback inputs on the logic gates by means of control points. In the above circuit, only the gate
input b requires a control point because gate input a is controlled from its driver gate which is an
identified input wrapper cell. In a multiple-phase testing of wrapper cells and core cells (i.e.
hierarchical at-speed testing at a higher level of the design), the gate output marked as c cannot
be observed when the testing of core cells is active and the testing of input wrapper cells is
inactive. In that case, an observe point may be necessary at the gate output c.
The automatic insertion of such control and observe points can be specified using the
-Test_points switch. Upon issuing the Run command, the test point locations are identified
along with the wrapper cell candidates. The identified test points are scheduled for insertion

LBISTArchitect Reference Manual, v2017.3 331

September 2017
BIST-Ready Command Dictionary
Setup Wrapper Chains

automatically. At this point, you can examine and modify the scheduled test points with the
following commands: Report Test Points, Add Test Points, and Delete Test Points. The actual
insertion of the test points occurs later when the Insert Test Logic command is issued.
Figure 2-11 highlights the logic the tool adds as the control and observe points. The tool uses
SEN_OUT type scan enable for the control points and SEN_IN type scan enable for the observe
points, where possible.

Figure 2-11. Control and Observe Point Insertion

Arguments
• -Exclude pin_names
An optional switch and a repeatable string that specifies the primary input/output pins to
exclude from the wrapper cell identification process. The system clock pins (set, reset,
clock, etc.) and test-related pins such as scan I/O, scan enable and test enable pins are
excluded from the identification process automatically.
• -INPUT_NUMber integer
An optional switch and an integer pair that enables two-domain distribution and specifies
the number of scan chains for input wrapper cells. The default value for the number of input
wrapper chains is 1.
• -INPUT_MAX_length integer
An optional switch and an integer pair that enables two-domain distribution and specifies
the maximum length of scan chains for input wrapper cells. The default value for the
maximum length of the input wrapper chains is unlimited.
• OUTPUT_NUMber integer
An optional switch and an integer pair that enables two-domain distribution and specifies
the number of scan chains for output wrapper cells. The default value for the number of
output wrapper chains is 1.

332 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup Wrapper Chains

• -OUTPUT_MAX_length integer
An optional switch and an integer pair that enables two-domain distribution and specifies
the maximum length of scan chains for output wrapper cells. The default value for the
maximum length of the output wrapper chains is unlimited.
• -INPUT_Threshold {integer | Nolimit}
An optional switch and integer or literal pair that specifies the maximum number of wrapper
cells to identify from primary inputs. The default is Nolimit.
• -OUTPUT_Threshold {integer | Nolimit}
An optional switch and integer or literal pair that specifies the maximum number of wrapper
cells to identify from primary outputs. The default is Nolimit.
• {-No_internal_feedback | -Allow_internal_feedback | -Test_points}
An optional switch that specifies the identification mode for input wrapper cells. Options
include:
-No_internal_feedback — Identifies the first level of registration cells by forward
tracing from the primary inputs. This is the default mode.
-Allow_internal_feedback — Identifies additional cells with outputs fed back into the
combinational logic between the primary inputs and the first level of registration
cells.
-Test_points switch — Inserts control and observe points at the feedback connections
instead of identifying additional cells from these feedback connections.
• -Verbose
An optional switch that prints a detailed session transcript during wrapper cell identification
including the instance pathnames of all identified wrapper cells per I/O.
Examples
The following example excludes the primary I/O pins a and b from wrapper cell identification;
Sets up four input wrapper scan chains and eight output wrapper scan chains; Sets sen1 and sen2
for the scan enable pin names of the input and output wrapper chains and reports the sequential
cells identified per I/O pin.
add cell model LATX -type dlat G D
add cell model INVX -type inv
setup wrapper chains -input_num 4 -output_num 8 -exclude a b
set scan enable sen1 -wrapper_chain -input
set scan enable sen2 -wrapper_chain -output
set system mode dft
run
report wrapper cells
insert test logic -clock merge -edge merge

LBISTArchitect Reference Manual, v2017.3 333

September 2017
BIST-Ready Command Dictionary
Setup Wrapper Chains

Related Commands
Add Test Points Setup Scan Identification
Delete Test Points Set Scan Enable
Report Test Points Set Scan_enable Sharing
Run Write Netlist
Setup Output Masks

334 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup X_bounding

Setup X_bounding
Scope: Dft mode
Usage
SETup X_bounding
[-Connect_to {Existing_scan_cell | Power_or_ground | [New_scan_cell -Model
scan_cell_model -Clock clock_for_new_scan_cells]}
[-SCAN_Drive_limit integer] [-SCAN_Cell_proximity integer]
[-Lbist_enable name] [-DONT_Bound pins…]
[-DONT_Constrain {-All | pins…}] [-Off] [-Verbose]
[-Bound_all_feedbacks]
Description
Defines the X bounding parameters.
Part of preparing a circuit for logic BIST requires ensuring that no unknown states (Xs)
propagate to the MISR, as that corrupts the signature. After scan selection and before test point
identification, the BIST-Ready phase of LBISTArchitect can identify potential X sources and
bound them.
For X bounding, even if the X does not propagate to an observe point, it will still be bound, as
there is no guarantee that an observe point will not be added later, making the X observable. To
bound primary inputs, there should be X pin constraints on the inputs, such that X bounding will
treat them as X sources and bound them. The Setup X_bounding command performs both X
bounding and sets X constraints.
Normally, you would add the Setup X_bounding command, with your specified options, to the
dofile for a separate X bounding run. But if you specify the Setup Test-point Identification
command in a BIST-Ready run, and you have not yet performed X bounding, then, by default,
LBISTArchitect turns Setup X_bounding on and the default values apply. You can add the
Setup X_bounding command to the MTPI run dofile to change these defaults, if necessary. If
you have already performed X bounding, the default for this command is OFF and
LBISTArchitect produces a message that summarizes the X bounding solution and then asserts
the controlling signal (lbist_en).
You can bound X sources in either of three ways. The first method (Existing_scan_cell) is to
bound the X source by connecting to a nearby scan cell (which would supply pseudorandom
patterns) in test mode. This is the invocation default.
The second method (New_scan_cell) is to bound the X source by connecting to a new scan cell
instead of using an existing nearby scan cell.
The third method (Power_or_ground) consists of adding an AND or OR gate that supplies a
constant 0 or 1 in test mode, respectively. Selection of whether to bound to a 0 or 1 is based on
trying to find the non-controlling value of the X source fanout. You do that to reduce the chance
that the bounding will block the propagation of other faults arriving at its fanout gate. This
method results in lower fault coverage and is therefore not recommended.

LBISTArchitect Reference Manual, v2017.3 335

September 2017
BIST-Ready Command Dictionary
Setup X_bounding

When reporting test points using the Report Test Points command, control points added for
bounding will be of type “Bounding”.

Arguments
• -Connect_to {Existing_scan_cell | Power_or_ground | {New_scan_cell -Model
scan_cell_model -Clock clock_for_new_scan_cells}]}
An optional switch and literal pair that specifies how bounding will occur.
Existing_scan_cell — An optional literal (invocation default) that specifies to perform
bounding by multiplexing the X-source output with a nearby scan cell. This has the
advantage of supplying pseudorandom patterns in test mode (lbist enable = 1).
Power_or_ground — An optional literal that specifies to perform bounding by tieing the
X-source output to a constant 0 or 1 by adding an AND or OR control point,
respectively, which is controlled on the other input by the inverted lbist enable or lbist
enable, respectively. This method results in lower fault coverage and is therefore not
recommended.
New_scan_cell — An optional literal that specifies to bind the X-sources by inserting
new scan cells to drive the signals. You can control the number of X-sources that each
new scan cell can drive using the “Setup Test_point Insertion -CShare” command.
-Model scan_cell_model — An optional switch and string pair that specifies the type
of scan cell that the tool inserts to drive X-sources. This option is only required
when you have specified more than one scan model with the Add Cell Models
command.
-Clock clock_for_new_scan_cells — An optional switch and string pair that
specifies the name of an existing clock that will drive all the new X-sources. The
available clocks come from the names you previously specified in the Add Clocks
command.
The default behavior is to select the clock of the new scan cell to match the
clocking of the previous flip-flop in the chain. However, if you have already
issued the “Setup Test_point Insertion -Time_based_capture ON” command, the
tool determines the clock of the new scan cell by analyzing the fanout from the X-
source. If the fanout includes multiple clock domains, the tool uses the slowest
clock (as defined by the Set Clock Period command).
• -SCAN_Drive_limit integer
An optional switch and integer pair that specifies a limit on how many Mux-type control
points one scan cell can drive for bounding. Having one scan cell drive a large number of
Mux control points can reduce test coverage, due to structural dependency. 0 means there is
no limit. The invocation default is 4.
• -SCAN_Cell_proximity integer
An optional switch and integer pair that specifies how many levels of logic away to search
for a scan cell to solve the X source problem. This switch provides an additional control on
the topological distance at which LBISTArchitect begins its search for an existing scan cell.

336 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Setup X_bounding

The default is 3, but in some circumstances, for instance, where reconvergent fanouts would
affect fault coverage, you may need to increase the distance with integer, to ensure an
acceptable solution.
• -Lbist_enable name
An optional switch and string pair that specifies the name of a signal which will control the
X bounding logic. The default is for BIST-Ready to use a global test enable signal for the
control of X bounding logic. This switch allows the use of a user-specified signal.
• -DONT_Bound pins
An optional switch and repeatable string that specify a list of pins that are not to be bounded,
even if they have pin constraints (X pin constraints in the case of X bounding). If you do not
specify any pins, LBISTArchitect clears the exclude list and bounds all X sources.
• -DONT_Constrain -All | pins
An optional switch and literal or repeatable string that specify to exclude all primary inputs
from being constrained to X, or to exclude just the specified pins from being constrained to
X. The default is to constrain all primary inputs to X, except for the following signals:
scan enable
scan inputs
scan outputs
test enable
lbist enable
clocks
• -Off
An optional switch that explicitly turns X bounding off. X bounding normally takes place
during a run after scan selection (if any) and just before test point identification, but if you
are performing a MTPI run, Setup X_bounding is ON by default if you have not already
performed X bounding in a previous run. If, for some reason, you do not want to perform X
bounding in the case just mentioned, use the -Off switch to turn off the default. In all other
cases, the invocation default is Off.
• -Verbose
An optional switch that specifies to turn on the verbose level of reporting on potential X
sources. If the verbose option is turned on, LBISTArchitect reports every potential X
source, as well as how and where each is bounded. The invocation default is off.
• -Bound_all_feedbacks
An optional literal that specifies to override the default behavior and add x-bounding logic
that explicitly breaks all feedback loops. By default, LBISTArchitect performs stability
analysis for all feedback loops and eliminates feedback loops that maintain a constant value
(regardless of clock activity) from being a target for x-bounding.
Examples
The following example shows the necessary commands used in a normal X bounding run:

LBISTArchitect Reference Manual, v2017.3 337

September 2017
BIST-Ready Command Dictionary
Setup X_bounding

setup x_bounding
setup scan identification none
set system mode dft
run
add cell model MUX21HA -type mux S A B
insert test logic -test_point on -scan off
…

Related Commands
Report BIST Bounding Setup Test_point Insertion

Command Summary

338 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Synthesize

Synthesize
Scope: Dft mode
Usage
SYNthesize
Description
Inserts test structures into the netlist to increase the design’s testability.
The Synthesize command inserts scan and/or testpoints based upon setup commands.
Information derived from scan analysis, testpoint analysis, and lockup latch processing setup
commands guide the Synthesis command’s operations without the need for using the extensive
options of the Insert Test Logic command.
Rather than receiving information from the following Insert Test Logic command options,
Synthesize derives the information directly from the following commands.:
Table 2-11. Insert Test Logic versus Synthesis
Insert Test Logic option New location
-Scan on Setup Scan Identification
-Test_point on Setup Test_point Identification
-Max_length # Setup Scan Identification -Max_length #
-Number # Setup Scan Identification -Number #

Note
The Synthesize command simplifies your choices by providing default behavior, instead
of executing the more complex Insert Test Logic command.

Examples
The following example inserts test structures into the netlist:
set system mode dft
setup scan identification -number 8 -max_length 100
setup test_point identification -control 10
run
...
synthesize

Related Commands
Insert Test Logic Setup Scan Identification
Setup Test_point Identification

LBISTArchitect Reference Manual, v2017.3 339

September 2017
BIST-Ready Command Dictionary
System

System
Scope: All modes
Usage
SYStem os_command
Description
Passes the specified command to the operating system for execution.
The System command executes one operating system command without exiting the currently
running application.
Arguments
• os_command
A required string that specifies any legal operating system command.
Examples
The following example performs a scan identification run, then displays the current working
directory without exiting the BIST-Ready phase of LBISTArchitect:
set system mode dft
run
system pwd

340 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Verify Scan

Verify Scan
Scope: Dft mode
Usage
Verify Scan
Description
Verifies that newly inserted scan can pass DRC.
The Verify Scan command is issued to test the conformity of clocking, scan, and pin
constraints. This command encompasses several verification steps often added by users at the
end of their runs. Users frequently write out an ATPG setup file, followed by returning to Setup
mode. They then delete the pin constraints, clocks, and scan information. The ATPG setup file
is then read back in and DFT mode entered to perform DRC checking. At this point, a Report
Dft Check -Nonscan is usually performed. This step validates that the ATPG setup file contains
correct clocking, scan, and pin constraint information for tools later in the flow.
The Verify Scan command encompasses all of the steps listed previously. During its operation,
DRC failures and DFT checking information is displayed. The temporary file used for writing
and subsequently reading the ATPG setup information is removed after completion of this
command.
Examples
This is an example of a typical usage for the Verify Scan command:
analyze control signals -auto_fix
set system mode dft
run
insert test logic -number 8
write netlist scan.v -verilog -replace
write atpg setup setup -replace
verify scan

Using the Verify Scan command replaced the following commands typically utilized at the end
of a script:
analyze control signals -auto_fix
set system mode dft
run
insert test logic -number 8
write netlist scan.v -verilog -replace
write atpg setup setup -replace
write atpg setup /tmp/verify_setup.pid -rep
set system mode setup
delete clocks -all
delete pin constraints -all
delete scan groups -all
delete scan chains -all
dofile /tmp/verify_setup.pid verify_setup.dofile
set system mode dft
report drc rules -fails -verbose
report dft check -nonscan

LBISTArchitect Reference Manual, v2017.3 341

September 2017
BIST-Ready Command Dictionary
Verify Scan

Related Commands
Report Dft Check

342 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write BIST Setup

Write BIST Setup

Scope: Dft mode
Prerequisites
You should enter all setup commands before executing this command. You must execute a
Write Netlist command before a Write BIST Setup command to ensure inclusion of a Setup
Synthesis Script command in the BIST Controller Synthesis driver file.
Usage
WRIte BIst Setup [module_filename] [dofile_filename] [-Replace] [-VErilog]
Description
Writes the top-level design interface and dofile used in the BIST Controller phase of
LBISTArchitect.
The Write BIST Setup command writes out two files used by the BIST Controller Synthesis
phase of LBISTArchitect: the design’s top-level interface and a dofile. After scan insertion with
the BIST-Ready phase, you need these files when you run the BIST Controller phase.
The top-level design interface file describes the input/output pin instances of the core design.
The pin instances LBISTArchitect writes to this file are the same as the ones it reads from the
top-level Verilog module.
The dofile contains commands that specify the internal scan chains, set up the BIST controller,
optionally set up multiphase test points, run the BIST Controller Synthesis phase, and save the
results.
Note
If you execute this command after switching back to Setup mode some information is lost
and not written to the dofile.

Another line that Write BIST Setup normally generates automatically for the dofile is a Setup
Synthesis Script command for use in the BIST Controller Synthesis phase. However, the BIST-
Ready phase will include this line only if it encounters a Write Netlist command before the
Write BIST Setup command. This order of commands is the only way LBISTArchitect will
know about the output file name. If it sees the commands in the reverse order, it will silently
skip adding the Setup Synthesis Script command to the dofile.
When the BIST Controller Synthesis phase sees a Setup Synthesis Script command before
encountering a Save BIST command, it writes out a Design Compiler synthesis script as part of
the Save BIST files.
Arguments
• module_filename
An optional string that specifies the name of the file to which LBISTArchitect writes the
top-level design interface. The default filename upon invocation is bist_in.v.

LBISTArchitect Reference Manual, v2017.3 343

September 2017
BIST-Ready Command Dictionary
Write BIST Setup

• dofile_filename
An optional string that specifies the name of the file to which LBISTArchitect writes the
dofile. The default upon invocation is bist.dofile.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the files, if
the files already exist. The default upon invocation is not to replace the files.
• -Verilog
An optional switch that specifies to write the design interface in Verilog format. The default
upon invocation is the format of the input netlist.
Examples
The following example performs all the setup, then writes the design interface and dofile files:
add scan groups grp1 s9234.testproc
add scan chains chain1 grp1 scan_in1 scan_out1
add clocks 0 clock
set capture clock clock
setup test_point identification -control 6 -observe 2 -patterns 1023 -base multiphase -verbose
-test_coverage 95.0 -phases 4 -bpcthreshold 7 -sigprobthreshold 0.05 -num_detections 1
set system mode dft
setup scan identification none
run
add cell models or2a -type or
add cell models n1l -type inv
add cell models and2a -type and
add cell models fd1sqa -type sdff CP D
setup scan insertion -sen scan_en
insert test logic -test_point on -scan off
write netlist s9234_1_scan_mptp.v -verilog -replace
write bist setup -replace

Related Commands
Write Netlist

Command Summary

344 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Formal_verification Setup

Write Formal_verification Setup

Scope: Dft mode
Usage
WRIte FOrmal_verification Setup constraint_filename [-Replace]
Description
Writes a constraints driver file for the formal verification tool, FormalPro.
You can use the constraints file with FormalPro to verify that any BIST-Ready additions have
not functionally changed the design. The output file describes the BIST-Ready changes that
FormalPro needs to ignore when comparing against the non-scan (reference) design. The
constraints file will contain the following constraints:

• Force all scan inputs to 1

• Ignore all scan outputs (including scan-outs shared with primary output pins)
• Force scan enables to be in functional mode
• Constrain test_en, lbist_en, and test_obs to their inactive states
When you enable observe point sharing and sink the tree into a new scan cell, FormalPro
automatically ignores the extra registers (observe point registers) found in the BISTed design.

You can perform formal verification after any BIST-Ready step. FormalPro always compares
the original non-scan design to the current output of BIST-Ready.

Arguments
• constraint_filename
A required string that specifies the name of the file to which LBISTArchitect writes the
formal verification constraints file.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the file,
constraint_filename, if the file already exists.
Examples
The following example writes out a constraints file named mtpi.constraints and also includes a
shell script to invoke FormalPro:
//mtpi dofile
//perform mtpi analysis and test logic synthesis
write netlist m8051_mtpi.v -replace
write formal_verification setup mtpi.constraints -replace
exit -force

#shell script to run FormalPro

LBISTArchitect Reference Manual, v2017.3 345

September 2017
BIST-Ready Command Dictionary
Write Formal_verification Setup

<Formal_Pro_Tree>/bin/formalpro -a -verilog m8051_core.v \

-b -verilog m8051_mtpi.v -common -lib lcbg10p_atpg.lib \
-constraintfile mtpi.constraints -overwrite

Related Commands
Write Netlist

Command Summary

346 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Loops

Write Loops
Scope: Dft mode
Usage
WRIte LOops filename [-Replace]
Description
Writes a list of all loops to the specified file.
The Write Loops command writes all loops in a circuit to a file. For each loop, the report
indicates whether the loop was broken by duplication. Loops that are not broken by duplication
are shown as being broken by a constant value, which means the loop is either a coupling loop,
or has a single multiple fanout gate. The report also includes the pin pathname and gate type of
each gate in each loop.
You can display the loops report information to the transcript by using the Report Loops
command.
Arguments
• filename
A required string that specifies the name of the file to which LBISTArchitect writes the loop
report information.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the file, if
the file already exists.
Examples
The following example writes a list of all loops to a file:
set system mode dft
write loops loop.info -replace

Related Commands
Report Loops

LBISTArchitect Reference Manual, v2017.3 347

September 2017
BIST-Ready Command Dictionary
Write Netlist

Write Netlist
Scope: All modes
Usage
WRIte NEtlist filename [-Replace] [-User_setup] [-Split_bus]
Description
Writes the current design to a Verilog netlist. Depending on the process, the current design is
either the one used to invoke LBISTArchitect or the one created by the scan insertion process.
Arguments
• filename
A required string that specifies a pathname for the Verilog netlist.
• -Replace
An optional switch that overwrites the contents of the specified file if it already exists.
• -User_setup
An optional switch that writes the design netlist based on the state of the current design,
with respect to Add Black Box and Delete Black Box commands.
• -Split_bus
An optional switch that writes out mapped buses as individual pins in the port mapping. By
default, all pins are listed together. For example:
By default, bus pins are written as follows:
ex_mod ex_inst (.ex_bport (a[3:0]), ...

If the -Split_bus switch is used, bus pins are written as follows:

ex_mod ex_inst (.ex_bport ({a[3], a[2], a[1], a[0]}), ...

Examples
The following example adds scan and writes out a Verilog netlist named verilog.scan.
add clocks 0 clock
set system mode dft
setup scan identification sequential full_scan -percent 50
run
insert test logic -max_length 10
write netlist verilog.scan

Related Commands
Write Scan Setup Delete Black Box
Add Black Box

348 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Primary Inputs

Write Primary Inputs

Scope: All modes
Usage
WRIte PRimary Inputs filename [-Replace] [-All | primary_input_pin…]
Description
Writes primary inputs to the specified file.
The Write Primary Inputs command writes a list of either all the primary inputs of a circuit or a
specific list of primary inputs that you specify, into a file where it can be reviewed.
This command is identical to the Report Primary Inputs command except the data is written into
a file.
Arguments
• filename
A required string that specifies the name of the file to which LBISTArchitect writes the
primary inputs.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the file, if
the file already exists.
• -All
An optional switch that specifies to write all the primary inputs to the file. This is the
default.
• primary_input_pin
An optional repeatable string that specifies a list of primary input pins that you want to write
to the file.
Examples
The following example writes all primary inputs to a file:
write primary inputs inputfile

Related Commands
Report Primary Inputs

LBISTArchitect Reference Manual, v2017.3 349

September 2017
BIST-Ready Command Dictionary
Write Primary Outputs

Write Primary Outputs

Scope: All modes
Usage
WRIte PRimary Outputs filename [-Replace] [-All | primary_output_pin…]
Description
Writes primary outputs to the specified file.
The Write Primary Outputs command writes a list of either all the primary outputs of a circuit or
a specific list of primary outputs that you specify into a file where it can be reviewed.
This command is identical to the Report Primary Outputs command except the data is written
into a file.
Arguments
• filename
A required string that specifies the name of the file to which LBISTArchitect writes the
primary outputs.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the file, if
the file already exists.
• -All
An optional switch that specifies to write all the primary outputs to the file. This is the
default.
• primary_output_pin
An optional repeatable string that specifies a list of primary output pins that you want to
write to the file.
Examples
The following example writes all primary outputs to a file:
write primary outputs outputfile

Related Commands
Report Primary Outputs

350 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Procfile

Write Procfile
Scope: All modes
Usage
WRIte PRocfile proc_filename [-Replace] [-Full]
Description
Writes existing procedure and timing data to the named enhanced procedure file.
The Write Procfile command writes out existing procedure and timing data to the named
enhanced procedure file.
Arguments
• proc_filename
A required string that specifies the name of the file to which you want to write existing
procedure and timing data.
• -Replace
An optional switch that replaces the contents of the file if the proc_filename already exists.
• -Full
An optional switch that causes the tool to parse the ATPG pattern list (if any) and create all
needed non-scan procedures before writing the procedure file data.
Note
The -Full option can cause the Write Procfile command to take more time if there are a
large number of ATPG-generated patterns in the internal pattern list.

Examples
The following example writes the existing procedure and timing data to the specified file:
write procfile myprocfile.proc

Related Commands
Add Scan Groups
Read Procfile

LBISTArchitect Reference Manual, v2017.3 351

September 2017
BIST-Ready Command Dictionary
Write Scan Identification

Write Scan Identification

Scope: All modes
Usage
WRIte SCan Identification filename [-Replace] [-Full | -Identified | -Defined]
[-DOfile | -Backannotation]
Description
Writes a list of the scan instances which LBISTArchitect has identified or you have defined as
scan cells.
The Write Scan Identification command writes scan cell instances that either LBISTArchitect
identified during the identification process or that you defined by using the Add Scan Instances
or Add Scan Models commands. The Write Scan Identification command lists the scan
instances in descending order, with the first instance being the most critical scan instance.
If you are identifying scan sequential, the Write Scan Identification command displays the
sequential loops that LBISTArchitect cut after you have performed the identification process
with the Run command.
If you are identifying partition scan, the Write Scan Identification command displays the
partition cells that LBISTArchitect flagged during the identification process that you perform
with the Run command.
If you issue the command without specifying -Backannotation or -Dofile options, the command
writes both identified and defined scan instances.
Arguments
• filename
A required string that specifies the name of the file to which LBISTArchitect writes the scan
instances.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the file, if
the file already exists.
• -Full | -Identified | -Defined
An optional switch that specifies at what level to write the file. The -Full option specifies to
write both identified and defined scan instances. This is the default. The -Identified option
specifies to write only scan instances that LBISTArchitect identified during the
identification process. The -Defined option specifies to only write scan instances that you
defined by using the Add Scan Instances or Add Scan Models commands.
• -DOfile | -Backannotation
An optional switch that specifies to write the scan instances in dofile or backannotation
format. In dofile format, the file is written as a list of lines which can be executed by the
Dofile command.

352 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Scan Identification

For example:
add scan instances instance_pathname

Examples
The following example writes all scan instances to a file after performing a full scan
identification run:
set system mode dft
setup scan identification full_scan
run
write scan identification scanfile -identified

The following is an example of the files contents:

Type Instance
-------------------------------------
defined /I_1_16
identified /I_1_16
identified /I_6_16
identified /I_8_16

Related Commands
Report Sequential Instances

LBISTArchitect Reference Manual, v2017.3 353

September 2017
BIST-Ready Command Dictionary
Write Scan Order

Write Scan Order

Scope: All modes
Usage
WRIte SCan Order {-Def | -Scandef} [-Endpoints] filename [-Replace]
[-No_segmentation] [-Keep_short_segments]
Description
Creates specified DEF file.
After the tool performs scan chains insertion, the Write Scan Order command can be used to
create a DEF representation. The tool can use the original netlist and the DEF to create an
updated netlist and ATPG setup.
Note
As DEF is a flat format, a hierarchical circuit is automatically flattened when the Write
Scan Order command is executed. If the sub-chain subset of DEF is written (-Scandef),
no flattening step is necessary.

Reading a complete DEF may be slow since these files can be quite large. However, you
can submit a stubbed DEF with only the SCANCHAIN section.

Arguments
• -Def | -Scandef
A required switch that specifies for a complete, structural DEF file to be produced or for a
subset DEF with scan chains.
• -Endpoints
An optional switch will cause only the start and stop scan cells in each chain to be
represented. It would be up to the Place & Route tool to analyze the topology between these
scan cells to identify the remaining scan cells in the chain.
• filename
A required string that specifies the name of the file to which the tool writes the scan
instances.
• -No_segmentation
An optional switch that disables the segmentation of scan chains in the DEF file. By default,
scan chains with different clocks/edges are segmented into separate chains. This behavior
preserves the location of the first and the last scan cells of different domains in the scan
chain.
If you disable the segmentation of scan chains, lockup cells inserted between the cells of
different domains may be placed in the wrong position and cause the scan chain to fail.

354 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Scan Order

Also, this switch disables the insertion of the PARTITION and MAXBITS keywords in the
DEF file. These keywords allow you to move scan chains between the floating blocks
defined in the DEF file.
• -Keep_short_segments
An optional switch that specifies that scan chains that contain only one or two scan cells
AND contain no lockup latches are written to the scan DEF file and are not commented out;
by default, scan chains of this type are written to the scan DEF file and are commented out.
Examples
The following example causes a complete, legal DEF file to be produced:
write scan order -def deffile

Related Commands
Add Scan Pins

LBISTArchitect Reference Manual, v2017.3 355

September 2017
BIST-Ready Command Dictionary
Write Scan Setup

Write Scan Setup

Scope: Dft mode
Prerequisites
You must insert the scan chains before using this command.
Usage
WRIte SCan Setup [procedure_filename [setup_filename]] [-Replace]
Description
Writes the test procedure file and the dofile for inserted scan chains to the specified files.
The Write Scan Setup command writes the test procedure file and the dofile file for the inserted
scan chains with the names you specify. You can use these files to identify the scan chains when
loading the scan design into the Fault Simulation phase.
LBISTArchitect outputs different levels of enhanced procedure file information depending on
whether you have first issued the Read Procfile command:
• If you execute the Write Scan Setup command without first using the Read Procfile
command, LBISTArchitect produces an enhanced procedure file that contains default
timeplates and just the procedures that are needed for Fault Simulation setup (for
example, Shift, Load_unload, and Test_setup).
• If you first run Read Procfile and load an enhanced procedure file that contains timeplate
definitions, non-scan procedure definitions (capture, ram_sequential, and others), and
empty or template scan procedures, then execute the Write Scan Setup command,
LBISTArchitect produces a more complete enhanced procedure file.
Arguments
• procedure_filename
An optional string that specifies the name of the test procedure file that LBISTArchitect
creates for the Fault Simulation phase. The default name is scan.procedure.
• setup_filename
An optional string that specifies the name of the dofile that LBISTArchitect creates for the
Fault Simulation phase. The default name is scan.dofile.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the file, if
the file already exists.
Examples
The following example writes the test procedure, the dofile, and the new netlist for the inserted
scan chains to the specified filenames:

356 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Scan Setup

add clocks 1 clk1

add clocks 0 clk0
set system mode dft
run
insert test logic
write atpg setup scan.testproc scan.do -replace
write netlist scan.v -verilog

Related Commands
Insert Test Logic Write Netlist
Read Procfile Write Procfile

LBISTArchitect Reference Manual, v2017.3 357

September 2017
BIST-Ready Command Dictionary
Write Static_timing Setup

Write Static_timing Setup

Scope: Dft mode
Usage
WRIte STatic_timing Setup {Functional | Test} filename [-Replace]
Definition
Writes a constraints file for use with static timing analysis tools.
Currently, the syntax for the driver file is targeted at PrimeTime®.
Arguments
• Functional
A literal that specifies to create a functional mode constraints file. The functional mode
driver will identify the MTPI phase signals and other test enable signals as constrained.
• Test
A literal that specifies to create a test mode constraints file. The test mode driver identifies
all the constrained primary inputs and the MTPI phase signals as constrained. It also
identifies all primary outputs as unsensitizable path destinations and all unconstrained
primary inputs as unsensitizable path sources.
• filename
A required string that specifies the name of the static timing analysis constraints file.
• -Replace
An optional switch that specifies to overwrite the contents of filename if a file by the same
name already exists.
Examples
The following example causes the BIST-Ready phase of LBISTArchitect to create a functional
mode static timing driver file named stime_pt:
write static_timing setup functional stime_pt -replace

The following is an example of an enhanced driver file:

read_file –f verilog core_mtpi.v
create_clock NX1 -period 6
constraints_as_being_generated_now
report_timing –slack_less 0.0 –max 2000000 –nosplit > func_sta.rep

358 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST-Ready Command Dictionary
Write Static_timing Setup

Related Commands
Archive Test_points Restore Test_points
Delete MTPI Control_point Delete MTPI Observe_point
Set Clock Period Load Static_timing Report

Command Summary

LBISTArchitect Reference Manual, v2017.3 359

September 2017
BIST-Ready Command Dictionary
Write Subchain Setup

Write Subchain Setup

Scope: Dft mode
Usage
WRIte SUbchain Setup filename -Replace
Description
Writes the appropriate Add Sub Chains commands to a file so that LBISTArchitect can
understand the preexisting scan sub-chains at the top-level of this module.
The Write Subchain Setup command is useful if you are performing a block-by-block test
synthesis at the lower design level. By using this command to specify for LBISTArchitect to
write the sub-chain setup information at the lower-level, and then reading in the setup file as
part of the scan sub-chain setup, you can avoid having to define the preexisting scan sub-chain
at the higher design level with the Add Sub Chains command.
Arguments
• filename
A required string that specifies the name of the file to which LBISTArchitect writes the scan
sub-chain setup information. For information on this file format, refer to the Insert Test
Logic command.
• -Replace
An optional switch that specifies for LBISTArchitect to replace the contents of the file, if
the file already exists.
Examples
The following example writes the scan chain setup information for this module, so that you can
later use the module1.setup file at the top-level to define the preexisting scan sub-chain:
insert test logic
write subchain setup /user/designs/module1.setup

The following example shows the contents of the module1.setup file:

add sub chains /user/designs/sub1 subc1 scan_in1 scan_out1 7
mux_scan scan_en

Related Commands
Add Test Points Report Test Logic
Insert Test Logic

360 LBISTArchitect Reference Manual, v2017.3

September 2017
 Chapter 3
BIST Controller Command Dictionary

This chapter contains command descriptions for the BIST Controller phase of LBISTArchitect.
The subsections are named for the command they describe. For quick reference, the commands
appear alphabetically, with each beginning on a separate page.

You invoke the BIST Controller phase of LBISTArchitect by using the lbistarchitect invocation
shell command with the -bist_controller switch as described in the Shell Commands chapter.

Command Line Syntax Conventions

This manual uses the following command usage line syntax conventions.

Table 3-1. Conventions for BIST Controller Command Line Syntax

Convention Example Usage
UPPercase REPort ENvironment Required command letters are in uppercase; in
(substitute product-specific most cases, you may omit lowercase letters when
examples throughout) 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 DELete TEstprocedure A boldface font indicates a required argument.
Include -File
[ ] EXIt [-Force] Square brackets enclose optional arguments. Do
not enter the brackets.
Italic DOFile filename An italic font indicates a user-supplied argument.
{ } ADD CEll Library library Braces enclose arguments to show grouping. Do
{{-Model name} | -All} not enter the braces.
| ADD CEll Library library The vertical bar indicates an either/or choice
{{-Model 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.

LBISTArchitect Reference Manual, v2017.3 361

September 2017
BIST Controller Command Dictionary
Command Summary

Table 3-1. Conventions for BIST Controller Command Line Syntax

Convention Example Usage
… ADD CLocks off_state An ellipsis follows an argument that may appear
primary_input_pin… more than once. Do not include the ellipsis when
[-Internal] entering commands.

Command Summary
Table 3-2 provides a quick reference for LBISTArchitect BIST Controller phase commands
described in this manual.
Table 3-2. Command Summary
Command Description
Add Capture Window Creates custom capture window waveforms for
testing designs with multiple clocks.
Add Cell Models Adds a generic or technology-specific clock/scan
enable buffer cell model.
Add Clock Domain Specifies that all listed clocks share the same
domain and, as a result, share the same clock
hardware logic of the co_clock_control module.
Add Clocks Specifies the names and inactive states of the core
design’s primary input pins to be considered for
multi-clock domain logic BIST.
Add LFSR Connections Connects a core logic pin to the specified LFSR.
Add LFSR Taps Adds the tap configuration to the specified LFSR.
Add LFSRs Specifies addition of a LFSR for use as either a
Pseudo-Random Pattern Generator (PRPG) or
Multiple Input Signature Register (MISR).
Add Pin Constraints Specifies input pins and the constant state at which
they are to be held during BIST mode.
Add Scan Pins Declares the name, ports, first and last cell clocks,
and length of a core scan chain that you want to use
as a STUMPS channel.
Add Set_reset Clocks Specifies the names and inactive states of the set
and reset clocks to be considered for set/reset tests.
Add Testprocedure Include Specifies to add an include statement to a
LBISTArchitect-generated test procedure.

362 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Command Summary

Table 3-2. Command Summary

Command Description
Add Tristate Controller An autogenerated command from the BIST-Ready
phase that defines the parameters of the tri-state
controller that the BIST Controller phase will add.
Connect Iscan Chains Connects internal scan chains to form single internal
scan chains.
Delete Capture Window Removes custom capture window waveforms that
you created with the Add Capture Window
command.
Delete Cell Models Removes cell models added with the Add Cell
Model command.
Delete Clocks Removes core design clock ports from the multi-
clock domain list.
Delete LFSR Connections Removes the specified connections between the
primary pins and the LFSR.
Delete LFSR Taps Removes the specified tap positions from a LFSR.
Delete LFSRs Removes one or more LFSR specifications.
Delete Pin Constraints Removes the pin constraints from the specified
primary input pins.
Delete Scan Pins Removes any previously-assigned scan-input and
scan-output pin names.
Delete Set_reset Clocks Removes core design set/reset clock ports.
Delete Testprocedure Include Specifies to delete an include statement from a
LBISTArchitect-generated test procedure.
Delete Tristate Controller Removes the specified tri-state controller(s) from
the internal list.
Disconnect Iscan Chains Disconnects top-level scan chains that you created
with the Connect Iscan Chains command.
Dofile Sequentially executes the commands residing in a
specified file.
Exit Terminates the application tool program.
Help Displays the syntax for the specified command.
History Displays a list of previously executed commands.
Read Procfile Reads the core-level test procedure file and
performs a syntax check.

LBISTArchitect Reference Manual, v2017.3 363

September 2017
BIST Controller Command Dictionary
Command Summary

Table 3-2. Command Summary

Command Description
Report Capture Window Displays a list of the custom capture window
waveforms that you currently have defined.
Report Cell Models Displays a list of currently defined cell models.
Report Clocks Displays a list of all multi-clock domain definitions.
Report Configuration_data Displays a list of the commands that the tools
Commands executes upon startup based on the available
metadata file for that design.
Report Environment Displays the current values of all the “set”
commands and the default names of the scan-type
pins.
Report LFSR Connections Displays a list of all the connections between
LFSRs and primary pins.
Report LFSRs Displays a list of definitions for all the current
LFSRs.
Report Pin Constraints Displays the pin constraints of the primary inputs.
Report Primary Inputs Displays the specified primary inputs.
Report Primary Outputs Displays the specified primary outputs.
Report Primitive Polynomials Lists the available polynomials for the length of
LFSR that you specify.
Report Procedure Displays all procedures or the specified procedure.
Report Scan Pins Displays all previously-assigned scan input and scan
output pin names.
Report Set_reset Clocks Displays a list of all set/reset pins.
Report Testprocedure Include Displays a list of the include statements added to
LBISTArchitect-generated test procedures using the
Add Testprocedure Include command.
Report Tristate Controller Displays a list of all tri-state controllers.
Reset State Resets tool setup back to the initial state at
invocation.
Run Causes LBISTArchitect to generate BIST logic.
Save BIST Saves the BIST output files.
Save History Saves the command-line history file to the specified
file.
Save Sequential Patterns Saves the specified number of sequential patterns to
the specified file.

364 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Command Summary

Table 3-2. Command Summary

Command Description
Set Bist Clock Specifies the name of the master clock.
Set BIST Enables Specifies the names of the enable signals controlling
control points, x-bounding multiplexers, and
observe sink points.
Set Capture Waveform Defines the waveform that the tool applies to the
core when the named capture window is active.
Set Clock Buffer Generates a generic or technology-specific buffer
for clocks and scan enables.
Set Clock Loading Assigns a loading factor to the clock specified by
the clock_name argument.
Set Clock Period Specifies the period (or frequency) and duty cycle of
a defined clock or control signal, or to remove all
clock timing that you have previously defined with
the Set Clock Period command.
Set Core Netlist Specifies the BIST-Ready output core netlist name
and its language.
Set Dofile Abort Lets you specify whether the tool aborts or
continues dofile execution if an error condition is
detected.
Set Dynamic X_bounding Specifies that the tool should drive the enable signal
that controls dynamic x-bounding of memory
elements that capture values from multicycle paths.
Set Iscan Interface Defines the internal scan interface parameters.
Set Lbist Controller Defines parameters for the logic BIST controller.
Set Logfile Handling Specifies for LBISTArchitect to direct the transcript
information to a file.
Set Output Format Sets the language of the RTL and test bench files.
Set Retiming Logic Provides a mechanism for specifying the use of
lockup latches or flip-flops for re-timing logic
within your design.
Set RTL Hierarchy Specifies where to place the MCD clock
multiplexer.
Set RTL Prefix Adds a unique prefix to the beginning of the name
of all created LBIST modules.
Set Scan_enable Switching Sets the default value for slow scan enable
switching.

LBISTArchitect Reference Manual, v2017.3 365

September 2017
BIST Controller Command Dictionary
Command Summary

Table 3-2. Command Summary

Command Description
Set Scan Enables Specifies the names and polarities of scan enable
signals.
Set Shift_rate Divisor Defines the rate to drive the scan chains in relation
to the bist_clk signal.
Set Testpoint Parameters Defines parameters for controlling test points using
the multiphase test point process.
Setup File Naming Explicitly defines the filenames for one or more
saved output files.
Setup Pin Constraints Sets the default pin constraint value for all input
pins.
Setup Scan Pins Globally sets up parameters for any added scan pins.
Setup Sdc Template Enables the writing of static timing analysis files in
a format compatible with the Synopsys PrimeTime
tool.
Setup Synthesis Script Sets the naming for the Design Compiler synthesis
script.
System Passes the specified command to the operating
system for execution.

366 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Command Descriptions

Command Descriptions
The remaining pages in this chapter describe, in alphabetical order, the commands used in
LBISTArchitect. Each command description begins on a new page and contains a line
indicating the supported applications.

You can use the line continuation character, “\\’, when application commands extend beyond
the end of a line. The line continuation character improves the readability of dofiles and helps
with the command line entry of multiple-argument commands.

LBISTArchitect Reference Manual, v2017.3 367

September 2017
BIST Controller Command Dictionary
Add Capture Window

Add Capture Window

Usage
ADD CApture Window capture_window_name pattern_start_value pattern_stop_value
Description
Creates custom capture window waveforms for testing designs with multiple clocks.
Each capture window defines a unique set of clock waveforms that the tool will apply during the
capture window of a subset of the Logic BIST patterns.
When testing designs with multiple clocks, you need to differentiate between two types of logic
paths. Intra-clock domain paths are logic paths that are driven by and, captured into flip-flops
that are all driven by the same clock. Inter-clock logic paths start with flip-flops driven by one
clock and are captured into flip-flops driven by a different clock. Typically, it is necessary for
you to use several capture windows to properly test all the transitions.
The tool selects capture windows by decoding the low order bits in the pattern counter, which
means the complete set of capture windows that you create must define a continuous range that
begins with 0, and end at a value that is one less than power of two.
Once you have created a capture window with the Add Capture Window command, you can
specify the shape of each clock waveform using the Set Capture Waveform command.
Arguments
• capture_window_name
A required string that specifies the name of the custom capture window that you are
creating.
• pattern_start_value
A required integer that specifies the first pattern number of the capture window.
• pattern_stop_value
A required integer that specifies the last pattern number of the capture window.
Related Commands
Delete Capture Window Set Capture Waveform
Report Capture Window Set Lbist Controller

Command Summary

368 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Cell Models

Add Cell Models

Usage
ADD CEll Models {cell_name {-Type buffer} {-Input input_name}
{-Output output_name} {-Library library_name}} |
{generic {-Type buffer} {-Input input_name} {-Output output_name}}
Description
Adds a generic or technology-specific clock/scan enable buffer cell model.
The Add Cell Models command provides a way to specify the buffers for use with clocks and
scan enables. The required cell_name argument specifies the name of the cell in the technology
library. You can specify a technology-independent cell by using generic as the cell_name
argument. If you specify generic, LBISTArchitect uses CLKBUF as the clock buffer entity
name. Cells added with this command normally serve as arguments for the Set Clock Buffer
command.
Arguments
• cell_name | generic
A required string or literal that you use to specify either a technology-specific cell or a
generic cell. The cell_name argument specifies the name of the cell in a technology library.
You specify a technology-independent cell by supplying generic as the argument.
• -Type buffer
A required switch and literal pair that specifies the type of the cell to add. For the present,
the only cell type available is a buffer cell.
• -Input input_name
A required switch and string pair that specifies the name of the cell’s input pin. Currently,
there can only be single input.
• -Output output_name
A required switch and string pair that specifies the name of the cell’s output pin. Currently,
there can only be single output.
• -Library library_name
A required switch and string pair (for technology-specific cells) that specifies the
technology library. If you supply this pair for a generic buffer, the tool ignores it.
Examples
The following example specifies a generic buffer with input A and output Y:
add cell models generic -type buffer -input A -output Y

This example adds the technology-specific cell (CTS55) from the technology library, TCS5000:
add cell models cts55 -type buffer -input A -output Y -library tsc5000

LBISTArchitect Reference Manual, v2017.3 369

September 2017
BIST Controller Command Dictionary
Add Cell Models

Related Commands
Delete Cell Models Report Cell Models
Set Clock Buffer

Command Summary

370 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Clock Domain

Add Clock Domain

Usage
ADD CLock Domain domain_name clk_name...
Description
Specifies the clocks that belong to the same clock domain; that is, clocks that are pulsed
simultaneously in each Named Capture Procedure (NCP).
As a result of sharing the same domain, the clocks share the same clock hardware logic of the
co_clock_control module.
When clocks are pulsed at the same time, as defined by the user in capture windows, duplicated
logic is created in the logic cone of the clock muxes in the LBIST Controller. You use this
command to specify that all clocks in a defined domain share the same clock hardware. This
eliminates the duplication of clock hardware logic.
Arguments
• domain_name
A required string that identifies a clock domain. All of the clocks listed in the clk_name
argument are considered to share the clock domain named by this argument.
• clk_name
A required repeatable string that lists the clock names belonging to the same clock domain.
Examples
The following example defines two clock domains. The first domain definition specifies that
CLK1 and CLK2 will share the same clock hardware logic of the co_clock_control module. The
second domain definition specifies that CLK3, CLK4, CLK5, and CLK6 will share clock
hardware logic.
add clock 1 clk1 clk2
add clock 0 clk3 clk4 clk5 clk6

add clock domain domain1 clk1 clk2

add clock domain domain2 clk3 clk4 clk5 clk6

add capture window wave1 0 254

add capture window wave2 255 255

set capture waveform wave1 domain1 pulse "010"

set capture waveform wave1 domain2 pulse "000"

set capture waveform wave2 domain1 pulse "000"

set capture waveform wave2 domain2 pulse "010"
run

LBISTArchitect Reference Manual, v2017.3 371

September 2017
BIST Controller Command Dictionary
Add Clock Domain

Related Commands
Add Clocks Report Clocks
Add Set_reset Clocks Set Capture Waveform
Delete Clocks

Command Summary

372 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Clocks

Add Clocks
Usage
ADD CLocks off_state primary_input_pins… [-Internal]
Description
Specifies the names and inactive states of the core design’s primary input pins to be considered
for multi-clock domain logic BIST.
If your core design uses a multiple clock domain, you must declare all clock ports and their
corresponding off-states with the Add Clocks command.
If you issue multiple Add Clock commands for a particular clock without an intervening Delete
Clocks command, LBISTArchitect displays a warning.
You can issue multiple Add Clock commands for different clocks, however their off states must
be the same.
If you add multiple clocks using the Add Clocks command, then you must also specify the
master clock using the Set Bist Clock command.
Arguments
• off_state
A required literal that specifies the pin value that cannot affect the output pin activity of the
instance. For example, the off-state of an active low reset pin is 1 (high). For an edge-
triggered control signal, the off–state is the value on the pin that results in the clock inputs
being placed at the initial value of a capturing transition.
The off-state choices are as follows:
0 — A literal specifying that the off-state value is 0.
1 — A literal specifying that the off-state value is 1.
• primary_input_pins
A required repeatable string that lists the core design’s clock ports that you want to be
considered for multi-clock domain logic BIST. The list of clock ports must exist in the core
design and all have the same off_state.
• -Internal
An optional switch that specifies the primary_input_pin is an internal pin for ATPG
purposes. See “Using On-Chip PLL Clocks for BIST Capture” in the LBISTArchitect
Process Guide for complete information.
The tool processes this internal pin as a clock primary input. Use this switch to define
internal clock inputs normally driven by on-chip circuitry, such as from PLL output.
When using this switch, then the primary_input_pin must be an internal pin and not an
actual clock primary input pin. When you save patterns, the tool omits this internal clock
input at the top level interface.

LBISTArchitect Reference Manual, v2017.3 373

September 2017
BIST Controller Command Dictionary
Add Clocks

Examples
The following example adds the primary input pins /clk_input and /sys_clk for a multi-clock
domain logic BIST with a shared off_state of zero:
add clocks 0 /clk_input /sys_clk
report clocks
off-state = 0
clk_input capture_string = 1111111100000000
sys_clk capture_string = 0000000011111111

Related Commands
Add Set_reset Clocks Report Clocks
Delete Clocks

Command Summary

374 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add LFSR Connections

Add LFSR Connections

Usage
ADD LFsr Connections primary_pin lfsr_name position…
Description
Connects a core logic pin to the specified LFSR.
The Add LFSR Connections command performs several functions, depending on whether the
specified LFSR is a PRPG or MISR.
PRPG Connections
If you are making connections for a PRPG, then this command performs the following
functions:
• specifies a connection between the PRPG and a scan input pin
• specifies the bits of the PRPG you want to XOR together to create a pseudorandom
pattern for the specified scan chain
Figure 3-1shows how you create different pseudorandom patterns for each scan chain by
XORing certain bits of the PRPG and shifting this “new” pseudorandom pattern through the
chain.

Figure 3-1. PRPG Connections

Commands Generated Circuitry

prpg1
add lfsrs prpg1 prpg 4 10 -in
add lfsr taps prpg1 3
add lfsr connections sci_1 prpg1 0 2 2 1
3 0

Core Design sci_1

MISR Connections
If you are specifying connections for a MISR, this command performs the following functions:
• specifies a connection between a scan output pin and the MISR
• specifies to which bit of the MISR you want to connect the scan output

LBISTArchitect Reference Manual, v2017.3 375

September 2017
BIST Controller Command Dictionary
Add LFSR Connections

After connecting a MISR, LBISTArchitect creates an XOR network responsible for merging
multiple scan outputs into a single bit in the MISR when the number of scan outputs exceeds the
number of bits in the MISR.

Figure 3-2. MISR Connections

Commands
add lfsrs misr1 misr 4 0 -in
Core
Design add lfsr taps misr1 1 3
add lfsr connections sco_1 misr1 3
sco_1 sco_2 add lfsr connections sco_2 misr1 2
misr1

3 2 1 0

Generated Circuitry

Arguments
• primary_pin
A required string that specifies the name of the boundary scan or core logic scan pin that you
want to connect to the LFSR specified by lfsr_name. If the LFSR functions as a PRPG, you
must connect it to a scan input pin. Similarly, if the LFSR functions as a MISR, you must
connect it to a scan output pin. In either case, if you do not want to specify the scan input or
scan output pin name for a boundary scan chain, you can specify the string “dummy”. When
it makes connections, LBISTArchitect selects a boundary scan pin not already connected to
the LFSR to serve as the “dummy”.
• lfsr_name
A required string that specifies the name of the LFSR to which you want to connect the
primary_pin.
• position
A required integer that specifies the bit position(s) of the lfsr_name at which to place
connections. For PRPGs, you can specify multiple positions. For MISRs, you can specify
only one position. A bit position is an integer number, where 0 indicates the least significant
bit position.

376 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add LFSR Connections

Examples
The following example connects a PRPG to a scan-in pin and a MISR to a scan-out pin:
add lfsrs lfsr1 prpg 5 10 -in
add lfsrs misr1 misr 5 15 -out
add lfsr taps lfsr1 2 4
add lfsr taps misr1 1
add lfsr connections scan_in1 lfsr1 2 3
add lfsr connections scan_out1 misr1 3

Figure 3-3. Example Connections

lfsr1

4 3 2 1 0

Core Design scan_in1

scan_out1

misr1

4 3 2 1 0

Related Commands
Add LFSR Taps Report LFSR Connections
Add LFSRs Report Primitive Polynomials
Delete LFSR Connections

Command Summary

LBISTArchitect Reference Manual, v2017.3 377

September 2017
BIST Controller Command Dictionary
Add LFSR Taps

Add LFSR Taps

Usage
ADD LFsr Taps lfsr_name position…
Description
Adds the tap configuration to the specified LFSR.
The Add LFSR Taps command sets the tap configuration of a particular LFSR. You can either
manually place the tap points for your LFSRs or you can allow LBISTArchitect to
automatically place them for you.
To manually add the LFSR tap points, you want to strategically place the PRPG or MISR tap
points to produce the maximum set of non-repeating patterns. You do this by using one of the
primitive polynomials associated with the length of your LFSR. You can list three of these
polynomials by using the Report Primitive Polynomial command.
Once you have the primitive polynomial, you determine the tap points from the primitive
polynomial depending on the tap type. For a Type 1 or “out” tap type, you remove the highest
and lowest terms from the polynomial and use the exponents of the remaining terms as the tap
points. For example, for an 8-bit LFSR the primitive polynomial is x8+x4+x3+x2+1. You
remove both x8 and 1 from the polynomial so you are left with x4+x3+x2. You then place the tap
points at the bits corresponding to the exponents: 4, 3, and 2.

For a Type 2 or “in” tap type, subtract the Type 1 or “out” tap points from the LFSR’s length.
For example, for the same 8-bit LFSR you determined the tap positions 4, 3, and 2 for the Type
1 tap type. Thus, for Type 2 or “in” tap types, you get 4, 5, and 6 (8 - 4, 8 - 3, and 8 - 2) as the
tap positions.
You specify the tap type, either in or out, using the Add Lfsrs command. The tap positions you
specify depend on the which tap type you chose.

Figure 3-4. Five-bit PRPG with Tap Points

Tapping Points
(bits 4 and 2)

4 3 2 1 0
5-bit PRPG

378 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add LFSR Taps

You can use the Report LFSRs command to display all the LFSRs with their current values and
tap positions.
Arguments
• lfsr_name
A required string that specifies the name of the LFSR for which you want to specify the
taps.
• position
A required repeatable integer that specifies the bit positions of the lfsr_name at which you
want to place the taps. LFSR bit positions have integer numbers, where 0 indicates the least
significant bit position. LBISTArchitect assumes the output of the 0-bit position connects to
the selected tap points and that the 0-bit position cannot itself be a tap point.
Examples
The following example places taps on added LFSRs:
add lfsrs lfsr1 prpg 5 10 -in
add lfsrs misr1 misr 5 15 -out
add lfsr taps lfsr1 1 3
add lfsr taps misr1 1 2

Related Commands
Add LFSRs Report LFSRs
Delete LFSR Taps Report Primitive Polynomials

Command Summary

LBISTArchitect Reference Manual, v2017.3 379

September 2017
BIST Controller Command Dictionary
Add LFSRs

Add LFSRs
Usage
ADD LFsrs lfsr_name {Prpg | Misr} length seed [-Out | -In]
Description
Adds a Linear Feedback Shift Register (LFSR) for use as either a Pseudo-Random Pattern
Generator (PRPG), to create pseudo-random patterns, or a Multiple Input Signature Register
(MISR), to compact responses from the circuit.
If you do not specify a PRPG or MISR, LBISTArchitect automatically provides them for you.
By default, LBISTArchitect creates both the PRPG and MISR as type “in”.
The size of the PRPG is calculated based on the minimum PRPG size (16 bits) and the total
number of scan chains in the design. For designs with more than 200 scan chains, the formula is:
PRPG size = S + 2 + (((N-200)/100) * 2)

Where, S = the minimum PRPG size (16 bits)

N = the total number of scan chains

As an example, for a design composed of 2000 scan chains, LBISTArchitect sets the size of the
PRPG to 54 bits as calculated below:

PRPG size = 16 + 2 + (((2000-200)/100) * 2)

= 54 bits
Note
For designs with fewer than 200 scan chains, a slight variation on this formula may occur
based on the number of patterns and scan chains.

The maximum size of a MISR is 64 bits. For designs with fewer than 64 scan chains,
LBISTArchitect creates a MISR whose size is equal to the number of scan chains. For designs
with 64 or more scan chains, it creates a 64 bit MISR.

As an example, for a design composed of 2000 scan chains, the MISR size is 64 bits.

The automatic default seed value is all 1s for both the PRPG and the MISR.
Arguments
• lfsr_name
A required string that specifies the LFSR name.
• Prpg
A literal indicating that the LFSR functions as a PRPG.
• Misr
A literal indicating that the LFSR functions as a MISR.

380 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add LFSRs

• length
A required integer, greater than 1, specifying the number of bits in the LFSR.
• seed
A required, right-justified, hexadecimal number that specifies the initial state of the LFSR.
PRPGs must have a seed value other than 0. When the IEEE 1149.1 instruction RUNBIST
initiates the BIST process, the controller loads the specified seed values into the PRPG and
MISR. To experiment with different seed values, place the boundary scan circuitry in the
Shift-DR state and load the new seed value through TDI into the PRPG and MISR.
• -Out
An optional switch that specifies that the exclusive-OR taps reside outside the register path.
An Out tap type corresponds to the industry term “Type 1”. Figure 3-5 shows an example of
an Out type tap configuration, which has two tap positions—at bit 1 and bit 3 of a four-stage
LFSR.

Figure 3-5. Out Tap Type

3 2 1 0

• -In
An optional switch that specifies that the exclusive-OR taps reside in the register path. An In
tap type corresponds to the industry term “Type 2”. In type tap points have the advantage of
incurring less gate delay as well as having less dependency (more randomness) between
bits. Figure 3-6 shows an example of an In type tap configuration that has two tap
positions—at bits 3 and 1 of a four-stage LFSR. By default, LBISTArchitect creates both
the PRPG and MISR as type “in”.

Figure 3-6. In Tap Type

3 2 1 0

Examples
The following example defines both a PRPG and a MISR, and sets the tap positions for both:

LBISTArchitect Reference Manual, v2017.3 381

September 2017
BIST Controller Command Dictionary
Add LFSRs

add lfsrs lfsr1 prpg 5 10 -in

add lfsrs misr1 misr 5 15 -out
add lfsr taps lfsr1 1 3
add lfsr taps misr1 1 2

Related Commands
Add LFSR Connections Report LFSRs
Add LFSR Taps Report Primitive Polynomials
Delete LFSRs

Command Summary

382 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Pin Constraints

Add Pin Constraints

Usage
ADD PIn Constraints primary_input_pins… {C0 | C1 | CZ | CX}
[-SImulate {ATPG | BIST | ALL}]
Description
Specifies input pins and the constant state at which they are to be held during BIST mode.
When creating the BIST controller, the Add Pin Constraints command allows you to constrain
specific input pins to a constant value. The specified pins are constrained during the mode you
specify in order to avoid the inputs being tied to X, propagating to the MISR, and thus
corrupting the signature.
You can set a default pin constraint value for all input pins using the Setup Pin Constraints
command. The pin constraints set by the Setup Pin Constraints command can be overridden by
the values set with the Add Pin Constraints command. You can remove an override of a default
pin constraint using the Delete Pin Constraints command. To remove the default pin constraint
for all input pins, you should use the Setup Pin Constraints command with the None literal.
Arguments
• primary_input_pins
A repeatable required string that specifies the primary input pin that you want held at the
constant_value during the mode you specify.
• C0 | C1 | CZ | CX
A literal that specifies the application of the constant value with which you want to constrain
the primary_input_pins. The constraint choices are as follows:
C0 — A literal that specifies application of the constant 0 to the chosen primary input
pins.
C1 — A literal that specifies application of the constant 1 to the chosen primary input
pins.
CZ — A literal that specifies application of the constant Z (high-impedance) to the
chosen primary input pins.
CX — A literal that specifies application of the constant X (unknown) to the chosen
primary input pins.
• -SImulate {ATPG | BIST | ALL}
Specifies for LBISTArchitect to constrain the pins through the test environment (such as the
test bench and test vectors). These signals must be driven with the appropriate values any
time a logic BIST test is active. This may cause problem for board/system test applications.
The ALL literal is the default when you specify (or by default use) the -Simulate switch.
The ATPG literal specifies for the tool to constrain the pins during ATPG topup pattern
generation (but not during BIST), the BIST literal specifies for the tool to constrain the pins

LBISTArchitect Reference Manual, v2017.3 383

September 2017
BIST Controller Command Dictionary
Add Pin Constraints

during BIST simulation (but not during ATPG), and the ALL literal specifies for the tool to
constrain the pins during both ATPG and BIST.
Examples
The following example illustrates how to hold two primary input pins to constant values:
add pin constraints kgmt c1
add pin constraints dsint c0

Related Commands
Delete Pin Constraints Setup Pin Constraints
Report Pin Constraints

Command Summary

384 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Pll End_capture

Add Pll End_capture

Usage
ADD PLl End_capture primary_output_pin
Description
Specifies the name of the core design’s primary output pin, which indicates to the BIST
controller a capture window is ended. See “Using On-Chip PLL Clocks for BIST Capture” in
the LBISTArchitect User’s Manual for complete information.
This is an active high input. You can only define one End_capture signal.
If you issue multiple Add Pll End_capture commands for a particular signal without a
corresponding Delete Pll End_capture command, LBISTArchitect displays a warning. If you
specify more than one End_capture signals, then LBISTArchitect displays an error.
Arguments
• primary_output_pin
A required string that specifies the core design’s PLL End_capture signal.
Related Commands
Add Clocks Report Pll End_capture
Delete Pll End_capture

Command Summary

LBISTArchitect Reference Manual, v2017.3 385

September 2017
BIST Controller Command Dictionary
Add Pll Triggers

Add Pll Triggers

Usage
ADD PLl Triggers off_state primary_input_pins…
Description
Specifies the names and inactive states of the core design’s primary input pins for consideration
as on-chip PLL-driven logic BIST. See “Using On-Chip PLL Clocks for BIST Capture” in the
LBISTArchitect Process Guide for complete information.
You use the Add Pll Triggers command to specify PLL triggers to generate the specified
triggering sequences in similar fashion as clocks.
If the core design has multiple triggering signals, then you must declare all signals and their
corresponding off-states using the Add Pll Triggers command. If you issue multiple Add Pll
Triggers commands for a particular triggering signal without an intervening Delete Pll Triggers
command, then LBISTArchitect displays a warning.
You can use multiple Add Pll Triggers commands for different trigger signals, however the
signals’ off states must be the same.
Arguments
• off_state
A required literal that specifies the pin value that cannot affect the output pin activity of the
instance. For example, the off-state of an active high GO PLL trigger signal is 0 (low).
Choose one of the following for off_state:
0 — A literal specifying that the off-state value is 0.
1 — A literal specifying that the off-state value is 1.
• primary_input_pins
A required repeatable string that lists the core design’s PLL trigger signals. The list of
trigger signals must exist in the core design and all have the same off_state.
Related Commands
Add Pll Triggers Report Pll Triggers
Delete Pll Triggers

386 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Scan Pins

Add Scan Pins

Usage
ADD SCan Pins chain_name scan_input_pin scan_output_pin
-First_cell polarity first_cell_clock -Last_cell polarity last_cell_clock -Length integer
Description
Declares the name, ports, first and last cell clocks, and length of a core scan chain that you want
to use as a STUMPS channel.
The Add Scan Pins command provides LBISTArchitect with information about an internal scan
chain in the core design and its associated scan-in and scan-out ports. LBISTArchitect checks to
see if the specified scan ports exist. If they do not, the tool generates an error. LBISTArchitect
keeps track of the port information and provides it to the fault simulation phase in the form of
commands within dofiles, which it creates when you use the Save BIST command.
LBISTArchitect uses the first and last cell information to determine whether it should insert
lockup or re-timing latches between the scan chain and the BIST controller logic to prevent
skew-induced race conditions.
The Setup Scan Pins command provides user control over global naming for newly-added scan
pins.
Arguments
• chain_name
A required string that specifies the name of the scan chain associated with the
scan_input_pin and scan_output_pin names.
• scan_input_pin
A required string that specifies the scan input pin name of the scan chain.
• scan_output_pin
A required string that specifies the scan output pin name of the scan chain.
• -First_cell polarity first_cell_clock
A required switch, literal, and string triplet that specifies the clock driving the first cell of
the scan chain and its polarity. LBISTArchitect adds lockup latches, as necessary, between
the PRPG and scan inputs. The tool also adds necessary latches while concatenating the
scan chains. The first_cell_clock argument specifies the name of the clock driving the first
scan cell on the chain (the cell connected to the scan in port). The literal, polarity, can be
one of two values:
Posedge — Specifies that first_cell_clock controls a positive-edge-triggered scan cell.
Negedge —Specifies that first_cell_clock controls a negative-edge-triggered scan cell.

LBISTArchitect Reference Manual, v2017.3 387

September 2017
BIST Controller Command Dictionary
Add Scan Pins

• -Last_cell polarity last_cell_clock

A required switch, literal, and string triplet that specifies the clock driving the last cell of the
scan chain. LBISTArchitect adds lockup latches, as necessary, between the scan outputs and
the MISR. The tool also adds necessary latches while concatenating the scan chains. The
last_cell_clock argument specifies the name of the clock driving the last scan cell on the
chain (the cell connected to the scan out port). The literal, polarity, can be one of two
values:
Posedge — Specifies that last_cell_clock controls a positive-edge-triggered scan cell.
Negedge —Specifies that last_cell_clock controls a negative-edge-triggered scan cell.
• -Length integer
A required switch and integer pair that specifies the length of the scan chain, chain_name.
LBISTArchitect uses this information when writing out the test bench file for a logic BIST
controller that requires external initialization of the scan chains. The length of each
individual chain is used to determine the length of the longest scan chain after scan chain
concatenation.
Examples
The following example defines four scan chains for a design containing two clocks, clk1 and
clk2.
add scan pins chain1 sin1 sout1 -first_cell posedge clk1 -last_cell posedge
clk1
add scan pins chain2 sin2 sout2 -first_cell negedge clk2 -last_cell posedge
clk1
add scan pins chain3 sin3 sout3 -first_cell negedge clk2 -last_cell posedge
clk1
add scan pins chain4 sin4 sout4 -first_cell negedge clk2 -last_cell negedge
clk2
connect iscan chains sin1 sout1 sin2 sout2
connect iscan chains sin4 sout4 sin3 sout3

Assuming the BIST controller is clocked by clk1 and uses the default (edge-based) lockup latch
insertion algorithm, LBISTArchitect inserts lockup latches in the following locations, where
scan data crosses clock domain boundaries:
• Between the PRPG and sin1, sin2, sin3, and sin4, because there may be skew between
the bist_clock and the gated version of the bist_clock that drives the core.
• Between sout1, sout2, and sout3 and the MISR.
• Between sout4 and sin3 while concatenating the scan chains.
Related Commands
Delete Scan Pins Setup Scan Pins
Report Scan Pins Set Lbist Controller

Command Summary

388 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Set_reset Clocks

Add Set_reset Clocks

Usage
ADD SEt_reset Clocks off_state primary_input_pin…
Description
Specifies the names and inactive states of the set and reset clocks to be considered for set/reset
tests.
The Add Set_reset Clocks command enables you to define set/reset pins, along with their off-
state, that need to be considered for set/reset test. The core design must have the specified
set/reset pins; otherwise, the tool issues an error stating that the pin is not present on the core
design.
Set/Reset tests are conducted as follows:
1. Test for Faults on Scan Cell Resets — For a small number of patterns, LBISTArchitect
loads the scan chains with pseudorandom patterns and, instead of capturing using the
system clocks, captures using the scan cell’s reset clock. If there are multiple reset ports
on the core design, each reset will require its own test.
2. Test for Faults on Scan Cell Sets — For a small number of patterns, LBISTArchitect
loads the scan chains with pseudorandom patterns and, instead of capturing using the
system clocks, captures using the scan cell’s set clock. If there are multiple set ports on
the core design, each set will require its own test.
LBISTArchitect treats these sets and resets as clocks. You can control the number of patterns
for which set/reset test is performed by using the Set Capture Waveform command.

Arguments
• off_state
A required literal that specifies the pin value that cannot affect the output pin activity of the
instance. For example, the off-state of an active low reset pin is 1 (high). For an edge-
triggered control signal, the off–state is the value on the pin that results in the clock inputs
being placed at the initial value of a capturing transition.
The off-state choices are as follows:
0 — A literal specifying that the off-state value is 0.
1 — A literal specifying that the off-state value is 1.
• primary_input_pins
A required repeatable string that lists the core design’s set and reset clock ports that you
want to be considered for set/reset tests. The list of clock ports must exist in the core design
and all have the same off_state.

LBISTArchitect Reference Manual, v2017.3 389

September 2017
BIST Controller Command Dictionary
Add Set_reset Clocks

Examples
The following example defines clk as a clock with zero off-state, set1 with 0 off-state, and
reset1 with 1 off-state. The final command sets LBISTArchitect to perform 1024 patters, of
which the first 16 patterns are dedicated for flush test.
add clocks 0 clk
add set_reset clocks 0 set1
add set_reset clocks 1 reset1
set lbist controller -patterns 1024 -flush_test 16

Related Commands
Delete Set_reset Clocks Set Lbist Controller
Report Set_reset Clocks
Command Summary

390 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Testprocedure Include

Add Testprocedure Include

Usage
ADD TEstprocedure Include [-Destination type] -Procedure procedure [name] -File files
Description
Specifies to add an include statement to a LBISTArchitect-generated test procedure.
The Add Testprocedure Include command enables you to include setup sequences into the
generated test procedure file. This capability is useful if you need to initialize a design into the
needed LBIST test mode for a correct LBIST operation.
Arguments
• -Destination type
An optional switch and string pair that specifies the type of procedure into which the include
statement is to be added. Type can be stuck-at or transition. The default is stuck-at.
• -Procedure procedure [name]
A required switch and string pair, with an optional literal, that specifies the name of the
procedure where the include statement is to be placed. The optional name argument
specifies to place the include statement in the specified named capture procedure.
• -File files...
A required switch and string pair that specifies the name of the file(s) to be included.
Example 1
The following example adds initialization commands to the test_setup procedure by including
the circuit_init.testproc file in the test_setup procedure in the non-transition test procedure file.
add testprocedure include -procedure test_setup -file circuit_init.testproc

This command produces the results shown in bold:

procedure test_setup =
timeplate tp_gen1;
#include “circuit_init.testproc”
cycle =
...
end;
end;

Example 2
The following example adds the capture.testproc file to the beginning of the named capture
procedure cap1.
add testprocedure include -procedure capture cap1 -file capture.testproc

This command produces the results shown in bold:

Procedure capture cap1 =

LBISTArchitect Reference Manual, v2017.3 391

September 2017
BIST Controller Command Dictionary
Add Testprocedure Include

timeplate tp_gen1;
#include “capture.testproc”
cycle =
...
end;
end;

Related Topics
Delete Testprocedure Include Report Testprocedure Include

392 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Add Tristate Controller

Add Tristate Controller

Prerequisite: There must be tri-state nets in the core and, during the BIST-Ready phase, you
must have defined a mux model with the Add Cell Models command, specified the One_hot
option with the Set Test Logic command, and issued a Write BIST Setup command, to
produce the dofile containing instances of this command.
The Add Tristate Controller command is autogenerated by the BIST-Ready phase and is not
intended for interactive use; it is documented for reference purposes only.
Usage
ADD TRistate Controller -Width integer -Prefix prefix_name
Description
An autogenerated command from the BIST-Ready phase that defines the parameters of the tri-
state controller that the BIST Controller phase will add.
BIST-Ready issues a separate Add Tristate Controller command for each net that is driven by a
tri-state.
Arguments
• -Width integer
A required switch and integer pair that specifies the number of control lines the tri-state
controller will contain.
• -Prefix prefix_name
A required switch and string pair that specifies the prefix name used with the control signals
of this particular tri-state controller.
Related Commands
Delete Tristate Controller Report Tristate Controller

Command Summary

LBISTArchitect Reference Manual, v2017.3 393

September 2017
BIST Controller Command Dictionary
Connect Iscan Chains

Connect Iscan Chains

Prerequisite: You must first define the scan chains using the Add Scan Pins command.
Usage
CONnect IScan Chains {{in_port_name out_port_name}…} | {chain_name…} |
-Single_core_chain
Description
Connects internal scan chains to form single internal scan chains.
The Connect Iscan Chains command connects multiple internal scan chains at the BIST
controller level to form a single scan chain at the top level for interfacing to ATPG topup
patterns. This reduces the number of scan pins and chains required for topup testing at the top
level (by default, all internal scan chains connect at the top level), while allowing you to keep
the size of the internal scan chains small to reduce BIST test application time. You can issue the
command multiple times to formulate as many top-level scan chains as needed.
The in_port_name and out_port_name pair represent each internal scan chain that you want to
interconnect. For each in_port_name out_port_name pair you provide, the command connects
the leading pair’s out_port_name to the next pair’s in_port_name. Figure 3-7 shows the
connections resulting from the following commands:
connect iscan chains in_port1 out_port1 in_port2 out_port2 in_port3 out_port3
connect iscan chains in_port4 out_port4 in_port5 out_port5

The first in_port_name pin and the last out_port_name pin are made available at the top level,
renamed—by default—as top_scan_inX and top_scan_outX. You can change the default name
that follows top_ by using the Setup Scan Pins command. The command also assigns a unique
name to each newly formed scan chain and echos the name to the transcript window so that you
can use it with the Disconnect Iscan Chains command.
Alternatively, you can use the names of the chains that you want LBISTArchitect to connect
together. The previous set of commands then become:
connect iscan chains scan_chain_1 scan_chain_2 scan_chain_3
connect iscan chains scan_chain_4 scan_chain_5

If LBISTArchitect encounters a chain name as the first argument, it treats all subsequent
arguments as chain names.

394 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Connect Iscan Chains

Figure 3-7. Interconnecting Internal Scan Chains

top_chain1 BISTed Core

top_scan_in1 scan_chain_1 out_port1
in_port1

scan_chain_2
in_port2 out_port2

in_port3 scan_chain_3 top_scan_out1

out_port3

top_chain2
scan_chain_4
top_scan_in2 in_port4 out_port4

scan_chain_5
in_port5 out_port5 top_scan_out2

Core

Figure 3-8. Interconnecting into a Single Chain

BISTed Core
top_scan_in1 in_port1 scan_chain_1
0 out_port1
1
top_single_in
in_port2 scan_chain_2
out_port2
select_single_
chain
scan_chain_3
in_port3 out_port3 top_scan_out1

in_port4 scan_chain_4
1 out_port4
top_scan_in2
0

scan_chain_5 top_scan_out2
in_port5 out_port5

Core top_single_out

This command also supports a second level of scan chain concatenation inside the BIST
controller, using the -Single_core_chain switch. This mode combines all the core scan chains
(including previously-created top-level scan chains) into a single, unnamed chain with ports
top_single_in and top_single_out, without deleting any existing top-level connections.
However, only one mode at a time can be active. You select the single core chain mode by
forcing a “1” on the BIST controller port, select_single_chain. When this mode is inactive, you
can once again access the top-level scan chain ports. Figure 3-8 shows the result of issuing the
following command:

LBISTArchitect Reference Manual, v2017.3 395

September 2017
BIST Controller Command Dictionary
Connect Iscan Chains

connect iscan chains -single_core_chain

LBISTArchitect connects the chains into a single chain in the same order in which you defined
them using the Add Scan Pins command.
There is no order dependency when issuing these commands. You can issue a command
creating the single core chain before, during, or after creating individual top-level scan chains.
A special case occurs when the core level scan pins are part of a bused input or output signal and
you connect the corresponding internal scan chains with the following commands:
CONnect IScan Chains sci(1) sco(1) sci(0) sco(0) sci(2) sco(2)
CONnect IScan Chains sci(3) sco(3) sci(4) sco(4

Figure 3-9 shows that LBISTArchitect resizes the bused input or output accordingly, causing
the top-level to core-level interconnections to no longer match.

Figure 3-9. Interconnecting Internal Bused Scan Chains

sci(0) sco(0)
sci(0) sci(1) sco(1)
sci(2) sco(2) sco(0)
sci(1) sci(3) sco(3)
sci(4) sco(4) sco(1)

core-level scan-in pins core-level scan-out pins

top-level scan-in pins top-level scan-out pins

Arguments
You can choose only one of the following arguments for each instance of this command.
• in_port_name out_port_name
A repeatable string pair which defines the input and output port of an internal scan chain
(in_port_name and out_port_name must belong to the same scan chain). The arguments
must match the port names used in the core logic. You must specify the port names in pairs,
for example, in_port_name_3 out_port_name_3.
• chain_name
A repeatable string that specifies the chain names of the chains you want connected into a
single top-level scan chain. If the first argument to the command is a chain name,
LBISTArchitect treats all further arguments as chain names.
• -Single_core_chain
A switch that specifies to connect all the core and top-level scan chains into a single top-
level chain with the ports, top_single_in and top_single_out.

396 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Connect Iscan Chains

Examples
To form a single internal scan chain from three chains, whose port names are paired as “IN1”,
“OUT1”, “IN2”, “OUT2”, and “IN3”, “OUT3”, enter the following command:
connect iscan chains in1 out1 in2 out2 in3 out3
// New chain has been named ‘top_chain1’

The result is a new internal scan chain named “top_chain1” with an input port name
“top_scan_in1” and an output port name “top_scan_out1”.
Related Commands
Disconnect Iscan Chains Setup Scan Pins
Add Scan Pins

Command Summary

LBISTArchitect Reference Manual, v2017.3 397

September 2017
BIST Controller Command Dictionary
Delete Capture Window

Delete Capture Window

Usage
Delete CApture Window capture_window_name | -All
Description
Removes custom capture window waveforms that you created with the Add Capture Window
command.
Allows you to selectively delete any custom capture window or delete all existing custom
capture windows.
Arguments
• capture_window_name
A string that specifies the name of the custom capture window that you are deleting.
• -All
A switch that deletes all existing custom capture windows.
Related Commands
Add Capture Window Set Capture Waveform
Report Capture Window Set Lbist Controller

Command Summary

398 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Delete Cell Models

Delete Cell Models

Prerequisites: You must add the cell model with the Add Cell Model command before you can
delete it.
Usage
DELete CEll Models cell_name… | -All
Description
Removes cell models added with the Add Cell Model command.
Allows you to selectively delete any number of existing cell models or delete all existing cell
models.
Arguments
• cell_name
A repeatable string that specifies the list of cell models you want to delete.
• -All
A switch that deletes all existing cell models.
Examples
The following example deletes a technology-specific cell model.
add cell models generic -type buffer -input A -output Y
add cell models cts55 -type buffer -input A -output Y -library tsc5000
delete cell models cts55
report cell models
generic, Input A, Output Y

Related Commands
Add Cell Models
Report Cell Models

Command Summary

LBISTArchitect Reference Manual, v2017.3 399

September 2017
BIST Controller Command Dictionary
Delete Clocks

Delete Clocks
Prerequisites: You must add a clock port to the multi-clock domain list before you can delete it.
Usage
DELete CLocks primary_input_pin [-Internal]... | -All
Description
Removes core design clock ports from the multi-clock domain list.
The Delete Clocks command removes the specified clock ports from the multi-clock domain
list.
Arguments
• primary_input_pins
A repeatable string that specifies the list of clock ports in the core design that you want to
delete from the multi-clock domain list.
• -Internal
An optional argument that deletes the internal clocks added with the Add Clocks ... -Internal
command. If you omit this arguement, then the tool only deletes the PI clocks.
• -All
A switch that deletes all ports from the multi-clock domain list.
Examples
The following example illustrates that to change the multi-domain clock off-state, you must first
delete the previous definition:
add clocks 1 /clk_input /sys_clk
add clocks 0 /clk_input /sys_clk
ERROR: /clk_input and sys_clk are already defined as clocks
delete clocks /clk_input /sys_clk
add clocks 0 /clk_input /sys_clk
report clocks
off-state = 0
clk_input capture_string = 1111111100000000
sys_clk capture_string = 0000000011111111

Related Commands
Add Clocks Report Clocks

Command Summary

400 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Delete LFSR Connections

Delete LFSR Connections

Prerequisites: You must define LFSR connections with the Add LFSR Connections command
before you can delete them.
Usage
DELete LFsr Connections lfsr_name {primary_pin… | -All}
Description
Removes the specified connections between the primary pins and the LFSR.
The Delete LFSR Connections command deletes the connections between the LFSR and the
primary pins that you specified with the Add LFSR Connections command. You can use the
Report LFSR Connections command to display all the current connections between LFSRs and
primary pins.
Arguments
• lfsr_name
A required string that specifies the LFSR whose primary pin connections you want to delete.
• primary_pin
A repeatable string that lists the primary pins whose connections to lfsr_name you want to
delete.
• -All
A switch that deletes all of the connections between lfsr_name and primary pins.
Examples
The following example changes the definition of a LFSR connection by deleting its connection
to scan input scan_in.1 and re-connecting it to scan_in.2.
add lfsrs lfsr1 prpg 5 15 -in
add lfsr taps lfsr1 2 3 4
add lfsr connections scan_in.1 lfsr1 2
delete lfsr connections lfsr1 scan_in.1
add lfsr connections scan_in.2 lfsr1 2

Related Commands
Add LFSR Connections Report LFSR Connections

Command Summary

LBISTArchitect Reference Manual, v2017.3 401

September 2017
BIST Controller Command Dictionary
Delete LFSR Taps

Delete LFSR Taps

Prerequisites: You must specify LFSR taps with the Add LFSR Taps command before you can
delete them.
Usage
DELete LFsr Taps lfsr_name {tap_position… | -All}
Description
Removes the specified tap positions from a LFSR.
The Delete LFSR Taps command deletes the specified LFSR tap positions that you added with
the Add LFSR Taps command. You can display the current tap positions of all defined LFSRs
by using the Report LFSRs command.
Arguments
• lfsr_name
A required string that specifies the LFSR whose tap positions you want to delete.
• tap_position
A repeatable string that specifies the list of tap positions that you want to delete from the
lfsr_name.
• -All
A switch that deletes all of the tap positions from the lfsr_name.
Examples
The following example changes a LFSR tap position from bit 3 to 1:
add lfsrs lfsr1 prpg 5 15 -in
add lfsr taps lfsr1 2 3 4
delete lfsr taps lfsr1 3
add lfsr taps lfsr1 1

Related Commands
Add LFSR Taps Report LFSRs

Command Summary

402 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Delete LFSRs

Delete LFSRs
Prerequisites: You must define LFSRs with the Add LFSRs command before you can delete
them.
Usage
DELete LFsrs lfsr_name… | -All
Description
Removes one or more LFSR specifications.
The Delete LFSRs command deletes LFSR definitions you added with the Add LFSRs
command. You can use the Report LFSRs command to display a list of the current LFSRs with
their current values and tap positions. When you delete a LFSR, the tool also deletes all its
associated taps and pin connections.
Arguments
• lfsr_name
A repeatable string that specifies the reference names of the LFSRs that you want to
remove.
• -All
A switch that deletes all defined LFSRs.
Examples
The following example changes the definition of a LFSR by deleting it and then re-adding it
with a new definition:
add lfsrs lfsr1 prpg 5 15 -in
add lfsrs lfsr2 prpg 5 13 -in
add lfsrs lfsr3 prpg 5 11 -out
delete lfsrs lfsr3
add lfsrs lfsr3 prpg 5 11 -in

Related Commands
Add LFSRs Report LFSRs

Command Summary

LBISTArchitect Reference Manual, v2017.3 403

September 2017
BIST Controller Command Dictionary
Delete Pin Constraints

Delete Pin Constraints

Usage
DELete PIn Constraints primary_input_pins… | -All
Description
Removes the pin constraints from the specified primary input pins.
The Delete Pin Constraints command deletes pin constraints that were previously added to the
primary inputs with the Add Pin Constraints command. You can delete the pin constraints for
specific pins or for all pins.
You can set a default pin constraint for all input and bidirectional pins using the Setup Pin
Constraints command. The pin constraints set by the Setup Pin Constraints command can have
their values overridden with the Add Pin Constraints command. You can remove an override of
a default pin constraint using the Delete Pin Constraints command. To remove the default pin
constraint for all input pins, you should use the Setup Pin Constraints command with the None
literal.
Arguments
• primary_input_pins
A repeatable string that specifies a list of primary input pins whose pin constraints you want
to delete.
• -All
A switch that specifies to delete the pin constraints of all primary input pins.
Examples
The following example adds two pin constraints and then deletes one of them:
add pin constraints ph1 c0
add pin constraints ph2 c0
delete pin constraints ph1

Related Commands
Add Pin Constraints Setup Pin Constraints
Report Pin Constraints

Command Summary

404 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Delete Pll End_capture

Delete Pll End_capture

Prerequisites: You must have added a PLL End_capture signal using the Add Pll End_capture
command.
Usage
DELete PLl End_capture
Description
Removes the core design PLL End_capture signal. If there is no End_capture signal, then
LBISTArchitect issues a warning. See “Using On-Chip PLL Clocks for BIST Capture” in the
LBISTArchitect Process Guide for complete information.
Related Commands
Add Pll End_capture Report Pll End_capture

LBISTArchitect Reference Manual, v2017.3 405

September 2017
BIST Controller Command Dictionary
Delete Pll Triggers

Delete Pll Triggers

Prerequisites: You must have added a PLL trigger signal using the Add Pll Triggers command.
Usage
DELete PLI Tiggers primary_input_pins… | -All
Description
Removes all core design PLL trigger signals or the specified PLL trigger signals.
See “Using On-Chip PLL Clocks for BIST Capture” in the LBISTArchitect Process Guide for
complete information.
Arguments
• primary_input_pins
A repeatable string that specifies a list of PLL trigger signals in the core design for deletion.
• -All
A switch that deletes all PLL trigger signals.
Related Commands
Add Pll Triggers Report Pll Triggers

406 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Delete Scan Pins

Delete Scan Pins

Usage
DELete SCan Pins chain_name… | -All
Description
Removes any previously-assigned scan-input and scan-output pin names.
The Delete Scan Pins command removes user-specified names of the scan-input and scan-
output pins of the scan chains that you previously assigned with the Add Scan Pins command.
You can use the Report Scan Pins command to display all added scan input and output pin
names for each scan chain.
Arguments
• chain_name
A repeatable string that specifies the names of the scan chains from which you want
LBISTArchitect to remove the associated pin names.
• -All
A switch that removes all added scan pin names from all scan chains.
Examples
The following example removes previously assigned scan chain input and output names for
chain1:
add scan pins chain1 si so
add scan pins chain2 si1 so1
delete scan pins chain1

Related Commands
Add Scan Pins Report Scan Pins

Command Summary

LBISTArchitect Reference Manual, v2017.3 407

September 2017
BIST Controller Command Dictionary
Delete Set_reset Clocks

Delete Set_reset Clocks

Prerequisites: You must add a set/reset clock port before you can delete it.
Usage
DELete SEt_reset Clocks primary_input_pins… | -All
Description
Removes core design set/reset clock ports.
The Delete Set_reset Clocks command removes the specified clock ports.
Arguments
• primary_input_pins
A repeatable string that specifies the list of set/reset clock ports in the core design that you
want to delete.
• -All
A switch that deletes all set/reset clock ports.
Examples
The following example illustrates that to change the set clock off-state, you must first delete the
previous definition:
add set_reset clocks 0 set1
add set_reset clocks 1 set1
ERROR: set1 is already defined as a clock
delete set_reset clocks set1
add set_reset clocks 1 set1

Related Commands
Add Set_reset Clocks Report Set_reset Clocks

Command Summary

408 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Delete Testprocedure Include

Delete Testprocedure Include

Usage
DELete TEstprocedure Include -File files
Description
Specifies to delete an include statement from a LBISTArchitect-generated test procedure.
Arguments
• -File files...
A required switch and string pair that specifies the name of the file(s) whose include
statement is to be removed.
Example
The following example removes the include statement for the circuit_init.testproc file from the
test procedure file.
delete testprocedure -file circuit_init.testproc

Given the following file contents:

procedure test_setup =
timeplate tp_gen1;
#include “circuit_init.testproc”
cycle =
...
end;
end;

This command produces the following results:

procedure test_setup =
timeplate tp_gen1;
cycle =
...
end;
end;

Related Topics
Add Testprocedure Include Report Testprocedure Include

LBISTArchitect Reference Manual, v2017.3 409

September 2017
BIST Controller Command Dictionary
Delete Tristate Controller

Delete Tristate Controller

This command is not intended for interactive use; it is documented for reference purposes only.
Usage
DELete TRistate Controller prefix_name | -All
Description
Removes the specified tri-state controller(s) from the internal list.
Arguments
• prefix_name
A switch that specifies to remove the tri-state controller identified by the prefix_name.
• -All
A switch that specifies to remove all tri-state controllers added with the Add Tristate
Controller command.
Related Commands
Add Tristate Controller Report Tristate Controller

Command Summary

410 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Disconnect Iscan Chains

Disconnect Iscan Chains

Prerequisites: You must connect internal scan chains to form a single internal scan chain, using
the Connect Iscan Chains command, before you can disconnect them.
Usage
DISconnect IScan Chains {top_level_chain_name…} | -All | -Single_core_chain
Description
Disconnects top-level scan chains that you created with the Connect Iscan Chains command.
The Disconnect Iscan Chains command disconnects any unwanted top-level LBISTArchitect-
created scan chains that you created from multiple internal core scan chains. The names of the
LBISTArchitect scan chains were echoed to the transcript window at the time they were created
with the Connect Iscan Chains command.
Arguments
• top_level_chain_name
A repeatable string that specifies the top-level scan chains that you want to disconnect.
• -All
A switch that specifies to disconnect all top-level scan chains created with the Connect Iscan
Chains command (including the chain created with -Single_core_chain).
• -Single_core_chain
A switch that specifies to disconnect only the top-level chain created with the
-Single_core_chain argument to the Connect Iscan Chains command.
Examples
To form three top-level LBISTArchitect scan chains and later delete two of them, enter the
following commands:
connect iscan chains in1 out1 in2 out2 in3 out3
// New chain has been named ‘top_chain1’
connect iscan chains in4 out4 in5 out5 in6 out6
// New chain has been named ‘top_chain2’
connect iscan chains in7 out7 in8 out8
// New chain has been named ‘top_chain3’
…
disconnect iscan chains top_chain1 top_chain3

The result is five original internal scan chains (1, 2, 3, 7, and 8) and one top level scan chain,
top_chain2. However, LBISTArchitect renames the remaining top level chain ports as
“top_scan_in1” and “top_scan_out1”.

LBISTArchitect Reference Manual, v2017.3 411

September 2017
BIST Controller Command Dictionary
Disconnect Iscan Chains

Related Commands
Connect Iscan Chains

Command Summary

412 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Dofile

Dofile
Prerequisites: The existence of a properly formatted file that contains legal LBISTArchitect
commands.
Usage
DOFile filename
Description
Sequentially executes the commands residing in a specified file.
The Dofile command sequentially executes the LBISTArchitect commands contained 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. 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

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.
You can specify a dofile at invocation by using the -Dofile switch with the lbistarchitect
invocation command.
Arguments
• filename
A required string specifying the name of the file containing the LBISTArchitect 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 hard pathname.
Examples
To cause LBISTArchitect to use an external file named BISTA_setup.do (located in the current
working directory) as the source for a series of commands, enter the following command:
dofile BISTA_setup.do

Related Commands
Set Dofile Abort

Command Summary

LBISTArchitect Reference Manual, v2017.3 413

September 2017
BIST Controller Command Dictionary
Exit

Exit
Usage
EXIt [-Force]
Description
Terminates the application tool program.
The Exit command 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 appears and you must specify whether to continue the session and save the
output, or exit without saving.
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

Or, to exit with a previously saved output, just enter:

exit

Related Commands
Command Summary

414 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Help

Help
Usage
HELp [command_name] [-MANual]
Description
Displays the syntax for the specified command.
The Help command 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 consists of any keyword or BIST Controller phase command. You
can use minimum typing for the command name.
• -MANual
An optional string that specifies to also display the reference manual description for the
specified command.
If you type HELp and include only the -MANual switch, the tool opens the product
bookcase, giving access to all the manuals for that product group.
Examples
For example, issue the following command at the command-line prompt:

LBIST> help add

This generates the following information on “add” commands.

ADD BSr Ports ADD CLocks

ADD LFsr Connections ADD LFsr Taps
ADD LFsrs ADD OUtput Masks
ADD PIn Constraints ADD SCan Pins
To generate usage information on a particular command, enter the entire command name:

LBIST> help add scan pins

This generates the following information:

Usage: ADD SCan Pins <chain name> <scan_input> <scan_output>

Related Commands
Command Summary

LBISTArchitect Reference Manual, v2017.3 415

September 2017
BIST Controller Command Dictionary
History

History
Usage
HIStory [list_count] [-Nonumbers] [-Reverse]
Description
Displays a list of previously executed commands.
The History 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.
Each command line in the history list is preceded by a leading number indicating 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.

416 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller 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 run
4 history

Related Commands
Save History

Command Summary

LBISTArchitect Reference Manual, v2017.3 417

September 2017
BIST Controller Command Dictionary
Read Procfile

Read Procfile
Usage
REAd PRocfile proc_filename [-Append | -Replace]
Description
Reads the core-level test procedure file and performs a syntax check.
The file specified by proc_filename must contain timeplates and one named capture procedure
(NCP) for each Add Capture Window command. If the procedure file is incorrect,
LBISTArchitect issues an error.
You must adhere to the following usage guidelines:
• Issue the Read Procfile command after all Add Capture Window commands.
• Use the same name for the capture window in both the dofile and test procedure file.
• Include one named capture procedure for each capture window.
• If the design has a PLL, add an external and internal mode for every named capture
procedure (see “Example 2”).
External mode — Defines the signals the BIST controller drives into the core to trigger
the capture window.
Internal mode — Defines the actual clock waveforms that appear in the device.
• Execute the Read Procfile command after the Set Clock Period command.
In each NCP, the period of a timeplate must be an integer multiple of the period of
bist_clock which is the fastest clock specified by Set Clock Period. If a clock has no
period specified, the default period is 50ns.
• Start each timeplate with the following two statements placed prior to the first clock
pulse transition:
force_pi 0;
measure_po 1;

To ensure the beginning of the clock pulse starts at a value greater than 0, force_pi must
occur at 0 and measure_po must occur at 1; the cycle period is no less than 3 units.
• All clock rising edge events must occur at 2 + (bist_clk*n), where n is an integer starting
from 0 (n= 0, 1, 2…).
If you are using “force” instead of “pulse” to make a clock transition, the clock rising
edge event can occur at (bist_clk*n), where n is an integer starting from 0 (n= 0, 1, 2…).
• All clock falling edge events must be at 2 + (bist_clk*n/2), where n is an integer starting
from 1 (n= 1, 2, 3…).

418 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Read Procfile

• If you are using “force” instead of “pulse” to make a clock transition, the clock falling
edge event can occur at (bist_clk*n/2), where n is an integer starting from 1 (n= 1, 2,
3…).
• With one exception, all clock periods in the timeplate must occur at an integer multiple
of the bist_clk period: clock_period = bist_clk*n (n= 1, 2, 3…). The timeplate used by
the first leading clock edge transition of a NCP may have a period of 2+bist_clk*n. (n=
1, 2, 3…).
• The timescale is always set to ns.
• All signals referred to in the “cycle=” blocks of NCPs must be clocks defined using Add
Clock or PLL trigger signals.
• The “cycle=” blocks may only contain the following statements:
force clock <off_state>
pulse clock
See “Using On-Chip PLL Clocks for BIST Capture” in the LBISTArchitect Process Guide for
complete information.
Arguments
• proc_filename
A required path and filename of the test procedure file to be read.
For the BIST controller phase, the test procedure file must contain timeplates and one
named capture procedure for each Add Capture Window command.
• -Append
An optional switch that reads the information specified in proc_filename and does the
following:
• Adds any new NCPs in proc_filename to the tool’s existing database of NCPs.
New NCPs are those whose name is not identical to that of an NCP in the existing
database. An added NCP is available immediately for use.
• Updates the timing (timeplate) of existing NCPs and other procedures as applicable,
without altering them in any other way.
• -Replace
An optional switch that deletes all existing NCPs in the tool’s internal database and replaces
them with the NCPs present in proc_filename provided that none of those existing NCPs are
used by a pattern in the current internal or external pattern set. If one or more of the existing
NCPs is used by a pattern, none of them are deleted or replaced. If proc_filename does not
contain any NCPs, the existing NCPs are deleted and not replaced. This is the default.

LBISTArchitect Reference Manual, v2017.3 419

September 2017
BIST Controller Command Dictionary
Read Procfile

Note
An NCP in proc_filename and its counterpart of the same name in the tool’s internal
database must have the same event sequence. If their event sequences differ, the
command is aborted.

Example 1
In the following example, the test procedure file specified by proc_filename is read:
read procfile my_file.proc

Example 2
In the following example, the three Add Capture Window commands in the dofile dictate that
three named capture procedures with the same name be included in the test procedure file.
Additionally, if a PLL is used the test procedure file must contain an external and internal mode
for each of the named capture procedures as shown.
add capture window cap1 0 9
add capture window cap2 10 14
add capture window cap3 15 15

If no PLL is used, the test procedure file must contain the following:
procedure capture cap1 =

......

end

procedure capture cap2 =

......

end

procedure capture cap3 =

......

end

If PLL is used, the test procedure file must contain the following:
procedure capture cap1 =
mode internal =
......
end

mode external =
......
end
end

420 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Read Procfile

procedure capture cap2 =

mode internal =
......
end

mode external =
......
end
end

procedure capture cap3 =

mode internal =
......
end

mode external =
......
end
end

Note
Note that the capture window name used in the dofile must be consistent with the name
used in the procedure file. Such as cap1, cap2, cap3 in this example.

Example 3
In the following example, a capture window is defined that creates two pulses of a clock
operating at bist_clock frequency (pulse mode), given a bist_clock frequency of 50ns:
set time scale 1.0 ns;
timeplate tp_gen1=
force_pi 0;
measure_po 1;
pulse clk1 2 25;
period 50;
end;

procedure capture cap1 =

timeplate tp_gen1;
cycle=
force_pi;
measure_po;
pulse clk1;
end;

cycle=
pulse clk1;
end;

end;

LBISTArchitect Reference Manual, v2017.3 421

September 2017
BIST Controller Command Dictionary
Read Procfile

The contents of this example test procedure file are equivalent to executing the following
command:
set capture waveform cap1 clk1 PULSE 11

Example 4
In the following example, a capture window is defined that creates two pulses of a clock
operating at 1/2 bist_clock frequency (hold mode), given a bist_clock frequency of 50ns:
set time scale 1.0 ns;
timeplate tp_gen1=
force_pi 0;
measure_po 1;
pulse clk1 52 50;
period 102;
end;

timeplate tp_gen2=
force_pi 0;
measure_po 1;
pulse clk1 50 50;
period 100;
end;

procedure capture cap1 =

cycle=
timeplate tp_gen1;
force_pi;
pulse clk1;
end;

cycle=
timeplate tp_gen2;
measure_po;
pulse clk1;
end;
end;

The contents of this example test procedure file are equivalent to executing the following
command:
set capture waveform cap1 clk1 HOLD 0101

Example 5
In the following example, a capture window is defined that creates two pulses of a clock
operating at 1/2 bist_clock frequency (hold mode), given a bist clock frequency of 50ns:
set time scale 1.0 ns;
timeplate tp_gen1=
force_pi 0;
measure_po 1;
pulse clk1 52 50;
period 152;
end;

timeplate tp_gen2=

422 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Read Procfile

force_pi 0;
measure_po 1;
pulse clk1 0 50;
period 100;
end;

procedure capture cap1 =

cycle=
timeplate tp_gen1;
force_pi;
pulse clk1;
end;

cycle=
timeplate tp_gen2;
pulse clk1;
end;
end;

The contents of this example test procedure file are equivalent to executing the following
command:
set capture waveform cap1 clk1 HOLD 01010

Example 6
In the following example, a capture window is defined that creates two pulses of a clock
operating at 1/3 bist_clock frequency (stretch mode), given a bist clock frequency of 50ns:
set time scale 1.0 ns;
timeplate tp_gen1=
force_pi 0;
measure_po 1;
pulse clk1 2 75;
period 150;
end;

procedure capture cap1 =

timeplate tp_gen1;
cycle=
force_pi;
measure_po;
pulse clk1;
end;

cycle=
pulse clk1;
end;

end;

The contents of this example test procedure file are equivalent to executing the following
command:
set capture waveform cap1 clk1 STRETCH 100100

LBISTArchitect Reference Manual, v2017.3 423

September 2017
BIST Controller Command Dictionary
Read Procfile

Example 7
In the following example, another stretch mode waveform is generated as follows:

set time scale 1.0 ns;

timeplate tp_gen1=
force_pi 0;
measure_po 1;
pulse clk1 52 75;
period 150;
end;

procedure capture cap1 =

timeplate tp_gen1;
cycle=
force_pi;
measure_po;
pulse clk1;
end;

cycle=
pulse clk1;
end;

end;

The contents of this example test procedure file are equivalent to executing the following
command:
set capture waveform cap1 clk1 STRETCH 010010

Example 8
In the following example, a capture window is defined that creates one pulse of a clock
operating at 1/3 bist_clock frequency (stretch mode), followed by a pulse of a clock running at
bist_clock frequency. The frequency of the bist_clock is 50ns:
set time scale 1.0 ns;
timeplate tp_gen1=
force_pi 0;
measure_po 1;
pulse clk1 2 75; // slow clock
pulse clk2 102 25; // fast clock
period 150;
end;

procedure capture cap1=

timeplate tp_gen1;
cycle=
force_pi;// Note that we do not use measure_po here on purpose.
pulse clk1;
pulse clk2";
end;
end;

424 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Read Procfile

The contents of this example test procedure file are equivalent to executing the following
command:
set capture waveform cap1 clk1 STRETCH 100
set capture waveform cap1 clk2 PULSE 001

Example 9
In the following example, the same waveforms are generated as in Example 8 by creating two
different timeplates: one at 50 ns and one at 100ns:
set time scale 1.0 ns;
timeplate tp_gen1=
force_pi 0;
measure_po 1;
pulse clk2 2 25; // fast clock
period 50;
end;

timeplate tp_gen2=
force_pi 0;
measure_po 1;
pulse clk1 2 75; // slow clock
period 100;
end;

procedure capture cap1 =

cycle=
timeplate tp_gen2;
force_pi;
pulse clk1;
end;

cycle=
timeplate tp_gen1;
measure_po;
pulse clk2;
end;
end;

The contents of this example test procedure file are equivalent to executing the following
command:
set capture waveform cap1 clk1 STRETCH 100
set capture waveform cap1 clk2 PULSE 001

Related Commands
Add Pll End_capture Delete Pll Triggers
Add Pll Triggers Report Procedure
Delete Pll End_capture Set Capture Waveform

LBISTArchitect Reference Manual, v2017.3 425

September 2017
BIST Controller Command Dictionary
Report Capture Window

Report Capture Window

Usage
REPort CApture Window
Description
Displays a list of the custom capture window waveforms that you currently have defined.
The Report Capture Window command displays the existing custom capture windows that you
defined with the Add Capture Window command. This command is useful for setting up the Set
Capture Waveform command.
Related Commands
Add Capture Window Set Capture Waveform
Delete Capture Window Set Lbist Controller

Command Summary

426 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Cell Models

Report Cell Models

Usage
REPort CEll Models
Description
Displays a list of currently defined cell models.
The Report Cell Models command displays the existing cell models defined with the Add Cell
Models command. This command is useful for setting up the Set Clock Buffer command.
Examples
The following example uses Report Cell Models to set up a Set Clock Buffer command.
add cell models generic -type buffer -input A -output Y
add cell models cts55 -type buffer -input A -output Y -library tsc5000
.
.
report cell models
generic, Input A, Output Y
cts55, Input A, Output Y, Library tsc5000
set clock buffer master_clock generic clk1 cts55 clk2 generic

Related Commands
Add Cell Models Delete Cell Models
Set Clock Buffer

Command Summary

LBISTArchitect Reference Manual, v2017.3 427

September 2017
BIST Controller Command Dictionary
Report Clocks

Report Clocks
Usage
REPort CLocks [-Internal]
Description
Displays a list of all multi-clock domain definitions.
The Report Clocks command displays a list of all clocks added with the Add Clocks command.
Argument
• -Internal
An optional argument that reports the internal clocks added with the Add Clocks ... -Internal
command. If you omit this arguement, then the tool only reports the PI clocks.
Examples
The following example displays a list of clocks after they have been added to the clock list:
add clocks 0 /clk_input /sys_clk
report clocks
off-state = 0
clk_input capture_string = 1111111100000000
sys_clk capture_string = 0000000011111111

Related Commands
Add Clocks Delete Clocks

Command Summary

428 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Configuration_data Commands

Report Configuration_data Commands

Usage
REPort COnfiguration_data Commands
Description
Displays a list of the commands that the tools executes upon startup based on the available
metadata file for that design.
LBISTArchitect uses binary configuration data files (metadata) to pass the necessary
information between the different invocation phases of the tool. The Bist-Ready and Bist-
Controller Generation phases both read a metadata file at invocation and execute the commands
associated with that file. This report lists the commands associated with that metadata file.
Example
The following example displays a brief sampling of commands that you might see in on of these
report commands.
report configuration_data commands
add clocks 0 NX2
set clock period NX2 0
add set_reset clocks 0 RST

LBISTArchitect Reference Manual, v2017.3 429

September 2017
BIST Controller Command Dictionary
Report Environment

Report Environment
Usage
REPort ENvironment [{> | >>} file_pathname]
Description
Displays the current values of all the “set” commands and the default names of the scan-type
pins.
When you first invoke LBISTArchitect, executing the Report Environment command shows all
of the default values of the “set” commands. By default, the output of the command is written to
the transcript window of the tool.
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example shows the LBISTArchitect invocation default settings:
report environment
LBIST Environment Report:
------------------------
LBIST controller defaults:
Core name: fha
No. Patterns: 10000
PRPG length: 32
MISR length: 32
Test Point Parameters: method = simulation
IScan Interface:
Number STUMPS Channels: 24
STUMPS Channel length: 512
Clock name: clock
Sen name: scan_en
Scan cells: 1000
Output SCAN pin default settings:
<Name form: Indexed> <Prefix: scan_out> <Initial: 1> <Modifier: 1>
<Suffix: >
Input SCAN pin default settings:
<Name form: Indexed> <Prefix: scan_in> <Initial: 1> <Modifier: 1>
<Suffix: >
Filenames set are:
BIST model: fha_bist.vhd
Fault simulation dofile: fha_faultsim.do
Core level fault simulation dofile: fha_core_faultsim.do

430 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Environment

BSDA dofile: fha_bsda.do

Stand-alone mode test bench file: fha_tb.vhd
Stand-alone mode test procedure file: fha_bist.testproc
Core level test procedure file: fha_bist.ctestproc
Topup ATPG test procedure file: fha_topup.testproc
Topup ATPG dofile: fha_topup_atpg.do
Topup ATPG fault file: fha_topup_atpg_faults
Message Handling: OFF.

Related Commands
Any of the “Set” commands.
Command Summary

LBISTArchitect Reference Manual, v2017.3 431

September 2017
BIST Controller Command Dictionary
Report LFSR Connections

Report LFSR Connections

Usage
REPort LFsr Connections
Description
Displays a list of all the connections between LFSRs and primary pins.
The Report LFSR Connections command displays all of the connections between the LFSRs
and the primary pins that you specified with the Add LFSR Connections commands.
Examples
The following example displays the connections between the LFSRs and primary pins:
add lfsrs lfsr1 prpg 5 15 -in
add lfsrs lfsr2 misr 5 11 -in
add lfsr taps lfsr1 1 3
add lfsr taps lfsr2 2 3
add lfsr connections scan_in1 lfsr1 3
add lfsr connections scan_out1 lfsr2 2
report lfsr connections

List of LFSR connections

LFSR = lfsr1
pin = scan_in1 connection_points = 3
LFSR = lfsr2
pin = scan_out1 connection_points = 2

Related Commands
Add LFSR Connections Delete LFSR Connections

Command Summary

432 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report LFSRs

Report LFSRs
Scope: All modes
Usage
REPort LFsrs
Description
Displays a list of definitions for all the current Linear Feedback Shift Registers (LFSRs).
The Report LFSRs command displays all of the LFSRs with their current values and tap
positions, which you specified using the Add LFSRs and Add LFSR Taps commands.
Examples
The following example displays the definitions of all the current LFSRs:

add lfsrs lfsr1 prpg 5 15 -in

add lfsrs lfsr2 prpg 5 13 -in
add lfsr taps lfsr1 1 3
add lfsr taps lfsr2 2 3
add lfsrs misr1 misr 5 11 -in
report lfsrs
List of LFSRs
Name Type Length Tap_type Seed
lfsr2 PRPG 5 -In 13
Taps at positions: 2,3
misr1 MISR 5 -In 11
No Tap positions Specified

Related Commands
Add LFSRs Set LFSR Seed
Add LFSR Taps Setup LFSRs
Delete LFSRs

LBISTArchitect Reference Manual, v2017.3 433

September 2017
BIST Controller Command Dictionary
Report Pin Constraints

Report Pin Constraints

Usage
REPort PIn Constraints [-All | primary_input_pins…]
Description
Displays the pin constraints of the primary inputs.
The Report Pin Constraints command displays the pin constraints that you previously added to
the primary inputs with the Add Pin Constraints command. You can change the constant value
constraints of the primary inputs by using the Add Pin Constraints or Setup Pin Constraints
commands.
Arguments
• -All
An optional switch that specifies to display the current constraints for all primary input pins.
This is the default.
• primary_input_pins
An optional repeatable string that specifies a list of primary input pins whose constraints
you want to display.
Examples
The following example displays the cycle behavior constraints of all primary inputs.
add pin constraints ph1 c0
add pin constraints ph2 c1
report pin constraints -all

Related Commands
Add Pin Constraints Setup Pin Constraints
Delete Pin Constraints

Command Summary

434 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Pll End_capture

Report Pll End_capture

Usage
REPort PLl End_capture
Description
Displays the PLL End_capture signal you have added with the Add Pll End_capture command.
See “Using On-Chip PLL Clocks for BIST Capture” in the LBISTArchitect Process Guide for
complete information.
Related Commands
Add Pll End_capture Delete Pll End_capture

LBISTArchitect Reference Manual, v2017.3 435

September 2017
BIST Controller Command Dictionary
Report Pll Triggers

Report Pll Triggers

Usage
REPort PLl Triggers
Description
Displays a list of all PLL trigger signals you have added with the Add Pll Triggers command.
See “Using On-Chip PLL Clocks for BIST Capture” in the LBISTArchitect Process Guide for
complete information.
Related Commands
Add Pll Triggers Delete Pll Triggers

436 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Primary Inputs

Report Primary Inputs

Scope: All modes
Usage
REPort PRimary Inputs [-All | primary_input_pin…]
Description
Displays the specified primary inputs.
The Report Primary Inputs command displays a list of either all the primary inputs of a circuit
or a specific list of primary inputs that you specify.
Arguments
• -All
An optional switch that specifies to display all the primary inputs. This is the default.
• primary_input_pin
An optional repeatable string that specifies a list of primary input pins that you want to
display.
Examples
The following example displays all of the primary inputs:
report primary inputs -all
SYSTEM: /clk
SYSTEM: /datain
Note
The label “system” means that these are primary inputs that LBISTArchitect
automatically recognizes because they were in the netlist. Because there is no Add
Primary Input command in LBISTArchitect, all primary inputs are of the system-defined
class.

Related Commands
Report Primary Outputs

LBISTArchitect Reference Manual, v2017.3 437

September 2017
BIST Controller Command Dictionary
Report Primary Outputs

Report Primary Outputs

Scope: All modes
Usage
REPort PRimary Outputs [-All | primary_output_pin…]
Description
Displays the specified primary outputs.
The Report Primary Outputs command displays a list of either all the primary outputs of a
circuit or a specific list of primary outputs that you specify.
Arguments
• -All
An optional switch that specifies to display all the primary outputs. This is the default.
• primary_output_pin
An optional repeatable string that specifies a list of primary output pins that you want to
display.
Examples
The following example displays all of the primary outputs:
report primary outputs -all
SYSTEM: /dataout
SYSTEM: /dataout1
Note
The label “system” means that these are primary outputs that LBISTArchitect
automatically recognizes because they were in the netlist. Because there is no Add
Primary Output command in LBISTArchitect, all primary outputs are of the system-
defined class.

Related Commands
Report Primary Inputs

438 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Primitive Polynomials

Report Primitive Polynomials

Usage
REPort PRimitive Polynomials lfsr_length
Description
Lists the available polynomials for the length of LFSR that you specify.
The Report Primitive Polynomials command lists the optimum polynomials for a LFSR of order
(length) up to 512.
You can either use one of the reported polynomials to manually determine the tap points for
your LFSR or you can allow LBISTArchitect to automatically use the polynomial with the least
number of terms for both your PRPG and MISR. If the length calculated by LBISTArchitect or
the length that you specify for any of the LFSRs is greater than 512, then you must manually
enter the LFSR tap points.
To manually add the LFSR tap points, use the polynomial information to determine the tap
point positions and the Add LFSR Taps command to place the tap points. Refer to the command
for information about how to use the polynomial information to determine the tap point
positions.
Arguments
• lfsr_length
A required integer less than or equal to 512 that specifies the length of the LFSR for which
you want to list the available polynomials.
Examples
The following example reports the polynomials for a LFSR with at length of 512:
report primitive polynomials 512
Available primitive polynomials for length 512 are:

1: x^512 + x^388 + x^255 + x^125 + 1

2: x^512 + x^426 + x^338 + x^255 + x^171 + x^86 + 1
3: x^512 + x^449 + x^384 + x^319 + x^256 + x^192 + x^128 + x^63 + 1

Related Commands
Add LFSR Connections Add LFSRs
Add LFSR Taps

Command Summary

LBISTArchitect Reference Manual, v2017.3 439

September 2017
BIST Controller Command Dictionary
Report Procedure

Report Procedure
Usage
REPort PRocedure [procedure_name | -All ]
Description
Displays all procedures or the specified procedure.
Arguments
• procedure_name
A string that specifies which procedure to display.
• -All
A switch that specifies that LBISTArchitect display all procedures. This is the default.
Example
The following example displays all procedures:
report procedure -all

Related Commands
Add Scan Groups Save Patterns
Read Procfile Write Procfile
Report Timeplate

440 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Scan Pins

Report Scan Pins

Usage
REPort SCan Pins [{> | >>} file_pathname]
Description
Displays all previously-assigned scan input and scan output pin names.
By default, the output of the command is written to the transcript window of the tool. The
Report Scan Pins command displays the user-specific names of the scan input and scan output
pins of the scan chains
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays all scan input and scan output names for the scan chains.
add scan pins chain1 scan_in1 scan_out1
add scan pins chain2 scan_in2 scan_out2
report scan pins

List of scan chains, input and output pins:

chain1 scan_in1 scan_out1
chain2 scan_in2 scan_out2

Related Commands
Add Scan Pins Delete Scan Pins

Command Summary

LBISTArchitect Reference Manual, v2017.3 441

September 2017
BIST Controller Command Dictionary
Report Set_reset Clocks

Report Set_reset Clocks

Usage
REPort SEt_reset Clocks
Description
Displays a list of all set/reset pins.
The Report Set_reset Clocks command displays a list of all clocks added with the Add Set_reset
Clocks command.
Examples
The following example displays a list of clocks after they have been added to the clock list:
add clocks 0 set1
add clocks 1 reset1
report clocks
set1 off-state = 0, capture_string = 1111111100000000
reset1 off-state = 1, capture_string = 0000000011111111

Related Commands
Add Set_reset Clocks Delete Set_reset Clocks

Command Summary

442 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Report Testprocedure Include

Report Testprocedure Include

Usage
Rep TEstprocedure Include
Description
Displays a list of the include statements added to LBISTArchitect-generated test procedures
using the Add Testprocedure Include command.
Arguments
None.
Example
The following example displays a list of all include statements added using the Add
Testprocedure Include command.
report testprocedure include

Related Topics
Add Testprocedure Include Delete Testprocedure Include

LBISTArchitect Reference Manual, v2017.3 443

September 2017
BIST Controller Command Dictionary
Report Tristate Controller

Report Tristate Controller

This command is not intended for interactive use; it is documented for reference purposes only.
Usage
REPort TRistate Controller
Description
Displays a list of all tri-state controllers.
The Report Tristate Controller command displays a list of the prefix names and widths of all
currently defined tri-state controllers added with the Add Tristate Controller command.
Related Commands
Add Tristate Controller Delete Tristate Controller

Command Summary

444 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Reset State

Reset State
Usage
RESet STate
Description
Resets tool setup back to the initial state at invocation.
The Reset State command, combined with the -All switch, performs the equivalent of exiting
the tool and then reinvoking it. You use this command after you issue commands during the
setup configuration phase of the BIST session and need to reset the tool and start over.
Note: Resetting the tool deletes all pending BIST results. You may want to use the Save BIST
command before resetting the state.
Related Commands
Report Environment Run

Command Summary

LBISTArchitect Reference Manual, v2017.3 445

September 2017
BIST Controller Command Dictionary
Run

Run
Prerequisites: You must define any BIST setup commands during the session before using the
Run command.
Usage
RUN
Description
Causes LBISTArchitect to generate BIST logic.
The Run command causes the applications to generate a BIST controller and other test logic for
the core memory or design, based on your setup configuration.
You can only execute the Run command once per session. To perform a second run, you must
use the Reset State command. To ease setup time, use a dofile for all your session setup
commands.
Examples
The following setup configuration for an LBISTArchitect session sets up a PRPG and a MISR
with taps and connections to an LBISTArchitect controller. It then sets up the scan chain
interfaces and the number of patterns for the controller. The final step is to perform a Run to
generate the controller, and then save it with the Save BIST command.

add lfsr lfsr1 prpg 6 5 -both -out

add lfsr taps lfsr1 1
add lfsr connections scan_in1 lfsr1 1 2
add lfsr lfsr2 misr 4 0 -both -out
add lfsr taps lfsr2 1
add lfsr connections scan_out1 lfsr2 2
set iscan interface -channel 1 -max_length 7 -clock clk -sen scan_en
set lbist controller -patterns 100
add scan pins chain1 scan_in1 scan_out1
run
save bist

Related Commands
Report Environment Reset State
Save BIST Setup File Naming

Command Summary

446 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Save BIST

Save BIST
Prerequisites: You must first issue the Run command.
Usage
SAVe BIst [-Replace]
Description
Saves the BIST output files. By default, the files are saved in the same format as the input
netlist. You can also use the Set Output Format command to specify the output format.

By default, LBISTArchitect uses the top-level entity or module name of the design as a prefix
and/or suffix for the saved filenames. You can use the Setup File Naming command to specify
names for the output files.
By default, LBISTArchitect outputs the following files:
• entity_bist.suffix — the BIST controller RTL file.
• entity_bsda_in.suffix — the BISTed top level entity or module for use with
BSDArchitect.
• entity_bsda.do — BSDArchitect dofile.
• entity_faultsim.do — fault simulation phase dofile.
• entity_trans_faultsim.do — fault simulation phase dofile for transition fault grading.
• entity_core_faultsim.do — core-level fault simulation phase dofile.
• entity_trans_core_faultsim.do — core-level fault simulation phase dofile for transition
fault grading.
• entity_topup_atpg.do — Tessent FastScan topup ATPG dofile.
• entity_topup_atpg_fault — topup ATPG fault simulation driver file.
• entity_bist.testproc — stand-alone mode test procedure file.
• entity_trans_bist.testproc — stand-alone mode test procedure file for transition fault
grading.
• entity_bist.ctestproc — core-level test procedure file.
• entity_trans_bist.ctestproc — core-level test procedure file for transition fault grading.
• entity_topup.testproc — top-level scan chain test procedure file.
• entity_bist_synth.scr — default Design Compiler synthesis script file.
• entity_bist.pat — pattern file (fault simulation mode)
• entity_bist.lfsr.trace — LFSR trace file (fault simulation mode)

LBISTArchitect Reference Manual, v2017.3 447

September 2017
BIST Controller Command Dictionary
Save BIST

• entity_bist.wgl — WGL pattern template file (you must edit to include the correct
signature)

Note
In the v8.2009_3 release and all subsequent releases, test bench generation does not occur
when the Save BIST command is executed. Test bench generation occurs during the test
bench generation step. For more information, see the -tbgen option of the lbistarchitect
shell command.

In addition, if you issue the Setup Synthesis Script command before issuing the Save BIST
command, LBISTArchitect saves a script file and names it entity_bist_synth.scr. This is a
Design Compiler script for synthesizing the BIST controller RTL and merging it with the core
design.
Arguments
• -Replace
Optional switch that overwrites existing output files of the same name.
Examples
To save the BIST Controller phase output files, enter the following commands:
// ** Successfully added BIST circuitry.
LBISTA>
// command: save bist -replace
// Saved m8051_e_bist.v
// Saved m8051_e_bsda_in.v
// Saved m8051_e_bist.testproc
// Saved m8051_e_topup.testproc
// Saved m8051_e_topup_atpg.do
// Saved m8051_e_bsda.do
// Saved m8051_e_bist.ctestproc
// Saved m8051_e_faultsim.do
// Saved m8051_e_core_faultsim.do
// Saved m8051_e_diagnose.do
// Saved m8051_e_bist_synth.scr
// Saved m8051_e_trans_bist.ctestproc
// Saved m8051_e_trans_core_faultsim.do
// Saved m8051_e_trans_bist.testproc
// Saved m8051_e_trans_faultsim.do
Note: Updated LBISTArchitect configuration file
‘m8051_e_bist.v.lbcfg’.

Related Commands
Run Setup File Naming
Setup Synthesis Script

448 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Save History

Save History
Usage
SAVe HIstory filename [-Replace]
Description
Saves the command-line history file to the specified file.
The Save History command saves the list of previously executed commands in the file that you
specify. You can then execute the file using the Dofile command.
Arguments
• filename
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.
history -nonumbers

dof instructor/fault.do
run
report environment
history -nonumbers
save history my_history -replace

Related Commands
Dofile
History

Command Summary

LBISTArchitect Reference Manual, v2017.3 449

September 2017
BIST Controller Command Dictionary
Save Sequential Patterns

Save Sequential Patterns

Prerequisites: You must first issue the Run command.
Usage
SAVe SEquential Patterns n_patterns {pattern_file bist_faultsim_dofile [-Replace]}
Description
Saves the specified number of sequential patterns to the specified file.
This command writes out the patterns you want to use for calculating the fault coverage for the
BIST controller circuitry. These patterns are based on the patterns applied by the test bench.
LBISTArchitect generates a driver file that reads in the patterns for a sequential fault simulation
on the synthesized, BISTed netlist. LBISTArchitect writes the patterns in FlexTest™ Table
format.
You can issue this command only after executing a Run command. To run a fault simulation on
the sequential (non-scan) portions of your design (such as the BIST controller circuitry), you
need to separately invoke the FlexTest application.
Arguments
• n_patterns
A required integer that specifies the number of patterns you want to save.
• pattern_file
A required string that specifies the name of the file into which the tool saves the patterns.
• bist_faultsim_dofile
A required string that specifies the name of the file into which you want to save the
sequential fault simulation dofile commands.
• -Replace
An optional switch that specifies for the tool to overwrite the contents of pattern_file and
bist_faultsim_dofile, if a file by either name already exists.
Examples
The following example saves 30 patterns for use in a FlexTest sequential fault simulation run:
run
save sequential patterns 30 seq.pats seq_fault_sim.dofile -replace

Related Commands
Run

Command Summary

450 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Bist Clock

Set Bist Clock

Usage
SET BIst Clock input_clk_name
Description
Specifies the name of the master clock.
By default, the tool uses the fastest clock in the design. When you do not specify the clock
frequency data, the tool uses the clock with the largest loading. The input_clk_name must
specify an existing clock pin name.
Arguments
• input_clk_name
An optional string that specifies the name of the clock that you want the tool to use as the
master clock.
Related Commands
Set Lbist Controller Set Shift_rate Divisor

Command Summary

LBISTArchitect Reference Manual, v2017.3 451

September 2017
BIST Controller Command Dictionary
Set BIST Enables

Set BIST Enables

This command is autogenerated by the BIST-Ready phase and is not intended for interactive
use; it is documented for reference purposes only.
Usage
SET BIst Enables {-Lbist_enable xbnd_enable | -TEST_Obs obs_enable | -TEST_En
cntlpt_enable}…
Description
Specifies the names of the enable signals controlling control points, x-bounding multiplexers,
and observe sink points.
Arguments
For the following three arguments, you can pick one or more, but you must pick at least one.
You should not pick any one argument more than once.
• -Lbist_enable xbnd_enable
A switch and string pair that specifies the name of the signal that enables x-bounding
muxes.
• -TEST_Obs obs_enable
A switch and string pair that specifies the name of the signal that enables observe sink points
in existing scan cells.
• -TEST_En cntlpt_enable
A switch and string pair that specifies the name of the signal that enables control points.
Related Commands
Set Scan Enables

Command Summary

452 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Capture Waveform

Set Capture Waveform

Usage
SET CApture Waveform capture_waveform_name {clock_name | clock_domain_name}
{PULSE | STRETCH | HOLD} “waveform_string”
Description
Defines the waveform the tool applies to the core when the named capture window is active.
Each capture window you define with the Add Capture Window command represents a set of
waveforms the tool applies to the core clock signals during the capture window. Once you have
defined a capture window using the Add Capture Window command, you can specify the shape
of each clock waveform using the Set Capture Waveform command.
The capture window size is set based on the number of characters in the first Set Capture
Waveform command. All further Set Capture Waveform commands must define waveforms
with the same number of positions.
Note
All clock signals that you do not explicitly define using the Set Capture Waveform
command for a given capture window will be forced to all zeroes.

For more information, see “At-speed Testing of Designs with High Speed Clocks” in the
LBISTArchitect Process Guide.
Arguments
• capture_waveform_name
A required string that specifies the name of the custom capture window that you created
with the Add Capture Window command.
• clock_name
A required string that specifies the name of a clock signal that you specified in the Add
Clocks or Add Set_reset Clocks command.
• clock_domain_name
A required string that specifies a clock domain defined by the Add Clock Domain
command. LBISTArchitect defines the Set Capture Waveform command once for each
clock domain.
Note
Any clock, defined by a clock_name argument, must have the same waveform mode
(PULSE, HOLD, or STRETCH) in all capture windows; a different clock may have a
different waveform mode.

LBISTArchitect Reference Manual, v2017.3 453

September 2017
BIST Controller Command Dictionary
Set Capture Waveform

• PULSE
A literal that allows you to generate full speed clock pulses during the capture window.
Each “1” in the capture window generates a single clock pulse at the bist_clk frequency.
• HOLD
A literal that allows you to generate slow clock pulses during the capture window. Each “1”
in the capture window holds the core clock signal in the active state for the entire cycle.
You can use this mechanism to generate clock pulses at 1/2, 1/4, 1/6 (and so on) of the
bist_clk frequency.
• STRETCH
A literal that allows you to generate slow clock pulses during the capture window. Each “1”
in the capture window holds the core clock signal in the active state for the entire cycle.
However, the active to inactive state transition is delayed by an extra 1/2 cycle.
You can use this mechanism to generate clock pulses at 1/3, 1/5, 1/7 (and so on) of the
bist_clk frequency.
• “waveform_string”
A required string (surrounded by double quotes) of ones and zeroes (0s and 1s) that specifies
the waveform_string that the tool will apply to the core when the named capture window is
active. Each position in the string represents one bist_clk cycle during the capture window.
The left most character in the waveform_string represents the first bist_clk cycle in the
capture window. The right most character in the waveform_string represents the last
bist_clk cycle in the capture window. Thus time passes as you go from left to right through
the waveform string.
• A zero “0” in the waveform_string always means keep the core clock signal off
during that cycle.
• A one “1” in PULSE mode means drive the core clock with a pulse from bist_clk
during just the cycle.
• A one “1” in HOLD mode means hold the core clock in the active state during the
entire bist_clk cycle.
• A one “1” in STRETCH mode also means hold the core clock in the active state for
the entire cycle. However, in STRETCH mode, the core clock is actually held active
for the entire cycle with the “1”, and also for the first half of the next cycle.
For example, in STRETCH mode, a waveform_string of “100” drives the core clock active
for 1 1/2 cycles and then holds it inactive for 1 1/2 cycles.

454 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Capture Waveform

Example 1
In this example, there are three clocks and two reset signals in the design, requiring the
following three capture windows:
• cap1 — Capture window for patterns 0 to 12.
• cap2 — Capture window for pattern 13.
• cap3 — Capture window for patterns 14 and 15.
This gives a cycle of 16 patterns before starting again. The following dofile excerpt shows the
command sequence:
//Capture window for patterns 0 to 12; CLK1, CLK2, and CLK3 are pulsed
add capture window cap1 0 12
set capture waveform cap1 CLK1 pulse “110000”
set capture waveform cap1 CLK2 pulse “001100”
set capture waveform cap1 CLK3 pulse “000011”
//see Figure 3-10 for cap1 waveforms

//Capture window for pattern 13; reset is held for two clock cycles
add capture window cap2 13 13
set capture waveform cap2 RESET hold “001100”
//see Figure 3-11 for cap2 waveforms

//Capture window for patterns 14 and 15

add capture window cap3 14 15
set capture waveform cap3 TRESET stretch “001100”
//see Figure 3-12 for cap3 waveforms

LBISTArchitect Reference Manual, v2017.3 455

September 2017
BIST Controller Command Dictionary
Set Capture Waveform

Figure 3-10. Set Capture Waveform cap1 Waveforms

Figure 3-11. Set Capture Waveform cap2 Waveforms

456 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Capture Waveform

Figure 3-12. Set Capture Waveform cap3 Waveforms

LBISTArchitect Reference Manual, v2017.3 457

September 2017
BIST Controller Command Dictionary
Set Capture Waveform

Example 2
The following example defines two clock domains. The first domain definition specifies that
CLK1 and CLK2 will share the same clock hardware logic of the co_clock_control module. The
second domain definition specifies that CLK3, CLK4, CLK5, and CLK6 will share clock
hardware logic. Each Set Capture Waveform command applies to all of the clocks defined for
that domain name.
add clock 1 clk1 clk2
add clock 0 clk3 clk4 clk5 clk6

add clock domain domain1 clk1 clk2

add clock domain domain2 clk3 clk4 clk5 clk6

add capture window wave1 0 254

add capture window wave2 255 255

set capture waveform wave1 domain1 pulse "010"

set capture waveform wave1 domain2 pulse "000"

set capture waveform wave2 domain1 pulse "000"

set capture waveform wave2 domain2 pulse "010"
run

Related Commands
Add Clock Domain Report Capture Window
Add Capture Window Set Lbist Controller
Delete Capture Window

Command Summary

458 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Clock Buffer

Set Clock Buffer

Prerequisites: You must add the cell_name using the Add Cell Models command before you can
use it as a buffer.
Usage
SET CLock Buffer {clock_or_scan_en_name cell_name}…
Description
Generates a generic or technology-specific buffer for clocks and scan enables.
For designs with multiple clock domains, it may be desirable to add buffers to the BIST master
clock and the clocks supplied to the core for a multiple-clock core. Also, scan enables may need
buffering if they drive a large number of cells.
The Set Clock Buffer command generates either a generic or technology-specific buffer for a
specified clock or scan enable. LBISTArchitect will also place buffers at the output of clock
suppression multiplexers in the mcd_mux_d block of the BIST controller. The buffered clock(s)
/ scan enables will drive all the BIST controller components such as PRPG, MISR, shift
counter, pattern counter, and the core.
If you specify a generic buffer, LBISTArchitect generates the following entity and architecture
for the buffer in the BIST controller:
entity CLKBUF is
port(A: in std_logic;
Y: out std_logic);
architecture RTL of CLKBUF is
begin
Y <= A;
end RTL;

The tool then instantiates this entity to buffer the clock and scan enable signals as follows:
library IEEE;
use IEEE.std_logic_1164.all;
ENTITY Example_BIST is
port (...);
end Example_BIST;
ARCHITECTURE RTL of Example_BIST is
component CLKBUF
port(A: in std_logic;
Y: out std_logic);
end component;
End RTL;

For an example of the command using a technology-specific buffer, see the Examples section
for this command.

LBISTArchitect Reference Manual, v2017.3 459

September 2017
BIST Controller Command Dictionary
Set Clock Buffer

Arguments
• clock_or_scan_en_name cell_name
A required repeatable string pair that specifies the name of the clock or scan enable and
whether the buffer is a generic or technology-specific cell. The cell_name must be the name
of an existing cell added with the Add Cell Models command, or the tool will issue an error.
You can buffer the master clock that drives the BIST components by specifying
master_clock as the clock name. Every other clock/scan enable must be an existing port on
the core. If you issue more than one Set Clock Buffer command, the last one prevails.
Examples
You can generate a technology-specific buffer by providing the name of the clock/scan enable
and the name of the technology cell (which you must have previously established with the Add
Cell Models command).
The following commands add a generic clock buffer to the master clock and clk2, and a tsc500
technology-specific buffer, cts55, to clk1.
add cell models generic -type buffer -input A -output Y
add cell models cts55 -type buffer -input A -output Y -library tsc5000
set clock buffer master_clock generic clk1 cts55 clk2 generic

LBISTArchitect instantiates that specific component to buffer the clock and scan enable signals,
as follows:
library IEEE;
use IEEE.std_logic_1164.all;
library TSC5000;
use TSC5000.all;
ENTITY Example_BIST is
port (...);
end Example_BIST;
ARCHITECTURE RTL of Example_BIST is
component CTS55
port(A: in std_logic;
Y: out std_logic);
end component;
End RTL;

Related Commands
Add Cell Models Delete Cell Models
Report Cell Models

Command Summary

460 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Clock Loading

Set Clock Loading

This command is autogenerated by the BIST-Ready phase and is not intended for interactive
use; it is documented for reference purposes only.
Usage
SET CLock Loading clock_name [load_factor | Undefined]
Description
Assigns a load factor or the literal value “undefined” to the clock specified by the clock_name
argument.
During the -bist_ready phase, the tool generates one Set Clock Loading command for each
clock in the design. The load factor indicates the percentage of flip-flops driven by a particular
clock in relation to the number of total flip-flops in the design.
The sum of all individual clock load values is 1.0 which coresponds to 100%.
The tool uses the assigned clock load factor to determine the number of patterns used to test
each clock in cases where the capture procedures and waveforms are not manually specified.
Note
Clock signals that only drive set and reset signals are assigned a load factor of 0.0. Each
of these signals is assigned a capture window that is active for one pattern out of every 32
or 64, depending on the number of patterns before the capture window sequence repeats.

Arguments
• clock_name
A required string that specifies the name of the clock for which you are setting the load
factor.
• load_factor
A positive real number that specifies the percentage of flip-flops driven by a particular
clock. If this argument is not specified, the literal “undefined” argument must be specified.
• Undefined
A literal that sets the load factor for the clock to 0.0. If this argument is not specified, you
must specify a load_factor.
Example 1
The following example shows the commands generated when two clocks exist in the design
and clock1 drives a quarter of the flip-flops while clock2 drives three quarters of the flip-flops:
set clock loading clock1 .25
set clock loading clock2 .75

LBISTArchitect Reference Manual, v2017.3 461

September 2017
BIST Controller Command Dictionary
Set Clock Loading

Example 2
The following example sets the load factor for clock3 to 0.0:

set clock loading clock3 undefined

Related Commands
Add Clocks Set Capture Waveform

Command Summary

462 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Clock Period

Set Clock Period

Prerequisites: You must already have added clkname with the Add Clocks command.
Usage
SET CLock Period [clkname | -Interface_clk] {[-Period time_period] |
[-Frequency time_period] | [-None]}
Description
Specifies the period (or frequency) and duty cycle of a defined clock or control signal, or to
remove all clock timing that you have previously defined with the Set Clock Period command.
LBISTArchitect uses the Set Clock Period command when generating the test bench and test
vector files. This value is also used to specify clock timing in the Synopsys Design Compiler
script that is generated during the Bist Controller generation phase. Within the BIST controller,
the clock waveform for capture clocks is defined by the Set Capture Waveform command. The
waveform for the input clock to the BIST controller is defined by the ATE. The tool assumes
when generating test benches and test vectors that the clock has a 50% duty cycle.
Arguments
• clkname
A string that specifies the name of the clock for which you are setting the period. You must
specify a clkname, or use the -Interface_clk switch.
• -Interface_clk
A switch the specifies for the tool to apply the period to the slow BIST controller interface
clock (bist_tck). The default period value for the slow TCK clock is 500 ns.
• -Period time_period
A switch and integer pair that specifies the period for the clock, clkname. The time_period
units are nanoseconds (ns).
• -Frequency time_period
A switch and integer pair that specifies the frequency for the clock, clkname. The
time_period unit is megahertz (Mhz).
• -None
A switch that removes all clock timing information that you have previously defined for the
clock, clkname.
Related Commands
Add Clocks Set Capture Waveform

Command Summary

LBISTArchitect Reference Manual, v2017.3 463

September 2017
BIST Controller Command Dictionary
Set Core Netlist

Set Core Netlist

Usage
SET CORe Netlist filename VERILOG
Description
Specifies the BIST-Ready output core netlist name and its language.
The core netlist, specified by the filename argument, is both the output of the BIST-Ready phase
and the input to the BIST-Controller phase. You must use this command to specify the name
and language of the input core netlist if you want the tool to generate a Design Compiler(tm)
synthesis script.
Note
The core netlist will most likely be a Verilog netlist even though we are generating a
VHDL description of the BIST Controller.

Arguments
• filename21
A required string that specifies the core netlist output from the BIST-Ready phase. This
argument can be either the pathname or leafname of the netlist.
Caution
The file specified by filename must already exist before you can execute this command.

• VERILOG
A literal switch that specifies that the format of the netlist specified by the filename
argument is Verilog.
Examples
The following example tells LBISTArchitect that the core netlist, fha_scan, is in Verilog
format.
set core netlist fha_scan verilog

Related Commands
Setup Synthesis Script

Command Summary

464 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Dofile Abort

Set Dofile Abort

Usage
SET DOfile Abort ON | OFf
Description
Lets you specify whether the tool aborts 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. The Set Dofile Abort command enables you
to turn this functionality off, so that 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 the default
upon invocation of the tool.
• OFf
A literal that forces dofile processing to complete all commands in a dofile regardless of
error detection.
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

Related Commands
Dofile

Command Summary

LBISTArchitect Reference Manual, v2017.3 465

September 2017
BIST Controller Command Dictionary
Set Dynamic X_bounding

Set Dynamic X_bounding

Usage
SET DYnamic X_bounding enable_name {capture_name...}
Description
Specifies that the tool should drive the enable signal that controls dynamic x-bounding of
memory elements that capture values from multicycle paths.
A design that contains multicycle paths is defined as having combinational logic paths between
memory elements that require more than one system clock cycle to acquire the new value.
The issue is that the registers that capture the values from multicycle paths capture unknown
values during Logic BIST testing. To resolve this issue the tool can add x-bounding logic to all
memory elements that capture values from a multicycle path.
This x-bounding logic consists of OR gates that let the tool capture a known value (of ‘1’) from
the multicycle path. These x-bounding gates are controlled by a dynamic signal that is derived
from the pattern counter. Once this mechanism is in place, the tool can create a special capture
window that generates two clock pulses with the appropriate time separation to allow the
multicycle path to stabilize before capture. The tool disables the x-bounding gates only when
this capture window is applied.
When dealing with multicycle paths, you first need to issue the Add Multi_cycle Path command
during the BIST-Ready phase of the tool. This command sets up the enable signal(s) and inserts
the OR gates that perform the actual x-bounding in the core netlist.
Note
You must issue this command for each signal that enables x-bounding and previously
defined with the Add Multi_cycle Path command. The enable signal is driven high (x-
bounding is enabled) during the enable windows that you specified as part of this
command. The enable signal remains low for any capture window(s) that you do not
specify in the Set Dynamic X_bounding command.

Arguments
• enable_name
A required string that specifies an enable signal name that you must have previously defined
in the BIST-Ready phase with the Add Multi_cycle Path command. The BIST controller
will dynamically drive this enable_name signal during this BIST-Controller phase.
• capture_name
A required string that specifies the name of a capture window that you must have previously
defined in this same phase (BIST-Controller) with the Add Capture Window command. The
dynamic x-bounding signal is activated (set to ‘1’) for all the capture window that you have
specified.

466 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Dynamic X_bounding

Related Commands
Add Capture Window Delete Capture Window
Add Multi_cycle Path Set Capture Waveform

Command Summary

LBISTArchitect Reference Manual, v2017.3 467

September 2017
BIST Controller Command Dictionary
Set Iscan Interface

Set Iscan Interface

Usage
SET IScan Interface [-CHannel number] [-Max_length number] [-SCell number]
Description
Defines the internal scan interface parameters.
LBISTArchitect needs to know the number of STUMPS channels in the design and the
maximum length of these channels. LBISTArchitect uses this information for configuring shift
counters in the BIST controller, as well as for making connections to all the STUMPS channels.
If you specify a parameter with this command, it changes any previous setting. For any
parameter that you do not specify, the previous setting remains.
Arguments
• -CHannel number
An optional switch and integer pair specifying the number of scan chains in the design for
use as STUMPS channels. By default, LBISTArchitect uses the number 24.
• -Max_length number
An optional switch and integer pair specifying the maximum length (number of scan cells)
of any scan chain (STUMPS channel) in core logic or boundary scan. By default,
LBISTArchitect uses the number 512.
• -SCell integer
An optional switch and integer pair that lets you specify the exact number of scan cells in
the design, which is the total of all cells in the scan chains inside the design. The default for
this number is 1000
Examples
The following example contains commands specifying that the design contains 2 scan chains,
the longest of which is 88 cells and a scan enable pin, named “scan_en”, that controls only
negative-edge-triggered scan cells. It also specifies the application of 2000 patterns during the
BIST process.
set iscan interface -channels 2 -max_length 88
set scan enables negedge scan_en
set lbist controller -patterns 2000

Related Commands
Add Scan Pins Save BIST
Setup File Naming
Command Summary

468 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Lbist Controller

Set Lbist Controller

Usage
SET LBist Controller [-Patterns number] [-Core_instance instance_name]
[-Flush_test number | -Chain_test number] [-TOp_level_access]
[-MUx_select select_signal_name] [-Reset High | Low]
[-PROgrammable_shift_rate ON | OFF]
[-Control_logic_for_scan_mode ON|OFF]
[-Parallel_interface {ON [-On_chip_comparator OFF | ALL_ONES | golden_misr_value]} |
OFF] [-Scalable_mtpi_phases ON | OFf]
Description
Defines parameters for the logic BIST controller.
By default, LBISTArchitect assumes the core’s internal scan chains are not initialized before
applying the BIST patterns. To prevent this uninitialized data from reaching the MISR,
LBISTArchitect adds logic to the BIST controller that places the MISR in a hold state while
loading the scan chains with the initial BIST pattern.
You can use the Set Lbist Controller command to change the default scan enable test settings by
using either the -Chain_test or -Flush_test switch. The default chain test suppresses all capture
clock activity during the capture window. Therefore, this test works well when performing at-
speed testing using multiple clock pulses in the capture window, since these clock pulses may
violate timing constraints in “shift mode”. By default, the tool performs the chain test with 32
patterns.
Alternately to using the -Chain_test, you can use the -Flush_test switch for testing and detecting
faults on the scan enables, where LBISTArchitect holds the scan enable signals in “shift mode”
during the capture window for a small number of patterns while still applying the desired clock
sequences. This process tests for stuck-at-capture-mode faults on the input cones to the scan
enables. These patterns will be the first patterns of the BIST test.
Set Lbist Controller also lets you multiplex the MTPI phase decoder signal to the top level, for
use by ATPG tools, with the -TOp_level_access switch. Figure 3-13 shows how the tool ANDs
the phase control signal (changeable from the default by issuing the Set Testpoint Parameters
command) with the bist_run signal. This ensures that the MTPI phase decoder signals are all
disabled when the system mode is not ATPG_mode and BIST is not being run.

LBISTArchitect Reference Manual, v2017.3 469

September 2017
BIST Controller Command Dictionary
Set Lbist Controller

Figure 3-13. MTPI Phase Decoder Signal Multiplexing

Top Level BIST Controller Core

bist_run
0
phase_cntlN MUX
atpg_mtpi_cntlN phase_cntlN
1

atpg_mode

You can optionally specify that the BIST controller includes an asynchronous test trigger signal
to activate the test, and provide direct access to the MISR value using an output vector
(misr_value). Configuring the BIST controller for this operation results in a simplified method
for determining the pass/fail status of test. See “Setting Up an Asynchronous BIST Test” in the
LBISTArchitect Process Guide for complete details and limitations of this option.
Arguments
• -Patterns number
An optional switch and integer pair specifying the number of patterns to apply. Note that
LBISTArchitect checks to ensure this number is not greater than 2k-1, where k is the
number of bits in the PRPG. By default, LBISTArchitect uses the number 10,000.
• -Core_instance instance_name
An optional switch and string pair specifying the core instance name in the generated Logic
BIST RTL file. The default name is core_i. This option lets you redefine this core instance
as follows:
In a VHDL example, the core was instantiated as follows:
core_i: XYZ port map (...);

You can change the name of the core instance from “core_i” to “ABC” using the
-Core_instance instance_name combination. The corresponding RTL file now
instantiates the core as follows:
ABC: XYZ port map (...);

• -Flush_test number
An optional switch and integer pair that specifies the number of patterns for which to
conduct flush testing. Specifying a 0 results in no flush test.
• -Chain_test number
An optional switch and integer pair that specifies the number of pseudo-random patterns
that are to be driven through the scan chains. You can either use the -Chain_test or the
-Flush_test switch, but not both. The -Chain_test switch is the tool default, and 32 is the
default number of patterns. Specifying a 0 results in no chain test or flush test.

470 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Lbist Controller

The -Chain_test switch causes the tool to modify the RTL so that no capture clock signals
are generated in the capture window during execution of the chain test patterns, which
means that the unload values will exactly match the load values. This test produces a
different MISR signature than when using the -Flush_test switch.
• -TOp_level_access
An optional switch specifying for LBISTArchitect to generate multiplexers for bist_run and
MTPI phase decoder signals. If you issue this switch alone, LBISTArchitect creates new
top-level ports with the name “atpg_signalname” (where signalname is the name of the
phase decoder or bist_run signal) and multiplexes them with the BIST-mode phase decoder
signals. If you do not set the -Mux_select switch, by default LBISTArchitect uses
atpg_mode as the select signal name.
Note
If you use the Set Testpoint Parameters command with the -Ports option, the phase
decoder signals assigned by that command will override any default signal and
signalname, phase_cntlN.

• -MUx_select select_signal_name
An optional switch and string pair specifying the default select signal name for the
multiplexers generated by the -Top_level_access switch. If the select_signal_name is not
already present at the top-level, LBISTArchitect creates a new pin. If you do not use this
switch, the default select_signal_name is atpg_mode.
• -Reset High | Low
An optional switch and literal pair that specifies whether the BIST reset signal (bist_reset) is
an active high or low signal. The default is that the bist_reset is an active high signal.
• -PROgrammable_shift_rate ON | OFF
An optional switch and literal pair that specifies using a unique shift rate. You use this in
conjunction with Set Shift_rate Divisor. The default is off.
• -Control_logic_for_scan_mode ON | OFF
An optional switch and literal pair that triggers the creation of additional hardware in the
BIST controller to simplify the insertion of scan chains inside the controller. These scan
chains are used to test the BIST controller during top-level ATPG and must not be active
during the LBIST test. The additional hardware in the controller fixes several scan insertion
DRC violations and is activated by a new top-level pin called bist_ip_scan_mode.
See “Setting Up Scan Insertion for the BIST Controller” in the LBISTArchitect Process
Guide for complete details.
• -Parallel_interface ON | OFF
An optional switch and literal pair specifying the addition of an interface for asynchronously
triggering a Logic BIST test and accessing the final MISR signature. If you specify ON,
then this argument adds a bist_run_input input for triggering the test. The bist_done output

LBISTArchitect Reference Manual, v2017.3 471

September 2017
BIST Controller Command Dictionary
Set Lbist Controller

signal transitions from low to high upon completion of the test. The misr_value output is a
vector providing direct access to the MISR value during the test. When this switch is set to
ON, it can be used in conjunction with the -ON_chip_comparator switch.
See “Setting Up an Asynchronous BIST Test” in the LBISTArchitect Process Guide for
complete details and limitations.
• -On_chip_comparator OFF | ALL_ONES | golden_misr_value
An optional switch and string or literal pair specifying the addition of an on chip comparator
block to the BIST controller. This switch can only be used when the -parallel_interface
switch is set to ON. Choose one from the following:
OFF — a literal turning off on-chip comparator addition.
ALL_ONES — a literal specifying all bits in the MISR are compared against 1.
golden_misr_value — a string of 0s (zeros) and 1 (ones) representing the reference
MISR signature. For example:
set lbist controller ... -On_chip_comparator 10000110000111110010110001110000

You must specify either golden_misr_signature or ALL_ONES; subsequently, this

argument adds a bist_run_input input for triggering the test and two outputs. Upon
completion of the test, the bist_done output transitions from low to high. The test_fail output
goes low at the end of the test if the internal MISR signature matches the specified reference
signature.
See “Setting Up an Asynchronous BIST Test” in the LBISTArchitect Process Guide for
complete details and limitations.
• -Scalable_mtpi_phases ON | OFf
An optional switch that specifies to enable the activation of all MTPI phases for any number
of test patterns. When this switch is enabled, the phase decoder is connected to the two bits
of the pattern counter directly to the left of the most significant bit of the capture window
decoder. For more information, see “Inserting Test Points Using MTPI” in the
LBISTArchitect Process Guide
Example 1
The following commands specify that the design contains 2 scan chains, the longest of which is
88 cells, and a scan enable pin named “scan_en.” It also specifies that you want to apply 2048
patterns during the BIST process using a stand-alone BIST controller:
set iscan interface -channel 2 -max_length 88
set lbist controller -patterns 2048

Example 2
The following example defines clk1 and clk2 as clocks with zero off-state, and set1 and reset1
with off-state 0 and 1, respectively. The Set Multi_domain Parameters command specifies that
clock clk1 captures for 1/2 of the total number of patterns, clk2 captures for 1/4 of the total
number of patterns, and set1 and reset1 capture for 1/8 of the total number of patterns. The final
command sets LBISTArchitect to perform 1024 patterns with no flush test.

472 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Lbist Controller

add clocks 0 clk1 clk2

add set_reset clocks 0 set1
add set_reset clocks 1 reset1
set multi_domain parameters -master clk1 -phases 8 clk1 11110000 clk2 00001100
set1 00000010 reset1 00000001
set lbist controller -patterns 1024 -flush_test 0

Example 3
The following example results in multiplexers for bist_run signals and MTPI signals.
LBISTArchitect multiplexes the BIST port mtpi_cntl1 (ANDed with bist_run) with the top-
level signal atpg_signal1. If this top-level port does not already exist, the tool creates it.
Because the -Mux_select option is not specified for this port, the default multiplexer select
signal is default_select as specified by the Set Lbist Controller command.
set lbist controller -top_level_access -mux_select default_select
set testpoint parameters -ports mtpi_cntl1 mtpi_cntl2 mtpi_cntl3

Figure 3-14. Example Schematic

mtpi_cntl1
0 mtpi_cntl1
bist_run
MUX
atpg_signal1 1

default_select
mtpi_cntl2
0 mtpi_cntl2
bist_run
MUX
atpg_signal2 1

special_select

mtpi_cntl3
0 mtpi_cntl3
bist_run
MUX
atpg_mtpi_cntl3 1

default_select

Related Commands
Add Scan Pins Set Iscan Interface
Run Set Retiming Logic
Set Shift_rate Divisor
Command Summary Set Testpoint Parameters

LBISTArchitect Reference Manual, v2017.3 473

September 2017
BIST Controller Command Dictionary
Set Logfile Handling

Set Logfile Handling

Scope: All modes
Usage
SET LOgfile Handling [-RESume | {filename [-Replace | -Append]}
Description
Specifies for LBISTArchitect to direct the transcript information to a file.
The tool can generate logfiles in two ways: by using the -Logfile switch when you invoke the
tool, or by interactively issuing the Set Logfile Handling command during the session. Use this
command to generate a new logfile, replace an existing logfile, or append information to a
logfile that already exists.
Issuing this command causes LBISTArchitect to write the transcript information, which
includes the commands and the corresponding output (if any), into the file you specify. You can
execute the Set Logfile Handling command at any time within the BIST Controller phase, and
you can also execute it multiple times.
In the logfile, all commands that LBISTArchitect executes are preceded with the command
keyword. You can easily search for the commands you executed, and then you can generate a
separate dofile containing those commands, which you can rerun within LBISTArchitect.
When you set the logfile handling, LBISTArchitect still writes the same information to the
session transcript window in addition to the logfile.
If you want LBISTArchitect to stop writing to a logfile, issue the Set Logfile Handling
command with no options, which closes the appropriate files.
Arguments
• -Resume
An optional switch that specifies for the tool to resume writing transcript output to the
logfile specified at invocation with the -Logfile invocation switch. You do not need to
include the name of the invocation logfile with this switch; the tool will remember the name.
• filename
An optional string that specifies the name of the file where you want LBISTArchitect to
write the transcript output. This string can be a full pathname or a leafname. If you only
specify a leafname, the tool creates the file in the directory from which you invoked the tool.
If you do not specify a filename, the tool discontinues writing logfiles and closes the
appropriate files.
• -Replace
An optional switch that forces LBISTArchitect to overwrite the file, if a file by that name
already exists.

474 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Logfile Handling

• -Append
An optional switch that causes LBISTArchitect to begin writing the transcript at the end of
the specified file.
Examples
The following example specifies for LBISTArchitect to write a logfile and to disable the writing
of the transcript:
set logfile handling /user/designs/setup_logfile -replace
run
save bist

Related Commands
lbistarchitect

Command Summary

LBISTArchitect Reference Manual, v2017.3 475

September 2017
BIST Controller Command Dictionary
Set Output Format

Set Output Format

Usage
SET OUtput Format [VErilog | VHdl]
Description
Sets the language of the RTL and test bench files.
By default, the tool generates the RTL and test bench files using the same language that was
used for the gate level netlist in the Bist-Ready phase. You can override this behavior by issuing
this command. Since some of the processing that the tool does during the Run command is
language specific, you must issue the Set Output Format command before the Run command.
Arguments
• VErilog
A literal that specifies for the tool to write the RTL and test bench in Verilog instead of the
native gate level VHDL netlist that was the original input to the Bist-Ready phase.
• VHdl
A literal that specifies for the tool to write the RTL and test bench in VHDL instead of the
native gate level Verilog netlist that was the original input to the Bist-Ready phase.
Related Commands
Command Summary

476 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Retiming Logic

Set Retiming Logic

Usage
SET REtiming Logic [-CLock_control {Latch | Flip_flop}]
[-SCan_enable {[Latch | Flip_flop | NOne}]
[-Prpg {Latch | Flip_flop | NOne}]
[-Misr {Latch | Flip_flop | NOne}]
[-COre_chains {[Latch | Flip_flop | NOne | ALL_Latch | ALL_Flop}]
[-Top_chains {[Latch | Flip_flop | NOne | ALL_Latch | ALL_Flop}]
Description
Provides a mechanism for specifying the use of lockup latches or flip-flops for re-timing logic
within your design.
By default, LBISTArchitect uses latches in the generation of re-timing logic. With this
command, you can specify where you want the tool to use flip-flops instead of latches.
The following figure illustrates the effect of the -Scan_enable switch on the timing of the scan
enable signal.

Figure 3-15. Scan Enable Timing Modification

Capture Pulse

Core Clock

Bist Clock

-SCan_enable [Latch | Flip_flop]

scan_en

-SCan_enable [NOne] scan_en

Arguments
• -CLock_control {Latch | Flip_flop}
An optional switch and literal pair that specifies for the tool to use negative edge flip-flops
instead of the default latches. The clock control block generates the enable signals that the
tool needs for clock gating. These enable signals must transition on the negative edge of the
clock.

LBISTArchitect Reference Manual, v2017.3 477

September 2017
BIST Controller Command Dictionary
Set Retiming Logic

• -SCan_enable {Latch | Flip_flop | NOne}

An optional switch and literal pair that specifies whether the tool uses a negative edge flip-
flop or a latch to generate the negative edge based signals, or directly drives the scan enable
with a signal that changes after the positive edge of the slow_bist_clk.
Note
For designs with scan cells driven using the negative edge of the clock, you must use
either the Set Scan_enable Switching command with the “slow” option, or ensure that
there is no clock skew between the slow_bist_clk and the core clocks.

• -Prpg {Latch | Flip_flop | NOne}

An optional switch and literal pair that specifies the type of circuitry the tool inserts for the
BIST controller circuitry that drives the inputs of the scan chains. By default, the tool adds
lockup latches after the PRPG that generates the inputs to the scan chains. You can use the
Flip_flop option to specify that flip-flops are added instead. You can also use the None
option to specify to remove all re-timing logic on the scan input side.
• [-Misr {Latch | Flip_flop | NOne}]
An optional switch and literal pair that specifies the type of circuitry the tool inserts for the
BIST controller circuitry that captures the outputs of the scan chains. By default, the tool
adds lockup latches before the MISR inputs that capture the outputs from the scan chains.
You can override the use of latches with flip-flops using this switch. You can use the
Flip_flop option to specify that flip-flops are added instead. You can also use the None
option to specify to remove all re-timing logic on the scan output side.
• -COre_chains {Latch | Flip_flop | NOne | ALL_Latch | ALL_Flop}
An optional switch and literal pair that specifies the type of circuitry that the tool inserts for
the BIST controller circuitry that drives the inputs and captures the outputs of the scan
chains. By default, the tool adds lockup latches before the scan chain inputs, and after the
scan chain outputs. You can use the Flip_flop option to specify that flip-flops are added
instead.
You can also use the None option to specify to remove all re-timing logic. The None option
assumes that all the clock trees in your design are balanced with respect to each other.
The All_flop and All_latch options force the addition of a latch or flip-flop between every
scan chain without considering the timing.
Caution
Due to the possible impact on the size and timing of your design, you must use extreme
care when using the All_flop and All_latch options.

• -Top_chains {Latch | Flip_flop | NOne | ALL_Latch | ALL_Flop}

If you are using the Connect Iscan Chains command that merges several internal scan
chains, the tool adds re-timing logic based on the clock timing at the first scan cell of the
next scan chain and also at the last scan cell of the previous scan chain. By default, the tool

478 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Retiming Logic

adds lockup latches for the re-timing logic, which you can override with flip-flops using this
switch.
The None option allows you to remove all re-timing logic. The None option assumes that all
the clock trees in your design are balanced with respect to each other.
The All_flop and All_latch options force the addition of a latch or flip-flop between every
scan chain without considering the timing.
Caution
Due to the possible impact on the size and timing of your design, you must use extreme
care when using the All_flop and All_latch options.

Example 1
The following example specifies that retiming logic for scan chain inputs is placed directly after
the PRPG outputs. Because no -Misr command switch is specified for the outputs, by default,
the tool adds lockup latches after each scan chain output that requires a retiming element.

set retiming logic -prpg latch

run

Example 2
The following command line specifies that retiming logic for scan chain inputs is placed
directly after the PRPG outputs and retiming logic for scan chain outputs is placed directly
before the MISR inputs.

set retiming logic -prpg latch -misr latch

run

Related Commands
Command Summary Set Scan_enable Switching
Connect Iscan Chains

LBISTArchitect Reference Manual, v2017.3 479

September 2017
BIST Controller Command Dictionary
Set RTL Hierarchy

Set RTL Hierarchy

Usage
SET RTl Hierarchy -Clk_mux {In | Out} -CLK_Control {In | Out}
Description
Specifies where to place the MCD clock multiplexer or the complete clock control hardware
inclusive MCD clock multiplexer.
The switch -Clk_mux allows a choice between placing the multi-clock domain clock
multiplexer instance inside the BIST controller block or at the top level.
The switch -CLK_Control allows a choice between placing the complete clock control
hardware inside the BIST controller block or instantiating an external clock control module at
the top level.
Arguments
• -Clk_mux {In | Out}
A required switch and literal pair that specifies where to place the clock multiplexer
instance. The default is to place it inside the BIST logic block.
In — A literal that specifies to place the multiplexer inside the logic BIST controller
block. This is the invocation default.
Out — A literal that specifies to place the multiplexer at the top level, outside the logic
BIST block.
• -CLK_Control {In | Out}
A required switch and literal pair that specifies where to place the clock control hardware.
The default is to place it inside the BIST logic block.
In — A literal that specifies to place the clock control hardware inside the logic BIST
controller block. This is the invocation default.
Out — A literal that specifies to place the clock control hardware at the top level,
outside the logic BIST block.
Examples
set rtl hierarchy -clk_mux out
set rtl hierarchy -clk_control out

Related Commands

Command Summary

480 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set RTL Prefix

Set RTL Prefix

Usage
SET RTl Prefix prefix_string
Description
Adds a unique prefix to the beginning of all LBIST modules names in the generated RTL.
You can use this command to avoid name conflicts when inserting logic BIST at the block level
of a design with multiple blocks, in which each block will be tested using a unique controller.
Arguments
• prefix_string
A required string that specifies the characters that are to be appended to the LBIST module
name.
Examples
In the following example, setting the RTL prefix string to core_ would cause bc_bist_controller
to be renamed to core_bc_bist_controller.
set rtl prefix core_

Related Commands
Command Summary

LBISTArchitect Reference Manual, v2017.3 481

September 2017
BIST Controller Command Dictionary
Set Scan Enables

Set Scan Enables

This command is autogenerated by the BIST-Ready phase and is not intended for interactive
use; it is documented for reference purposes only.
Usage
SET SCan Enables {polarity scan_en_name}…
Description
Specifies the names and polarities of scan enable signals.
The Set Scan Enables command allows you to identify which signals to use as scan enables, as
well as the polarity of those signals. If the design contains negative-edge-triggered flip-flops
that capture data from positive-edge-triggered flip-flops, LBISTArchitect adds the Set
Split_capture Cycle On command to the Fault Simulation phase driver file. The tool will also
add the Set Split_capture Cycle On command to the driver file if you specify multiple scan
enables of positive and negative polarity, or if a scan enable controls both negative-edge-
triggered and positive-edge-triggered scan cells.

Arguments
• polarity scan_en_name
A required, repeatable, literal and string pair.
The literal, polarity, can be one of three values:
Posedge — Specifies that scan_en_name controls only positive-edge-triggered scan
cells.
Negedge —Specifies that scan_en_name controls only negative-edge-triggered scan
cells.
Mixedge — Specifies that scan_en_name controls both positive-edge-triggered and
negative-edge-triggered scan cells.
The string, scan_en_name, specifies a core design scan enable pin.
Related Commands
Set BIST Enables

Command Summary

482 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Scan_enable Switching

Set Scan_enable Switching

Usage
SET SCan_enable Switching Slow | Fast | Cycles delay_cycles | {SE_ON_delay_cycles
on_cycles SE_OFF_delay_cycles off_cycles}
Description
Sets the default value for scan enable switching.
By default, the BIST controller does not use delay cycles (bist_clk cycles where all the core
clocks are suppressed) in order to switch the scan enable signal. You can activate the slow scan
enable switching functionality by setting the appropriate bit in the BIST controller.
Alternatively, you can specify switching the scan enable signal after a certain number of the
delay cycles.
Arguments
• Slow
A required literal specifying that the default behavior of the BIST controller is to use extra
bist_clk cycles (with all core clocks switched off) to create a timing window for switching
the scan enable on and off.
• Fast
A required literal specifying that the default behavior of the BIST controller is to switch the
scan enable after the negative edge of the last shift cycle. This is the default.
• Cycles delay_cycles
An optional switch and integer pair specifying that the generated test bench and vectors
explicitly load the scan enable control register with the value of cycles in bits 0 to 3 and 4 to
7. This configures the hardware to generate the specified number of delay cycles for both
scan enable transitions. You must specify cycle using an integer between 0 (zero) and 15.
See “Using Delay Cycles for Scan Enable Transition” in the LBISTArchitect Process Guide
for additional information on delay cycles.
• SE_ON_delay_cycles on_cycles SE_OFF_delay_cycles off_cycles
An optional switch and integer quadruplet specifying that the generated test bench and
vectors explicitly load the scan enable control register with the value of on_cycles in bits 0
to 3 and the value of off_cycles in bits 4 to 7. This configures the hardware to generate
on_cycles delay cycles during the scan enable on transition, and off_cycles delay cycles
during the scan enable off transition. You must specify both on_cycles and off_cycles, and
you must these values using integers between 0 (zero) and 15.
See “Using Delay Cycles for Scan Enable Transition” in the LBISTArchitect Process Guide
for additional information on delay cycles.

LBISTArchitect Reference Manual, v2017.3 483

September 2017
BIST Controller Command Dictionary
Set Scan_enable Switching

Related Commands
Command Summary

484 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Shift_rate Divisor

Set Shift_rate Divisor

Usage
SET SHift_rate Divisor shift_rate
Description
Defines the rate to drive the scan chains in relation to the bist_clk signal.
The BIST controller includes the ability to shift scan chains at a fraction of the bist_clk rate. The
default behavior is to shift at the full bist_clk rate. You can adjust the shift rate at run time using
the control interface. The default shift rate that is selected whenever the controller is reset can
also be set using the Set Shift_rate Divisor command.

Arguments
• shift_rate
A literal that specifies the shift rate of the bist_clk signal. The literal, shift_rate, must be
between 1 and 32.
The shift_rate values for 2 through 8 are as follows:
2 —Specifies to reduce the shift rate by a factor of two, which means that the scan
chains will be driven at 1/2 the bist_clk rate.
3 — Specifies to reduce the shift rate by a factor of three, which means that the scan
chains will be driven at 1/3 the bist_clk rate.
4 — Specifies to reduce the shift rate by a factor of four, which means that the scan
chains will be driven at 1/4 the bist_clk rate.
5 — Specifies to reduce the shift rate by a factor of five, which means that the scan
chains will be driven at 1/5 the bist_clk rate.
6 — Specifies to reduce the shift rate by a factor of six, which means that the scan chains
will be driven at 1/6 the bist_clk rate.
7 — Specifies to reduce the shift rate by a factor of seven, which means that the scan
chains will be driven at 1/7 the bist_clk rate.
8 — Specifies to reduce the shift rate by a factor of eight, which means that the scan
chains will be driven at 1/8 the bist_clk rate.
Related Commands
Add Capture Window Set Capture Waveform
Delete Capture Window Set Lbist Controller
Report Capture Window

Command Summary

LBISTArchitect Reference Manual, v2017.3 485

September 2017
BIST Controller Command Dictionary
Set Testpoint Parameters

Set Testpoint Parameters

Usage
SET TEstpoint Parameters [-Method {None | {Multi_phase [-POrts port_name…] [-PHases
integer]}}]
Description
Defines parameters for controlling test points using the multiphase test point process.
Note: You do not need to issue this command if you plan on using a manual test point insertion
process.
The Set Testpoint Parameters command specifies whether or not to use Multiphase Test Point
Insertion (MTPI) to select control test points and sets parameters for MTPI if you use it. The
BIST Controller phase of LBISTArchitect does not insert the test point circuitry; however, it
does insert and connect the decoder circuitry into the BIST controller, based on the phases and
ports you specify.
Arguments
• -Method None | Multi_phase
An optional switch and literal pair that determines whether to use MTPI for test point
control. The following lists the options available:
None — A literal specifying that the BIST Controller phase will not synthesize phase
control circuitry for control test points. This is the default upon invocation of
LBISTArchitect.
Multi_phase — A literal specifying that you used the multiphase-based technique to
calculate, select, and insert the test points in the BIST-Ready phase and that the BIST
Controller phase will synthesize phase control circuitry for control test points.
• -POrts port_name
An optional switch and repeatable string that you can use with the Multi_phase literal to
name the ports that you want LBISTArchitect to use for the multiphase test point control
processes. The first port you specify controls the phase 1 test points (phase 0 is not used
here). The second port you specify controls the phase 2 control points, and so on. The
number of ports you specify must be one less than the number of phases you specify. The
default port names are “phase_cntlN”, where N is an integer.
• -PHases integer
An optional switch and integer pair that you can use with the Multi_phase literal to represent
the number of phases you want the test point insertion process to use. The integer argument
must be a power of 2 (such as, 2, 4, 8, 16, 32, and so on). You would typically use two or
four phases. The default is 2.
LBISTArchitect numbers the phases beginning with 0. Thus, when you specify 4 phases, the
tool considers these to be phases 0-3.

486 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Set Testpoint Parameters

If you also set the number of phases in the Setup Test_point Identification command in the
BIST-Ready phase of LBISTArchitect, the two numbers must match.
Related Commands
Set Lbist Controller

Command Summary

LBISTArchitect Reference Manual, v2017.3 487

September 2017
BIST Controller Command Dictionary
Setup File Naming

Setup File Naming

Usage
SETup FIle Naming [-BIst_model filename] [-BSDA_In filename] [-BSDA_Dofile filename]
[-BSDA_Sequence filename] [-BSDA_Testbench filename] [-BSDA_Vectors filename]
[-Faultsim_dofile filename] [-CORE_Faultsim_dofile filename] [-FLat_model filename]
[-TOPUP_Atpg_dofile filename] [-TOPUP_Faultfile filename]
[-TESTBench filename] [-TEST_Procedure filename]
[-CORE_Test_procedure filename] [-TOPUP_Test_procedure filename]
[-SYnthesis_script filename]
[-Wgl_test_vector filename] [-STil_test_vector filename]
[-Diagnostic_dofile filename]
[-TRANS_CORE_FSIM_Dofile filename]
[-TRANS_FSIM_Dofile filename]
[-TRANS_CORE_FSIM_Testproc filename]
[-TRANS_FSIM_Testproc filename]
[-Patterns filename] [-Lfsr_trace filename]
[-SHift_mode_sdc filename]
[-CApture_mode_sdc filename]
[-BYpass_mode_sdc filename]
Description
Explicitly defines the filenames for one or more saved output files.
Sometimes the default filenames produce a different format than one that is most useful to you.
You can use the Setup File Naming command to explicitly define the filename for any of the
saved output files. This prevents you from having to rename your files to fit your tool’s specific
requirements.
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.

Arguments
• -BIst_model filename
An optional switch and string pair specifying the name of the RTL file that LBISTArchitect
writes when you issue the Save BIST command.
By default, LBISTArchitect produces the following file when you issue the Save BIST
command: “entity_bist.suffix”. If the invocation file does not have a suffix, the Save BIST
command adds the .v suffix (for Verilog) or the .vhd suffix (for VHDL).
• -BSDA_In filename
An optional switch and string pair specifying the BSDArchitect™ input filename that
LBISTArchitect writes when you issue the Save BIST command.

488 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Setup File Naming

By default, LBISTArchitect names the BSDArchitect input file “entity_bsda_in.suffix.”

• -BSDA_Dofile filename
An optional switch and string pair specifying the BSDArchitect dofile name that
LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the BSDArchitect dofile “entity_bsda.do”.
• -BSDA_Sequence filename
An optional switch and string pair specifying the name of the BSDArchitect test sequence
file that LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the BSDArchitect test sequence file
“entity_lbist_bscan.test_seq”.
• -BSDA_Testbench filename
An optional switch and string pair specifying the name of the test bench file that is passed
into BSDArchitect to be used in conjunction with the “entity_bsda.do” file.
By default, LBISTArchitect names the BSDArchitect test bench
“entity_lbist_bscan_tb.suffix”.
• -BSDA_Vectors filename
An optional switch and string pair specifying the name of the test vector file that is passed
into BSDArchitect to be used in conjunction with the “entity_bsda.do” file.
By default, LBISTArchitect names the BSDArchitect test vector file
“entity_lbist_bscan.wgl”.
• -Faultsim_dofile filename
An optional switch and string pair specifying the fault simulation dofile name that
LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the fault simulation dofile “entity_faultsim.do”.
• -CORE_Faultsim_dofile filename
An optional switch and string pair specifying the core-level fault simulation dofile name that
LBISTArchitect writes when you issue the Save BIST command. This dofile creates bit
accurate fault simulation on the core design without the logic synthesis prerequisite.
By default, LBISTArchitect names the core-level fault simulation dofile
“entity_core_faultsim.do”.
• -FLat_model filename
An optional switch and string pair specifying the filename argument of the Save Flattened
Model command that LBISTArchitect automatically places in
the”design_name_core_faultsim.do”, which by default is named“entity.flat”.
You can use this switch to change the default filename value that LBISTArchitect writes to
the dofile. That way, that during the fault simulation phase, LBISTArchitect will save the
flattened model to the name you specify here.

LBISTArchitect Reference Manual, v2017.3 489

September 2017
BIST Controller Command Dictionary
Setup File Naming

Note
The flattened model is intended for use by the Tessent Diagnosis tool in the
LBISTArchitect diagnostics flow.

• -TOPUP_Atpg_dofile filename
An optional switch and string pair specifying the topup ATPG dofile name that
LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the topup ATPG dofile “entity_topup_atpg.do”.
• -TOPUP_Faultfile filename
An optional switch and string pair specifying the file in which faults targeted for topup
ATPG are to be stored.
By default, LBISTArchitect names the topup ATPG fault simulation driver
“entity_topup_atpg_faults”.
• -TESTBench filename
An optional switch and string pair specifying the simulation test bench name that
LBISTArchitect writes when you issue the Save BIST command. This file is written out
only in the stand-alone mode of logic BIST controller.
By default, LBISTArchitect names the simulation test bench “entity_tb.suffix”. If the
invocation file does not have a suffix, the Save BIST command adds the .v suffix (for
Verilog) or the .vhd suffix (for VHDL).
• -TEST_Procedure filename
An optional switch and string pair specifying the test procedure name that LBISTArchitect
writes when you issue the Save BIST command.
By default, LBISTArchitect names the test procedure “entity_bist.testproc.”.
• -CORE_Test_procedure filename
An optional switch and string pair specifying the core-level test procedure name that
LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the test procedure “entity_bist.ctestproc”.
• -TOPUP_Test_procedure filename
An optional switch and string pair specifying the topup ATPG test procedure name that
LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the test procedure “entity_topup.testproc”.
• -SYnthesis_script filename
An optional switch and string pair that specifies the Design Compiler synthesis script name
that LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the script “entity_bist_synth.scr”.

490 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Setup File Naming

• -TRANS_CORE_FSIM_Dofile filename
An optional switch and string pair specifying the core-level transition fault simulation dofile
name that LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the core-level fault simulation dofile for transition fault
grading “entity_trans_core_faultsim.do”.
• -TRANS_FSIM_Dofile filename
An optional switch and string pair specifying the top-level fault simulation dofile name for
transition fault grading, which LBISTArchitect writes when you issue the Save BIST
command.
By default, LBISTArchitect names the transition fault simulation dofile
“entity_trans_faultsim.do”.
• -TRANS_CORE_FSIM_Testproc filename
An optional switch and string pair specifying the core-level test procedure name for
transition fault grading, which LBISTArchitect writes when you issue the Save BIST
command.
By default, LBISTArchitect names the test procedure “entity_trans_bist.ctestproc”.
• -TRANS_FSIM_Testproc filename
An optional switch and string pair specifying the top-level test procedure name for transition
fault grading, which LBISTArchitect writes when you issue the Save BIST command.
By default, LBISTArchitect names the test procedure “entity_trans_bist.testproc.”.
• -Patterns filename
An optional switch and string pair specifying the name of the file where LBISTArchitect
automatically writes the patterns at the end of the fault simulation phase, as controlled by
the “entity_core_faultsim.do” file.
By default, LBISTArchitect names the file “entity_bist.pat.gz”.
• -Lfsr_trace filename
An optional switch and string pair specifying the name of the file where LBISTArchitect
automatically writes the LFSR values at the end of the fault simulation phase, as controlled
by the “entity_core_faultsim.do” file. You can use the LFSR trace values to generate custom
test bench programming files using TBGen.
By default, LBISTArchitect names the file”entity_bist.lfsr.trace.gz”.
• -Wgl_test_vector filename
An optional switch and string pair specifying the name of the template file that
LBISTArchitect writes when you issue the Save Bist command. You can use the template
file as a starting point for running the BIST session. You need to edit the template file to
include the correct signature value.
By default, LBISTArchitect names the file”entity_bist.wgl”.

LBISTArchitect Reference Manual, v2017.3 491

September 2017
BIST Controller Command Dictionary
Setup File Naming

• -STil_test_vector filename
An optional switch and string pair specifying the name of the test vector file in STIL format.
By default, LBISTArchitect names the file “entity_bist.stil”.
• -Diagnostic_dofile filename
An optional switch and string pair specifying the name of the diagnostic dofile. By default,
LBISTArchitect names this file “entity_diagnose.do”.
• -SHift_mode_sdc filename
An optional switch and literal pair that specify the name of the timing constraints file to be
generated; this file will be used to verify the operation of the bist controller when it shifts
data through the scan chains. The default file name is <basename>_shift.sd where basename
is replaced by the name of the top level module in the incoming netlist.
• -CApture_mode_sdc filename
An optional switch and literal pair that specify the name of the timing constraints file to be
generated; this file will be used to verify the operation of the bist controller when it
generates the at-speed capture windows. The default file name is <basename>_capture.sdc
where basename is replaced by the name of the top level module in the incoming netlist.
• -BYpass_mode_sdc filename
An optional switch and literal pair that specify the name of the timing constraints file to be
generated; this file will be used to verify the operation of the bist controller when it is in
diagnostics hold mode and the bist_diag_clk signal can be used to shift data through the core
scan chains. The default file name is <basename>_bypass.sdc where basename is replaced
by the name of the top level module in the incoming netlist.
Examples
The following is an LBISTArchitect example that sets the LBISTArchitect run to use the file
names of your own choice, rather than the default names:

setup file naming -bist_model output.vhdl -bsda_dofile bsdafile.do

-faultsim_dofile faultsim.do -topup_faultfile topupfaults
run
save bist -vhdl

The VHDL entity that LBISTArchitect produces as a result of the Save BIST command has the
name, “output.vhdl”, the BSDArchitect command file has the name “bsdafile.do”, the fault
simulation command file has the name “faultsim.do”, and the topup ATPG fault simulation
driver file has the name “topupfaults”.

Related Commands
Save BIST Run
Setup Synthesis Script Setup Sdc Template

Command Summary

492 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Setup Pin Constraints

Setup Pin Constraints

Usage
SETup PIn Constraints None | {{C0 | C1 | CZ | CX}
[-Exclude primary_input_pins…] [-SImulate {ATPG | BIST | ALL}]}
Description
Sets the default pin constraint value for all input pins.
When creating a BIST controller, the Setup Pin Constraints command constrains all input pins
to the specified default value. You use this command to constrain the input during the mode you
specify in order to avoid the inputs being tied to X and propagating to the MISR, thus corrupting
the signature. The value you set is the default that will be present on valid input pins (not clocks
and scan signals), unless overridden by the Add Pin Constraints command.
You can exclude all primary input and bidirectional pins except the following logic BIST
related pins (which you can never constrain):
• clocks
• scan inputs, scan outputs, and scan enables
• multi-phase test points
You use the None literal to remove all default settings defined with this command.
Arguments
• None
A required string that specifies to remove all the current default constraints for all primary
input and bidirectional pins. You must specify this literal or one of the “C” literals. This is
the tool invocation default.
• C0 | C1 | CZ | CX
A literal that specifies the default constant value constraint for the primary_input_pins,
except for any pins excluded by the specified exclude options. You must specify one of
these literals or the None literal. The constraint choices are as follows:
C0 — A literal that specifies application of the constant 0 to the chosen primary input
pins.
C1 — A literal that specifies application of the constant 1 to the chosen primary input
pins.
CZ — A literal that specifies application of the constant Z (high-impedance) to the
chosen primary input pins.
CX — A literal that specifies application of the constant X (unknown) to the chosen
primary input pins.

LBISTArchitect Reference Manual, v2017.3 493

September 2017
BIST Controller Command Dictionary
Setup Pin Constraints

• -Exclude primary_input_pins
An optional switch and repeatable string that specifies to exclude the specified primary
input pins from the setup setting.
• -SImulate {ATPG | BIST | ALL}
Specifies for LBISTArchitect to constrain the pins in the test procedure, test bench, and test
vector files. These signals must be driven with the appropriate values any time a logic BIST
test is active. This may cause problem for board/system test applications.
The ATPG literal specifies for the tool to constrain the pins during ATPG topup pattern
generation, the BIST literal specifies for the tool to constrain the pins in the BIST
simulation, and the ALL literal specifies for the tool to constrain the pins during both ATPG
and BIST.
Examples
The following example defines the default pin constraints for all pins, then adds two additional
pin constraints that override the default:
setup pin constraints c0
add pin constraints kgmt c1
add pin constraints ckgmt c1

Related Commands
Add Pin Constraints Report Pin Constraints
Delete Pin Constraints

Command Summary

494 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Setup Scan Pins

Setup Scan Pins

Usage
SETup SCan Pins {Input | Output} [-INDexed | -Bused] [-Prefix base_name] [-INItial index#]
[-Modifier incr_index#] [-Suffix suffix_name]
Description
Globally sets up parameters for any added scan pins.
The Setup Scan Pins command specifies the index or bus naming conventions for scan-in or
scan-out pins. The Report Environment command displays the names and values that
LBISTArchitect uses for scan-in and scan-out pins. For consistency and automation,
LBISTArchitect also provides this information to the Fault Simulation phase when you save
dofiles at the end the session using Save BIST.
Indexed names are in the form:

base_name + index# + suffix_name

Bused names are in the form:

base_name + [index#]

Arguments
• Input
A literal specifying that LBISTArchitect apply the index or bus format on the scan-in pins.
• Output
A literal specifying that LBISTArchitect apply the index or bus format on the scan-out pins.
• -INDexed
An optional switch specifying that LBISTArchitect apply the index format to the scan-in or
scan-out pin names. This is the default.
• -Bused
An optional switch specifying that LBISTArchitect apply the bus format to the scan-in or
scan-out pin names.
• -Prefix base_name
An optional switch and string pair that specifies the root name of the scan-in
or scan-out pin. The default name is scan_in for input scan pins and scan_out for output scan
pins.
• -INItial index#
An optional switch and integer pair that specifies the initial index value of the scan-in or
scan-out pin name. The default value is 1.

LBISTArchitect Reference Manual, v2017.3 495

September 2017
BIST Controller Command Dictionary
Setup Scan Pins

• -Modifier incr_index#
An optional switch and integer pair specifying the incremental value to add to the index#
when creating additional names with the same base_name. The default is 1.
• -Suffix suffix_name
An optional switch and string pair specifying the name that you want to place after the
index#. LBISTArchitect uses this for indexed naming only. The default is null.
Examples
The following example configures bus names for the scan-in pins and scan-out pins, with the
index number starting at 5 and incrementing by 2 for scan-in pins, and the index number starting
at 4 and incrementing by 2 for scan-out pins:
setup scan pins input -bused -prefix scin -initial 5 -modifier 2
setup scan pins output -bused -prefix scout -initial 4 -modifier 2

Related Commands
Add Scan Pins Save BIST
Connect Iscan Chains
Command Summary

496 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Setup Sdc Template

Setup Sdc Template

Usage
SETup SDc Template [-Register_suffix suffix] [-Q q_pin_name] [-Qn qn_pin_name]
{-Flat | -Hierarchical} [-Vector_delimiter xy]
Arguments
• -Reg_suffix suffix
An optional switch and value pair that specify the suffix LBISTArchitect appends to RTL
register names (in the generated SDC file) when referencing these registers in the gate-level
netlist. The default register suffix is “_reg”. For example, a register named shift_speed in the
RTL would map to a flip-flop named “shift_speed_reg”.
• -Q q_pin_name
An optional switch and value pair that specify the name of the active-high output of the flip-
flop. The default is “Q”. Timing constraints that originate at specific registers in the RTL
must be applied to all outputs of the corresponding flip-flops in the gate-level netlist. This
command specifies the pin name that is appended to the RTL register name when
referencing the active-high output of the flip-flop.
• -Qn qn_pin_name
An optional switch and value pair that specify the name of the active-low output of the flip-
flop. The default is “QN”. This command specifies the pin name that is appended to the
RTL register name when referencing the active-low output of the flip-flop.
• -Flat
Literal that indicates that all hierarchy has been removed from the synthesized netlist. The
generated SDC file refers to hierarchical names as “\a/b/c/counter_reg/Q”.
• -Hierarchical
Literal that indicates that all hierarchy was preserved during synthesis. The generated SDC
file hierarchy refers to the non-hierarchical names as “a/b/c/counter_reg/Q”. This is the
default.
• -Vector_delimiter xy
An optional switch and literal pair that defines the tokens used when mapping multi-bit
registers in the RTL into individual flip-flop instance names in the gate-level netlist. The
default value is brackets, “[]”, which indicates that the synthesized netlist uses standard
Verilog notation to determine the bits of the vector. For example, a 3-bit register in the RTL
specified as “reg [2:0] counter” would be referenced as “counter_reg[0]/Q”,
“counter_reg[1]/Q”, and “counter_reg[2]/Q” in the generated SDC file.
Description
Enables the writing of static timing analysis files in a format compatible with the Synopsys
PrimeTime tool.

LBISTArchitect Reference Manual, v2017.3 497

September 2017
BIST Controller Command Dictionary
Setup Sdc Template

This command triggers the writing of static timing analysis files used to verify the BIST
controller. Optional switches control the mapping of hierarchical paths in the RTL to nets in the
synthesized netlist.
LBISTArchitect will not write out any SDC templates unless the Setup Sdc Template command
is issued. You must issue this command prior to the Save Bist command.
LBISTArchitect generates three separate SDC files to verify the following three modes: timing
during shift cycles, timing during capture cycles, and timing during bypass mode (used for
diagnostics).
All generated SDC files contain statements to perform the following functions:
• Define relevant clock signals.
• Define set case analysis statements to sensitize the mode-appropriate clock paths.
• Define default latency and uncertainty for clocks.
• Define input and output delays for BIST control signals.
• Define mode-specific constraints.
• End with an “update_timing' command to process the previously defined information.

Note
The generated SDC files do not include the commands needed to read the design into
PrimeTime.

Example
In the following example, assume the synthesized netlist still uses standard Verilog notation
which means that we could access the least significant bit in the shift_speed register as
“shift_speed_reg[0]/Q”. In this case, the synthesis tool is configured to replace the default
brackets with an ASCII “x” character. The following command causes the register to be
referenced as “shift_speed_regx0x/Q”.

setup sdc template -vector_delimiter xx

Related Topics
Setup File Naming

498 LBISTArchitect Reference Manual, v2017.3

September 2017
 BIST Controller Command Dictionary
Setup Synthesis Script

Setup Synthesis Script

Prerequisites: You must issue this command before issuing the Save BIST command. You must
already have specified—in the Design Compiler initialization files—which technology
libraries to use with Design Compiler.
Usage
SETup SYnthesis Script
Description
Sets the naming for the Design Compiler synthesis script.
This command causes LBISTArchitect (when executing a Save BIST command) to write out a
Design Compiler-specific script (in Tcl format) for synthesizing the BIST controller’s RTL
description and merging it with the core design. By default, LBISTArchitect names the script,
entity_bist_synth.scr, but you can rename the script file using the -Synthesis_script switch in the
Setup File Naming command. The script saves the synthesized, merged output in a file named,
entity_bist_netlist.suffix.
The BIST-Ready phase of LBISTArchitect includes this command (with certain conditions; see
the Write BIST Setup command) as part of the driver file output of the Write BIST Setup
command. If you invoke the BIST Controller Synthesis phase in stand-alone mode, you must
explicitly specify this command.
You use this command in conjunction with the Set Core Netlist command, which specifies both
the BIST-Ready output netlist filename and its language. If you issue only the Setup Synthesis
Script command and not the Set Core Netlist command, LBISTArchitect issues a warning
indicating that the synthesis script was not saved for lack of a core file name. The Set Core
Netlist command obsoletes the previously-available -Core_file switch in the Setup Synthesis
Script command.
For a Verilog flow, this command does not require any arguments. You must issue this
command if you want LBISTArchitect to write out a Design Compiler script.
Related Commands
Save BIST Setup File Naming
Set Core Netlist
Command Summary

LBISTArchitect Reference Manual, v2017.3 499

September 2017
BIST Controller Command Dictionary
System

System
Usage
SYStem os_command
Description
Passes the specified command to the operating system for execution.
The System command passes the specified command to the operating system for execution.
After execution, control returns to the application.
Arguments
• os_command
A required string specifying any legal operating system command.
Examples
To view the contents of the logic_bist.v file, enter:
system vi logic_bist.v

Related Commands
Command Summary

500 LBISTArchitect Reference Manual, v2017.3

September 2017
 Chapter 4
Fault Simulation Command Dictionary

This chapter contains command descriptions for the Fault Simulation phase of LBISTArchitect.
The subsections are named for the command they describe. For quick reference, the commands
appear alphabetically, with each beginning on a separate page.

You invoke the Fault Simulation phase by using the lbistarchitect invocation shell command
with the -fault_simulation switch as described in the Shell Commands chapter.

Command Line Syntax Conventions

This manual uses the following command usage line syntax conventions.

Table 4-1. Conventions for Fault Simulation Command Line Syntax

Convention Example Usage
UPPercase REPort ENvironment Required command letters are in uppercase; in
(substitute product-specific most cases, you may omit lowercase letters when
examples throughout) 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 FAults -All A boldface font indicates a required argument.
[ ] EXIt [-Force] Square brackets enclose optional arguments. Do
not enter the brackets.
Italic DOFile filename An italic font indicates a user-supplied argument.
{ } ADD CEll Library library Braces enclose arguments to show grouping. Do
{{-Model name} | -All} not enter the braces.
| ADD CEll Library library The vertical bar indicates an either/or choice
{{-Model 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.

LBISTArchitect Reference Manual, v2017.3 501

September 2017
Fault Simulation Command Dictionary
Command Summary

Table 4-1. Conventions for Fault Simulation Command Line Syntax

Convention Example Usage
… ADD CLocks off_state An ellipsis follows an argument that may appear
primary_input_pin… more than once. Do not include the ellipsis when
[-Internal] entering commands.

Command Summary
Table 4-2 provides a quick reference for the LBISTArchitect Fault Simulation phase commands
described in this manual.
Table 4-2. Command Summary
Command Description
Add Bist Capture Associates a named capture procedure with a subset of the
BIST patterns.
Add Chain Masks Masks the load, capture, and/or unload values on the
specified scan chains.
Add Clocks Adds clock primary inputs to the clock list.
Add Faults Adds faults into the current fault list.
Add LFSR Connections Connects an external pin to a Linear Feedback Shift
Register (LFSR).
Add LFSR Taps Adds the tap configuration to a Linear Feedback Shift
Register (LFSR).
Add LFSRs Adds LFSRs for use as PRPGs or MISRs.
Add MTPI Controller Creates a MTPI controller and connects it to the primary
inputs.
Add MTPI Output Defines the values to be output by the controller.
Add Nofaults Places nofault settings either on pin pathnames, pin names
of specified instances, or modules.
Add Notest Points Adds circuit points to list for exclusion from testability
insertion.
Add Output Masks Ignores any fault effects that propagate to the primary
output pins you name.
Add Pin Constraints Adds pin constraints to primary input pins that are in input
mode.
Add Pin Equivalences Adds restrictions to primary inputs so that they have equal
or inverted values.
Add Primary Inputs Adds primary inputs.

502 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Command Summary

Table 4-2. Command Summary (cont.)

Command Description
Add Primary Outputs Adds primary outputs.
Add Processors Enables the tool to run multiple processes in parallel on
multiple machines to reduce ATPG runtime.
Add Scan Chains Adds a scan chain to a scan group.
Add Scan Groups Adds a scan chain group to the system.
Add Tied Signals Adds a value to floating signals or pins.
Alias Specifies the shorthand name for a Fault Simulation
command, UNIX command, or existing command alias, or
any combination of the three.
Analyze Control Signals Identifies and optionally defines the primary inputs of
control signals.
Delete Bist Capture Removes the state restrictions from the specified objects.
Delete Chain Masks Removes chain masks from the specified scan chains.
Delete Clocks Removes primary input pins from the clock list.
Delete Faults Removes faults from the current fault list.
Delete LFSR Connections Removes connections between the specified primary pins
and Linear Feedback Shift Registers (LFSRs).
Delete LFSR Taps Removes the tap positions from a Linear Feedback Shift
Register (LFSR).
Delete LFSRs Removes the specified Linear Feedback Shift Registers
(LFSRs).
Delete MTPI Controller Deletes the MTPI controller(s).
Delete MTPI Output Deletes the MTPI controller output definitions.
Delete Nofaults Removes the nofault settings from either the specified pin
or instance/module pathnames.
Delete Notest Points Removes the circuit point that indicates to the tool which
specified pins it cannot use for testability insertion.
Delete Output Masks Removes the masking of the specified primary output pins.
Delete Pin Constraints Removes the pin constraints from the specified primary
input pins.
Delete Pin Equivalences Removes the pin equivalence specifications for the
designated primary input pins.
Delete Primary Inputs Removes the specified primary inputs from the current
netlist.

LBISTArchitect Reference Manual, v2017.3 503

September 2017
Fault Simulation Command Dictionary
Command Summary

Table 4-2. Command Summary (cont.)

Command Description
Delete Primary Outputs Removes the specified primary outputs from the current
netlist.
Delete Processors Removes processor definitions previously specified with
the Add Processors command.

Delete Scan Chains Removes the specified scan chain definitions from the scan
chain list.
Delete Scan Groups Removes the specified scan chain group definitions from
the scan chain group list.
Delete Tied Signals Removes the assigned (tied) value from the specified
floating nets or pins.
Dofile Executes the commands contained within the specified file.
Exit Terminates the application tool program.
Find Design Names Displays design object hierarchical names matched by an
input regular expression.
Flatten Model Creates a primitive gate simulation representation of the
design.
Help Displays the usage syntax and system mode for the
specified command.
History Displays a list of previously-executed commands.
Identify Redundant Faults Identifies faults among current the faults whose redundancy
has not yet been determined.
Load Faults Updates the current fault population to include or exclude
the faults contained in the specified fault file.
Report Bist Capture Displays a list of the currently defined BIST capture
windows.
Report Chain Masks Reports the list of masked scan chains and their associated
unload value.
Report Clocks Displays a list of all the primary input pins currently in the
clock list.
Report Drc Rules Displays either a summary of DRC violations (fails) or
violation occurrence message(s).
Report Environment Displays the current values of all the “set” commands.
Report Failures Displays the failing pattern results.
Report Faults Displays fault information from the current fault list.

504 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Command Summary

Table 4-2. Command Summary (cont.)

Command Description
Report Feedback Paths Displays a textual report of the currently identified
feedback paths.
Report Gates Displays the netlist information and simulation results for
the specified gates and the simulation results for the
specified user-defined ATPG functions.
Report LFSR Connections Displays a list of all the connections between Linear
Feedback Shift Registers (LFSRs) and primary pins.
Report LFSRs Displays a list of definitions for all the current Linear
Feedback Shift Registers (LFSRs).
Report Loops Displays information about circuit loops.
Related Commands Reports the state data related to the MTPI controller(s).
Report Nofaults Displays the nofault settings for the specified pin
pathnames or pin names of instances.
Report Notest Points Displays all the circuit points for which you do not want to
insert controllability and observability.
Report Output Masks Displays a list of the currently masked primary output pins.
Report Pin Constraints Displays the pin constraints of the primary inputs.
Report Pin Equivalences Displays the pin equivalences of the primary inputs.
Report Primary Inputs Displays the specified primary inputs.
Report Primary Outputs Displays the specified primary outputs.
Report Processors Displays information about the current distributed
processing environment.
Report Scan Cells Displays a report on the scan cells that reside in the
specified scan chains.
Report Scan Chains Displays a report on all the current scan chains.
Report Scan Groups Displays a report on all the current scan chain groups.
Run Displays estimates of maximum test coverage possible with
different sequential depth settings.
Report Statistics Displays a detailed report of the design’s simulation
statistics.
Report Tied Signals Displays a list of the tied floating signals and pins.
Report Variables Displays user-defined variables and values.
Report Version Data Displays the current software version information.

LBISTArchitect Reference Manual, v2017.3 505

September 2017
Fault Simulation Command Dictionary
Command Summary

Table 4-2. Command Summary (cont.)

Command Description
Reset Di Faults Re-classifies DI faults to UC.
Run Runs a simulation.
Save Flattened Model Saves the flattened circuit model, the scan trace, and all
DRC-related information to a binary file.
Save History Saves the command line history file to the specified file.
Save Patterns Saves the current test pattern set to a file in the format that
you specify.
Set BIST Chain_test Disables all capture clock activity for the specified number
of patterns in the fault simulation during execution of the
chain test.
Set BIST Debug Sets up a trace of LFSR(s) value during a pattern’s shift
cycles.
Set BIST Trace Turns on the ability to trace PRPG and MISR values after
each BIST pattern.
Set Capture Clock Specifies the capture clock name for pseudorandom pattern
simulation.
Set Contention Check Specifies the conditions of contention checking.
Set Distributed Displays or sets the values of several multiprocessing
variables.
Set Dofile Abort Lets you specify whether the tool aborts or continues dofile
execution if an error condition is detected.
Set Drc Handling Specifies how the tool globally handles design rule
violations.
Set Fault Mode Specifies whether the fault mode is collapsed or
uncollapsed.
Set Fault Type Specifies the fault model that will be used during fault
grading of the BIST patterns.
Set File Compression Controls whether the tools read and write files with .Z or .gz
extensions as compressed files (the default).
Set Gate Level Specifies the hierarchical level of gate reporting and
displaying.
Set Gate Report Specifies additional display information for the Report
Gates command.
Set Gzip Options Specifies GNU gzip options to use with the GNU gzip
command.

506 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Command Summary

Table 4-2. Command Summary (cont.)

Command Description
Set Internal Fault Specifies whether the tool allows faults within or only on
the boundary of library models.
Set LFSR Seed Sets the initial value of a PRPG or a MISR.
Set Logfile Handling Specifies for the tool to direct the transcript information to a
file.
Set Number Shifts Sets the number of shifts for loading or unloading the scan
chains.
Set Pattern Buffer Stores run-time pattern data in temporary files in the
directory specified.
Set Pattern Classification Specifies the order in which to store test patterns.
Set Pattern Source Specifies the source of the patterns for future Run
commands.
Set Pattern Type Specifies the type of pattern(s) used by simulation.
Set Possible Credit Specifies the percentage of credit that the tool assigns
possible-detected faults.
Set Random Patterns Specifies the number of pseudorandom patterns
LBISTArchitect simulates.
Set Screen Display Specifies whether the tool writes the transcript to the
session window.
Set Split Capture_cycle Controls whether the tool updates simulation data between
clock edges.
Set System Mode Specifies the system mode you want the tool to enter.
Setup LFSRs Changes the shift_type and tap_type default setting for the
Add LFSRs and Add LFSR Taps commands.
Setup Pin Constraints Changes the default cycle behavior for non-constrained
primary inputs.
Setup Tied Signals Changes the default value for floating pins and floating nets
which do not have assigned values.
System Passes the specified command to the operating system for
execution.
Update Implication Detections Performs an analysis on the undetected and possibly-
detected faults to see if the tool can classify any of those
faults as detected-by-implication.
Write Faults Writes fault information from the current fault list to a file.

LBISTArchitect Reference Manual, v2017.3 507

September 2017
Fault Simulation Command Dictionary
Command Descriptions

Command Descriptions
The remaining pages in this chapter describe, in alphabetical order, the Fault Simulation phase
commands used in LBISTArchitect. Each command description begins on a new page and
contains a line indicating the supported applications. For ease of use, the command and switch
names are, in most cases, identical to those used in Tessent FastScan.

You can use the line continuation character, “\\’, when application commands extend beyond
the end of a line. The line continuation character improves the readability of dofiles and helps
with the command line entry of multiple-argument commands.

508 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Bist Capture

Add Bist Capture

Scope: All modes
Note
Add Bist Capture command is auto-generated by the BIST controller phase and is not
intended for interactive use; it is documented for reference purposes only.

Usage
ADD BIst Capture capture_procedure_name [start_value stop_value]
Description
Associates a named capture procedure with a subset of the BIST patterns.
Arguments
• capture_procedure_name
A required string that specifies the name of the capture procedure.
• start_value
A required argument that specifies the beginning of a contiguous range for a group of
capture procedures. The tool typically generates the start and stop values in the BIST
controller synthesis phase, and you should not change the values.
• stop_value
A required argument that specifies the end of a contiguous range for a group of capture
procedures. The tool typically generates the start and stop values in the BIST controller
synthesis phase, and you should not change the values.
Related Commands
Delete Bist Capture

LBISTArchitect Reference Manual, v2017.3 509

September 2017
Fault Simulation Command Dictionary
Add Chain Masks

Add Chain Masks

Scope: All modes
Prerequisites: Scan chains must be defined.
Usage
ADD CHain Masks chain_name... [-Cell_constraints {OX|XX|TX}] [-Unload_value {0|1}]
Description
Masks the load and/or unload values on the specified scan chains during BIST simulation.
The Add Chain Masks command allows you to insert custom logic between the scan chain
outputs and the Multiple-Input Shift Register (MISR) allowing you to feed a constant unload
value (either 0 or 1) into the MISR and ignore the actual circuit responses.
Arguments
• chain_name...
Required, repeatable string that specifies a scan chain in the current design.
• -Cell_constraints
Optional switch and literal pair that specifies the cell constraints and observe values for the
masking of the specified scan chain(s). By default, load and capture values are applied, but
the results are not included in the fault observation (OX). Options include:
OX — load and capture values are applied, but the fault observation does not include the
results. Default setting.
XX — load and unload values are not applied, but values are captured normally for all
scan cells in the scan chain for multiple-cycle tests.
TX — all scan cell values are tied as X.
• -Unload_value
Required switch and literal pair that specifies an unload value for the masking of the
specified scan chain(s). If this switch is not specified, an error message is issued. Options
include:
0 — Specifies the unload value is 0.
1 — Specifies the unload value is 1.
Example
The following example does not apply the load values (no controllability) or unload (does not
provide any observability) values but uses all the cells from chain1 during a multi-cycle test.
The external channels use the 0 unload value to calculate the circuit response.
add chain masks chain1 -cell_constraints xx -unload_value 0
Warning: There is no DRC provided to check the reliability of the settings/hardware
described by this command.

510 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Chain Masks

Related Command
Delete Chain Masks Add Scan Chains
Report Chain Masks

LBISTArchitect Reference Manual, v2017.3 511

September 2017
Fault Simulation Command Dictionary
Add Clocks

Add Clocks
Scope: Setup mode
Usage
ADD CLocks off_state primary_input_pin… [-Internal]
Description
Adds clock primary inputs to the clock list.
The Add Clocks command adds scan or non-scan clock pins to the clock list for proper scan
operation. The tool considers any signal to be a clock if it can change the state of a sequential
element, including system clocks, sets, and resets.
Pins that you add to the clock list must have an off–state. The off-state of a clock pin is the value
on the pin which results in the clock inputs of sequential memory elements becoming inactive.
For edge-triggered devices, the off–state is the value on the pin that results in placing their clock
inputs at the initial value of a capturing transition. The tool also considers set and reset lines as
clock lines. You can constrain a clock pin to its off-state in order to suppress its use as a capture
clock during the BIST process. The constrained value must be the same as the clock off-state or
an error occurs. If you add an equivalence to the clock list, the tool adds all of its equivalent pins
to the clock list as well.
Arguments
• off_state
A required literal that specifies the pin value that inactivates the sequential memory
elements. The off_state choices are as follows:
0 — A literal specifying that the off-state value is 0.
1 — A literal specifying that the off-state value is 1.
• primary_input_pin
A required repeatable string that lists the primary input pins that you want to assign as
clocks. The list of primary input pins must all have the same off_state.
• -Internal
An optional switch that specifies the primary_input_pin is an internal pin for ATPG
purposes. See “Using On-Chip PLL Clocks for BIST Capture” in the LBISTArchitect
Process Guide for complete information.
The tool processes this internal pin as a clock primary input. Use this switch to define
internal clock inputs normally driven by on-chip circuitry, such as from PLL output.
When using this switch, then the primary_input_pin must be an internal pin and not an
actual clock primary input pin. When you save patterns, the tool omits this internal clock
input at the top level interface.

512 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Clocks

Examples
The following example adds a clock to the clock list, with an off-state of one:
add scan groups group1 proc.g1
add scan chains chain1 group1 scin1 scout1
add clocks 1 clock1

Related Commands
Analyze Control Signals Report Clocks
Delete Clocks

LBISTArchitect Reference Manual, v2017.3 513

September 2017
Fault Simulation Command Dictionary
Add Faults

Add Faults
Scope: Fault and Good modes
Usage
Stuck/Toggle Faults Usage:
ADD FAults {-All | {object_expression… [-PIN | -INstance]}} [-Stuck_at {01 | 0 | 1}]
{[-CLOCK_Domains {ALL | clock_pathname…} [-NO_EQUivalent_clocks]] |
[-CAPture_procedures {ALL | capture_procedure_name…}]} [-VERbose] [{> | >>}
file_pathname]
Description
Adds faults into the current fault list.
The Add Faults command adds faults to the current fault list, discards all patterns in the current
test pattern set, and sets all faults to undetected (actual category is UC). When you enter the
Setup mode, the tool deletes all faults from the current fault list. Furthermore, if you change the
fault type, the tool deletes all faults.
The tool only adds one instance of any given fault, ignoring any duplicate faults.
Arguments
• -All
A switch that specifies to add all faults on all model, netlist primitive, and top module pins.
The setting of the Set Internal Fault command affects the behavior of this switch. If the Set
Internal Fault command is set to “off” (the default), the switch only adds faults residing on
the boundaries of library cells. If the Set Internal Fault command is set to “on”, the -All
switch adds faults that reside on the inputs and outputs of gates within library cells. For
more information about fault locations, refer to “Fault Locations” in the Scan and ATPG
User’s Manual.
• object_expression
A string representing a list of instances or pins, whose faults the tool adds to the current fault
list. The string supports regular expressions, which may include any number of embedded
asterisk (*) or question mark (?) wildcard characters. The * character matches any sequence
of characters (including none) in a name, and the ? character matches any single character.
Instance pathnames must be ATPG library cell instances. Pin pathnames must be ATPG
library cell instance pins, also referred to as design level pins. If the object expression
specifies a pin within an instance of an ATPG library model, the tool ignores it. By default,
pin pathnames are matched first. If a pin pathname match is not found, the tool next tries to
match instance pathnames. You can force the tool to match only pin pathnames or only
instance pathnames by including the -Pin or -Instance switch after the object_expression.
• -Pin
An optional switch that specifies to use the preceding object expression to match only pin
pathnames; the tool will then add faults for all the pins matched.

514 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Faults

• -Instance
An optional switch that specifies to use the preceding object expression to match only
instance pathnames; the tool will then add faults for all the pins on the instances matched.
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies which stuck-at faults to add to the fault list.
The stuck-at values are as follows:
01 — A literal specifying that the tool add both the “stuck-at-0” and “stuck-at-1” faults.
This is the default.
0 — A literal specifying that the tool add only the “stuck-at-0” faults.
1 — A literal specifying that the tool add only the “stuck-at-1” faults.
• -CLOCK_Domains {ALL | clock_pathname…}
An optional switch and literal or repeatable string pair that specifies a list of clocks and
directs the tool to add only faults that are potentially detectable using any of the specified
clocks (or equivalent clocks). For a transition fault to be potentially detectable, it must be
detectable when the same clock (one of the specified clocks or an equivalent) is used for
launch and capture. Any other type of fault must be detectable when one of the specified
clocks or equivalents is used as the capture clock. The argument choices are as follows:
ALL — A literal that specifies all the clocks in the design.
clock_pathname — A repeatable string that specifies a particular clock.
Be aware that a fault added using this switch might also be detectable by an unspecified
clock.
• -NO_EQUivalent_clocks
An optional switch that prevents the -Clock_domains switch from adding faults in
equivalent clock domains.
• -CAPture_procedures {ALL | capture_procedure_name…}
An optional switch and literal or repeatable string pair that specifies a list of enabled named
capture procedures and directs the tool to add faults that are potentially detectable by any of
the specified procedures. The argument choices are as follows:
ALL — A literal that specifies all enabled named capture procedures.
capture_procedure_name — A repeatable string that specifies a particular enabled
named capture procedure.
• -VERbose
By default when you specify wildcard characters for instance (-INstance) or pin (-PIN)
names, the tool outputs a summary message similar to the following:
// Note: Adding faults for 330 fault sites.

LBISTArchitect Reference Manual, v2017.3 515

September 2017
Fault Simulation Command Dictionary
Add Faults

When you specify the optional -VERbose switch, then the tool outputs the instance or pin
names instead of the summary. You can optionally redirect this output to a file using the >
or >> redirection operators.
If you use actual instance or pin names instead of wildcards, then this switch has no effect.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example adds all faults to the circuit so that you can run the fault simulation:
set system mode fault
add faults -all
run

Related Commands
Delete Faults Set Fault Mode
Load Faults Write Faults
Report Faults

516 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add LFSR Connections

Add LFSR Connections

Scope: Setup mode
Usage
ADD LFsr Connections primary_pin lfsr_name position…
Description
Connects an external pin to a Linear Feedback Shift Register (LFSR).
The Add LFSR Connections command connects a core logic pin to an LFSR. You specify this
pin with the primary_pin argument. LFSR bit positions have integer numbers, where 0 indicates
the least significant bit position. LBISTArchitect assumes that the output of the 0 bit position
connects to the input of the highest bit position. If you select multiple bits of a Pseudo-Random
Pattern Generator (PRPG) for the position argument, the tool assumes they are all exclusive-
ORed together to create the value for the pin.
If you determine that multiple primary_pins must connect to a bit position of a Multiple Input
Signature Register (MISR), you must issue a separate Add LFSR Connections command for
each pin. LBISTArchitect assumes the pins are all exclusive-ORed together to create the value
for the next MISR input. LBISTArchitect also assumes that the physical placement of the MISR
connections is after the tapping points as shown in Figure 4-1.

Figure 4-1. MISR placement

SR SR

Tapping Point IN
MISR

You can use the Report LFSRs command to display all the LFSRs with their current values and
tap positions.
Arguments
• primary_pin
A required string that specifies the name of the core logic pin that you want to connect to the
LFSR specified by lfsr_name.
• lfsr_name
A required string that specifies the name of the LFSR to which you want to connect the
primary_pin.

LBISTArchitect Reference Manual, v2017.3 517

September 2017
Fault Simulation Command Dictionary
Add LFSR Connections

• position
A required repeatable integer that specifies the bit positions of the lfsr_name at whose
outputs you want to place connections. A bit position is an integer number, where 0
indicates the least significant bit position. The tool assumes the output of the 0 bit position
connects to the input of the highest bit position.
Examples
The following example connects an LFSR to a scan-in pin and another LFSR to a scan-out pin:
add lfsrs lfsr1 prpg 5 10 -serial -in
add lfsrs misr1 misr 5 15 -both -out
add lfsr taps lfsr1 1 3
add lfsr taps misr1 1 2
add lfsr connections scan_in.1 lfsr1 2
add lfsr connections scan_out.0 misr1 3

Related Commands
Add LFSRs Delete LFSR Connections
Add LFSR Taps Report LFSR Connections

518 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add LFSR Taps

Add LFSR Taps

Scope: Setup mode
Usage
ADD LFsr Taps lfsr_name position…
Description
Adds the tap configuration to a Linear Feedback Shift Register (LFSR).
The Add LFSR Taps command sets the tap configuration of an LFSR. LFSR bit positions have
integer numbers, where 0 indicates the least significant bit position. LBISTArchitect assumes
the output of the 0-bit position connects to the selected tap points and that the 0-bit position
cannot itself be a tap point.
You can use the Report LFSRs command to display all the LFSRs with their current values and
tap positions. You can change the default setting of the tap_type switches by using the Setup
LFSRs command.
Arguments
• lfsr_name
A required string that specifies the name of the LFSR on which you want to place the taps.
• position
A required, repeatable integer that specifies the bit positions of the lfsr_name at whose
outputs you want to place the taps.
Examples
The following example places taps on the newly-added LFSRs:
add lfsrs lfsr1 prpg 5 10 -serial -in
add lfsrs misr1 misr 5 15 -both -out
add lfsr taps lfsr1 1 3
add lfsr taps misr1 1 2

Related Commands
Add LFSRs Report LFSRs
Delete LFSR Taps Setup LFSRs

LBISTArchitect Reference Manual, v2017.3 519

September 2017
Fault Simulation Command Dictionary
Add LFSRs

Add LFSRs
Scope: Setup mode
Usage
ADD LFsrs lfsr_name {Prpg | Misr} length seed [-Both | -Serial | -Parallel] [-Out | -In]
Description
Adds LFSRs for use as PRPGs or MISRs.
The Add LFSRs command defines LFSRs, which LBISTArchitect uses as PRPGs, to create
pseudorandom values for the BIST patterns or as MISRs to compact responses.
You specify the LFSR’s shift technique by using one of the following shift_type switches: -
Both, -Serial, or -Parallel. You specify the placement of the exclusive-OR taps by using one of
the following tap_type switches: -Out or -In. You can change the default setting of the
shift_type and tap_type switches by using the Setup LFSRs command.
Arguments
• lfsr_name
A required string that specifies the name that you want to assign to the LFSR.
• Prpg
A literal that indicates the LFSR functions as a PRPG.
• Misr
A literal that indicates the LFSR functions as a MISR.
• length
A required integer, greater than 1, that specifies the number of bits in the LFSR.
• seed
A required, right-justified, hexadecimal number, greater than 0, that specifies the initial state
of the LFSR.
The following lists the three shift_type switches of which you can choose only one.

• -Both
An optional switch specifying that the LFSR shifts both serially and in parallel. This is the
default unless you change it with the Setup LFSRs command.
• -Serial
An optional switch specifying that the LFSR shifts serially the number of times equal to the
length of the longest scan chain for each scan pattern.
• -Parallel
An optional switch specifying that the LFSR parallel shifts once for each scan pattern.

520 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add LFSRs

The following lists the two tap_type switches of which you can only choose one.

• -Out
An optional switch specifying that the exclusive-OR taps reside outside the register path.
This is the default unless you change it with the Setup LFSRs command.
• -In
An optional switch specifying that the exclusive-OR taps reside in the register path.
Examples
The following example defines an LFSR to be a PRPG and another LFSR to be a MISR:
add lfsrs lfsr1 prpg 5 10 -serial -in
add lfsrs misr1 misr 5 15 -both -out
add lfsr taps lfsr1 1 3
add lfsr taps misr1 1 2

Related Commands
Add LFSR Taps Report LFSRs
Add LFSR Connections Setup LFSRs
Delete LFSRs

LBISTArchitect Reference Manual, v2017.3 521

September 2017
Fault Simulation Command Dictionary
Add MTPI Controller

Add MTPI Controller

Scope: Setup mode
Usage
ADD MTpi Controller controller_name primary_input…
Description
Creates a MTPI controller and connects it to the primary inputs.
The Add MTPI Controller command creates a MTPI controller and connects it to the specified
primary inputs of the design.
Arguments
• controller_name
A string that specifies the name of the MTPI controller to create.
• primary_input
A repeatable string that specifies the names of the primary input of the design. These inputs
may not be clocks, RAM control signals, or LFSRs functioning as PRPGs. The order that
the primary inputs are entered is used to map to the MTPI controller output pins.
Examples
The following example defines one controller with three primary inputs. It also defines the
outputs of the controller.
add mtpi controller controller1 /corecomp/core_i/phase_1 /corecomp/core_i/
phase_ /corecomp/core_i/phase_3
add mtpi output controller1 0 001
add mtpi output controller1 2 010
add mtpi output controller1 9 100
add mtpi output controller1 18 000

Related Commands
Add MTPI Output Related Commands
Delete MTPI Controller
Delete MTPI Output

522 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add MTPI Output

Add MTPI Output

Scope: All modes
Usage
ADD MTpi Output controller_name {cycle_number output_value}… repeat
Description
Defines the values to be output by the controller.
The Add MTPI Output command defines the values to be output by the controller when the
pattern count reaches the specified cycle number.
Arguments
• controller_name
A string that specifies the name of the MTPI controller for which you are defining the
output values.
• cycle_number output_value
A pair of repeatable strings that specify the cycle_number at which the accompanying
output_value is placed at the output. The output_value is a string of binary digits, where the
length of the string must match the number of primary inputs attached to the MTPI
controller. Each bit in the string is mapped to the MTPI controller primary input connection
in the same order as the pins were defined with the Add MTPI Controller command.
• repeat
A required literal that specifies a repeat interval be applied to the remaining Add MTPI
Output statements. By default, the cycle count (described in the cycle_number
output_value argument description) will be the same as the pattern counter. This means that
the Add MTPI Output statements must explicitly cover the entire pattern range that will be
simulated. The repeat option forces a reset of the cycle counter whenever the pattern counter
reaches the repeat value. As an example, this argument could be used to define an MTPI
controller that drives one set of output values for even numbered patterns and a different set
of output values for odd numbered patterns using a repeat interval of 2.
Examples
The following example defines one controller with three primary inputs. It also defines the
outputs of the controller. The output values are defined for cycle number 0, 2, 9, and 18. Notice
that the output value is three digits, which matches the number of primary inputs.
add mtpi controller controller1 /corecomp/core_i/phase_1 /corecomp/core_i/phase_2
/corecomp/core_i/phase_3
add mtpi output controller1 0 001
add mtpi output controller1 2 010
add mtpi output controller1 9 100
add mtpi output controller1 18 000 repeat

LBISTArchitect Reference Manual, v2017.3 523

September 2017
Fault Simulation Command Dictionary
Add MTPI Output

Related Commands
Add MTPI Controller Related Commands
Delete MTPI Controller
Delete MTPI Output

524 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Nofaults

Add Nofaults
Scope: All switches except -Wire are valid in Setup mode only. The -Wire switch is valid in all
modes except Setup.
Usage
ADD NOfaults {{{modulename -Module} | {object_expression… [-PIN | -Instance]}}
[-Stuck_at {01 | 0 | 1}]} [-Keep_boundary]} | -Wire [-VERbose] [{> | >>} file_pathname]
Description
Places nofault settings either on pin pathnames, pin names of specified instances, or modules.
By specifying pathnames of pins, instances of, or modules while in Setup mode, the Add
Nofaults command places a nofault setting either on the specific pins or on boundary and
internal pins of the instances/modules. All added nofault pin pathnames are in the user class. If
you do not specify a stuck-at value, then the tool places a nofault setting on both stuck-at values.
When you add faults with the Add Faults command, after you issue the Add Nofaults command,
the specified pin pathnames or boundary and internal pins of instances/modules cannot be sites
for those added faults. Once you add nofault settings, the tool deletes the flattened model.
Caution
Once you add nofault settings, the tool loses all information added after flattening the
model due to the deletion of the flattened model. Adding nofault settings should be done
prior to flattening the model.

Arguments
• modulename
A repeatable string that specifies the name of a module to which you want to assign nofault
settings. You must include the -Module switch when you specify a module name.
• -Module
A switch that specifies to interpret the modulename argument as a module pathname. All
instances of the module are affected. You can use the asterisk (*) and question mark (?)
wildcards for the modulename argument, and the tool adds the nofault for all matching
modules or library models.
• objection_expression
A string representing a list of pathnames of instances or pins for which you want to assign
nofault settings. The string may include any number of embedded asterisk (*) or question
mark (?) wildcard characters. The asterisk matches any sequence of characters (including
none) in a name, and the question mark matches any single character.
Pin pathnames must be ATPG library cell instance pins, also referred to as design level pins.
If the object expression specifies a pin within an instance of an ATPG library model, the
tool ignores it. By default, pin pathnames are matched first. If a pin pathname match is not
found, the tool next tries to match instance pathnames. You can force the tool to match only

LBISTArchitect Reference Manual, v2017.3 525

September 2017
Fault Simulation Command Dictionary
Add Nofaults

pin pathnames or only instance pathnames by including the -Pin or -Instance switch after the
object_expression.
• -PIN
An optional switch that specifies to use the preceding object expression to match only pin
pathnames; the tool will then assign nofault settings to all the pins matched.
• -Instance
An optional switch that specifies to use the preceding object expression to match only
instance pathnames; the tool will then assign nofault settings to all boundary and internal
pins of the instances matched (unless you use the -Keep_boundary switch).
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies to which stuck-at values you want to assign
a nofault setting. The choices for stuck-at values are as follows:
01 — A literal that specifies the placement of a nofault setting on both the “stuck-at-0”
and “stuck-at-1” faults. This is the default.
0 — A literal that specifies the placement of a nofault setting only on the “stuck-at-0”
faults.
1 — A literal that specifies the placement of a nofault setting on the “stuck-at-1” faults.
• -Keep_boundary
An optional switch that specifies to apply nofault settings to the inside of the specified
instance/module, but allow faults at the boundary pins of these instances/modules. This
option does not apply to nofaults on pin pathnames.
• -Wire
A required switch that specifies for the tool to no-fault a cone of logic fanning out from a
stem forward into a single wire gate. The tool no-faults the entire cone of logic between the
stem and the wire gate, but not the stem or the output of the wire gate. There must be no
other fanout from this cone of logic. This switch is valid in all modes except Setup.
Note
This switch will affect all qualifying logic cones.

• -VERbose
By default when you specify wildcard characters for instance (-INstance) or pin (-PIN)
names, the tool outputs a summary message similar to the following:
// Note: Adding faults for 330 fault sites.

When you specify the optional -VERbose switch, then the tool outputs the instance or pin
names instead of the summary. You can optionally redirect this output to a file using the >
or >> redirection operators.
If you use actual instance or pin names instead of wildcards, then this switch has no effect.

526 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Nofaults

• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example defines nofault settings to all the pins in the instance, so when you add
all faults to the circuit for a simulation run, the tool will not place faults on the pins of that
instance:
add nofaults i_1006 -instance
set system mode fault
add faults -all
run

The next example places nofault settings on all the design pins within all instances of wired
cone logic, adds all faults to the circuit, and performs a simulation run so that LBISTArchitect
places nofaults on the wired cone logic pins:
set system mode fault
add nofault -wire
add faults -all
run

Related Commands
Delete Nofaults Report Nofaults

LBISTArchitect Reference Manual, v2017.3 527

September 2017
Fault Simulation Command Dictionary
Add Notest Points

Add Notest Points

Scope: Fault and Good modes
Usage
ADD NOtest Points pin_pathname…
Description
Adds circuit points to list for exclusion from testability insertion.
The Add Notest Points command excludes the specified cell output pins from use as
controllability and observability insertion points. If the selected pin is already a control or
observe point, an error occurs when you issue this command. You can use the Report Notest
Points command to display all the pins in this list.
Arguments
• pin_pathname
A required, repeatable string that lists the output pins that you do not want to use for
insertion of controllability and observability.
Examples
The following example specifies output pins that LBISTArchitect cannot use for testability
insertion:
set system mode fault
add notest points i_1006/o i_1008/o i_1009/o

Related Commands
Delete Notest Points Report Notest Points

528 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Output Masks

Add Output Masks

Scope: Setup mode
Usage
ADD OUtput Masks primary_output… | -All
Description
Ignores any fault effects that propagate to the primary output pins you name.
The tool uses primary output pins as the observe points during the fault detection process. When
you mask a primary output pin, you inform the tool to mark that pin as an invalid observation
point during the fault detection process. This command allows you the ability to flag primary
output pins that do not have strobe capability. The tool classifies the faults whose effects only
propagate to that observation point as Atpg_Untestable (AU).
The tool uses this capability to mask C8 (PO connected to a clock line) violations on the
primary outputs. This is necessary for some designs in order to connect the scan chain outputs to
the MISR.
Arguments
• primary_output
A repeatable string that specifies the name of the primary output pin you want to mask.
• -All
A switch that specifies to mask all primary output pins.
Examples
The following example specifies the primary output pins that will not have the strobe capability
on the hardware tester:
add output masks qb1 qb2 qb3

Related Commands
Delete Output Masks Report Output Masks

LBISTArchitect Reference Manual, v2017.3 529

September 2017
Fault Simulation Command Dictionary
Add Pin Constraints

Add Pin Constraints

Scope: Setup mode
Usage
ADD PIn Constraints primary_input_pin… constraint_format
Description
Adds pin constraints to primary input pins that are in input mode.
The Add Pin Constraints command restricts the chosen pins to a specific value during BIST
simulation.
For every regular primary input, for which you do not specify a constraint by using the Add Pin
Constraints command, saving patterns will automatically default to the NR constraint format
except where you use the CRO and CR1 formats.
Note
The NR constraint format is not available from the LBISTArchitect command line
interface.

You can constrain a clock pin to its off-state to prevent its use as a capture clock during BIST
simulation. The constrained value must be the same as the clock off-state or an error occurs.
You may want to use a return format if the pin utilizes clock timing in the test_setup procedure.
You can also constrain a scan-in pin. You cannot constrain an equivalent pin, with the exception
of a simple equivalent pin. If you constrain a primary input to be a constant Z, but it does not
connect to a tri-state net, LBISTArchitect converts the pin value to a constant X;
LBISTArchitect also displays a warning message indicating that it performed the conversion.
Arguments
• primary_input_pin
A required, repeatable string that specifies the primary input pins that you want to constrain.
• constraint_format
An argument that specifies the constant value with which you want to constrain the primary
input pins. The constraint format choices are as follows:
C0 — A literal that specifies application of the constant 0 to the chosen primary input
pins.
C1 — A literal that specifies application of the constant 1 to the chosen primary input
pins.
CZ — A literal that specifies application of the constant Z (high-impedance) to the
chosen primary input pins.
CX — A literal that specifies application of the constant X (unknown) to the chosen
primary input pins.

530 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Pin Constraints

CT0 — A literal that specifies application of the constant TIE0. BIST simulation treats
CT0 as if you had added a tied signal.
CT1 — A literal that specifies application of the constant TIE1. BIST simulation treats
CT1 as if you had added a tied signal.
CR0 — A literal that specifies a constant that returns to 0; LBISTArchitect uses this
constant only when formatting the patterns. BIST simulation treats CR0 as a C0.
CR1 — A literal that specifies a constant that returns to 1; LBISTArchitect uses this
constant only when formatting the patterns. BIST simulation treats CR1 as a C1.
Examples
The following example constrains two primary inputs to be at a constant.
add pin constraints indata2 c1
add pin constraints indata4 c0

Related Commands
Delete Pin Constraints
Report Pin Constraints

LBISTArchitect Reference Manual, v2017.3 531

September 2017
Fault Simulation Command Dictionary
Add Pin Equivalences

Add Pin Equivalences

Scope: Setup mode
Usage
ADD PIn Equivalences reference_pin {equivalent_pin… | {-Invert inverted_pin…}}…
Description
Adds restrictions to primary inputs so that they have equal or inverted values.
The Add Pin Equivalences command specifies that all primary input pins named subsequent to
the reference_pin take on the value (or the inverted value) of the reference_pin. You can specify
both pin equivalences and inversions in one command line by listing all equivalent_pins before
the -Invert switch and all inverted_pins after the -Invert switch.
Constrained pins may not be equivalent pins.
If you are inserting testpoints and want to add new scan cells, you should use the Add Pin
Equivalences command to define equivalent clocks that can be utilized during scan cell
insertion. When you define equivalent clocks using this command, you ensure that the two
clocks are skew-balanced with respect to each other and LBIST can use them interchangeably.

Arguments
• reference_pin
A required string that specifies the name of the primary input pin whose value you want the
tool to use when determining the state value of the other named, primary input pins.
• equivalent_pin
A repeatable string that lists the primary input pins whose values you want to equal the
reference_pin. You must list all equivalent_pins before the -Invert inverted_pin argument.
• -Invert inverted_pin
A switch and repeatable string pair that lists the primary input pins whose values you want
to invert with respect to reference_pin.
Examples
The following example shows the Add Pin Equivalences command.
add pin equivalences indata2 indata3 -invert indata4

It provides the following results:

indata3 is equivalent to indata2
indata4 is inverted with respect to indata2

Related Commands
Add Clock Groups Report Pin Equivalences
Delete Pin Equivalences

532 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Primary Inputs

Add Primary Inputs

Scope: Setup mode
Usage
ADD PRimary Inputs net_pathname… [-Cut | -Internal] [-Module]
Description
Adds primary inputs.
The Add Primary Inputs command adds an additional primary input to each specified net. Once
added, the tool designates them as user-class primary inputs, as opposed to the primary inputs
described in the original netlist, which it designates as system class primary inputs. Use the -Cut
option to disconnect the original drivers of the net so that the added primary input becomes the
only driver to the net. Otherwise, if there are other drivers besides the newly-added primary
input, the tool treats this net as a wired net. You can display the user class, system class, or full
classes of primary inputs using the Report Primary Inputs command.
Arguments
• net_pathname
A required, repeatable string that specifies the pathname of the nets to which you want to
add primary inputs.
• -Cut
An optional switch that specifies disconnection of the original drivers of the net, making the
added primary input the only driver of the net. The design must be flattened prior to using
this option with the Flatten Model command.
• -Internal
An optional switch that specifies net_pathname is an internal net. Like the -Cut switch, this
switch disconnects the original drivers of the net, making the added primary input the only
driver of the net. Unlike primary inputs you add using the -Cut switch, these primary inputs
are not added to the top-level interface when saving patterns. Use this switch to define
internal control signals that originate from internal circuitry.
• -Module
An optional switch that specifies addition of the primary input to the specified nets in all
modules.
Examples
The following example adds two new primary inputs to the circuit and places them in the user
class of primary inputs:
add primary inputs indata2 indata4

LBISTArchitect Reference Manual, v2017.3 533

September 2017
Fault Simulation Command Dictionary
Add Primary Inputs

Related Commands
Delete Primary Inputs
Report Primary Inputs

534 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Primary Outputs

Add Primary Outputs

Scope: Setup mode
Usage
ADD PRimary Outputs net_pathname… [-Internal]
Description
Adds primary outputs.
The Add Primary Outputs command adds an additional primary output to each specified net.
Once added, the tool defines them as user-class primary outputs. The tool defines the primary
outputs described in the original netlist as system class primary outputs. You can display the
user class, system class, or full classes of primary outputs using the Report Primary Outputs
command.
Arguments
• net_pathname
A required, repeatable string that specifies the nets to which you want to add primary
outputs.
• -Internal
An optional switch that specifies net_pathname is an internal net. This switch disconnects
the original drains of the net, making the added primary output a drain of the net. These
primary outputs are not added to the top-level interface when saving patterns. Use this
switch to define internal control signals that originate from internal circuitry.
Examples
The following example adds a new primary output to the circuit and places it in the user class of
primary outputs:
add primary outputs outdata1

Related Commands
Delete Primary Outputs
Report Primary Outputs

LBISTArchitect Reference Manual, v2017.3 535

September 2017
Fault Simulation Command Dictionary
Add Processors

Add Processors
Tools Supported: Tessent FastScan and Tessent TestKompress
Scope: All modes
Usage
ADD PROcessors {hostname[:{cpus | MAXcpu}]}…
[-Filter {Linux | SUnos}]
[-Filter {X86 | X86-64 | SParc}]
Description
Enables the tool to run multiple processes in parallel on multiple machines to reduce runtime.
The Add Processors command enables the tool to use multiple processors simultaneously on
specified host machines when executing distributed commands for fault simulation. Especially
for large designs, running multiple processes in parallel can sometimes reduce runtime
significantly.
Without access to multiple processors, the tool executes as a single master process. When you
make additional processors available with the Add Processors command, there will still be a
single master process, but the tool will start up additional slave processes for parallel execution
and coordinate communication between them.
All distributed commands alert you with a message when the design is being sent to slave
processors. This message may not appear after subsequent commands if the other processors
have already received the design and you have issued no commands in the interim that would
affect the information the other processors received. There is currently a limit of 1024
processors per Add Processors command.

Tip: To stop the command from waiting any longer for requested slave processes not yet
received and proceed with those it has, use the Control-C key sequence.

Note
IPv4 address support differs slightly by platform due to differences in the underlying
system call implementations. These differences may be machine dependent due to
dynamic linking with libraries resident on the host computer.

Arguments
• hostname
A required, repeatable string or literal that specifies a host machine or job scheduler that the
tool may utilize for slave processes.
You can add a host machine of any platform type for which there exists a Mentor Graphics
Tessent software tree with a path corresponding to the tree used by the master process.
The hostname choices are as follows:

536 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Processors

machine_name — A string that specifies a host machine by its network name.

LOCALHOST — A literal that specifies to use the machine you invoked the tool on as
the host machine.
IPaddress — A string that specifies a host machine by its IP address.
LSF — A literal that specifies to use available Load Sharing Function (LSF) host
machines.
SGE — A literal that specifies to use available Sun Grid Engine (SGE) host machines.
GENERIC — A literal that specifies to use a host machine as determined by a custom
job scheduler. This option requires that you first issue a Set Distributed command
with the generic_scheduler argument to inform the tool how to launch the custom job
scheduler.
Note
The use of job schedulers requires certain environment prerequisites to be satisfied before
you invoke the tool. See “Multiprocessing Requirements” in the Scan and ATPG User’s
Manual for more information.

• :{cpus | MAXcpu}
A colon (:) and positive integer or literal pair with which you can optionally specify the
number of processes on the specified host machine or job scheduler to use as slave
processes. You can specify up to 32 processes per host.
If you specify an integer, the tool will use that number of processes.
If using a job scheduler, the tool will use as many processes as the scheduler provides in the
time allotted. The time allotted is determined by the setting of the scheduler_timeout
variable, which you can change using the Set Distributed command. See the
scheduler_timeout variable in Table 2-21 for more information.
If you specify the Maxcpu literal, the tool will automatically determine the number of
processes the host can accommodate (less one if the host must also run the master process)
and use up to that number of processes as slave processes. The invocation default for SGE,
LSF and generic is four processes; for the others it is one.
Note
The Maxcpu literal does not apply to grid scheduling or generic scheduling. The tool’s
Maxcpu calculations are based on currently running processes without considering other
slave process specifications on the same command line. If, for example, you use the
Maxcpu literal twice in the same command for a given host, the number of slave
processes on that machine could exceed the number of available processors.

• -Filter
An optional switch that limits the choice of hosts that the specified LSF or SGE job
scheduler can use to just those running a certain operating system and/or utilizing a certain
architecture. This argument has an effect only on LSF and SGE job schedulers.

LBISTArchitect Reference Manual, v2017.3 537

September 2017
Fault Simulation Command Dictionary
Add Processors

• Linux | SUnos
An optional literal that, together with the -Filter switch, limits the choice of hosts that the
specified LSF or SGE job scheduler can use to just those processors running the Linux or
SunOS operating system (OS). Only one OS may be specified per Add Processors
command.
• X86 | X86-64 | SParc
An optional literal that, together with the -Filter switch, limits the choice of hosts that the
specified LSF or SGE job scheduler can use to just those with processors that have an x86,
x86-64, or SPARC architecture. Only one architecture may be specified per Add Processors
command.
Example 1
Assume the tool has been invoked on a machine whose network name is ace. The following
example manually defines two other host machines for multiprocessing, specifying that two
slave processes should be run on one of the machines and one slave process on the other. The
network names of the other machines are “nemo” (with two available processors) and “ahab”
(with two available processors).
add processors nemo:2 ahab:1
// Note: Acquired 1 slave license.
// Note: Spawning processes:
// 32 bit nemo (2 processors) x86
// 32 bit ahab (1 processor) x86
// Note: 3 slaves synchronized (1 sec).

report processors
hosts/processors arch CPU(s) %idle free RAM process size
---------------- ------- ----------- ----- ------------ ------------
ace (master) x86 2 x 2.2 GHz 91% 8601.03 MB 20.07 MB
nemo 1 x86 2 x 2.0 GHz 49% 160.04 MB 18.77 MB
2 18.77 MB
ahab 1 x86 1 x 1.7 GHz 26% 257.35 MB 18.77 MB
master and 3 processors running.

Example 2
The following example spawns two more slave processes on host machine nemo, which is two
more than the number of processors on that machine:
add processors nemo:2
// Note: Now using 4 CPUs on nemo (2 exist).
// Note: Acquired 1 new slave license, for a total of 2.
// Note: Spawning processes:
// 32 bit nemo (2 processors) x86
// Note: 2 slaves synchronized (1 sec).

538 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Processors

Note
You can run more processes on a host machine than the number of available processors
on that machine, but this is not recommended, as not all of the processes can run
concurrently.

Example 3
The following example specifies to distribute the processing load among any two available SGE
processors running Linux:
add processors sge:2 -filter linux
// Note: Acquired 1 slave license.
// Note: Spawning processes:
// 32 bit grid05 (2 processors) x86-64
// Note: 2 slaves synchronized (0 sec).

Related Commands
Delete Processors Run
Report Processors Set Distributed

LBISTArchitect Reference Manual, v2017.3 539

September 2017
Fault Simulation Command Dictionary
Add Scan Chains

Add Scan Chains

Scope: Setup mode
Prerequisites
You must define the scan chain group with the Add Scan Groups command prior to using this
command.
Usage

ADD SCan Chains [-Internal] {chain_name group_name primary_input_pin

primary_output_pin}…
Description
Adds a scan chain to a scan group.
The Add Scan Chains command defines a scan chain that exists in the design. A scan chain
references the name of a scan chain group, which you must define prior to issuing this
command.
You can define multiple scan chains on one command line by repeating the complete sequence
of arguments for each scan chain.
Arguments
• chain_name
A required string that specifies the name of the scan chain you want added to the scan group.
• group_name
A required string that specifies the name of the scan chain group to which you are adding
the scan chain.
• primary_input_pin
A required string that specifies the input pin of the scan chain.
• primary_output_pin
A required string that specifies the output pin of the scan chain.
• -Internal
An optional switch that defines internal scan chains. This switch is intended for use with
LBIST simulation.
Examples
The following example defines two scan chains (chain1 and chain2) that belong to the same
scan group (group1):

540 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Scan Chains

add scan groups group1 scanfile

add scan chains chain1 group1 indata2 testout2
add scan chains chain2 group1 indata4 testout4

Related Commands
Add Scan Groups Report Scan Chains
Delete Scan Chains

LBISTArchitect Reference Manual, v2017.3 541

September 2017
Fault Simulation Command Dictionary
Add Scan Groups

Add Scan Groups

Scope: Setup mode
Usage
ADD SCan Groups {group_name test_procedure_filename}…
Description
Adds a scan chain group to the system.
The Add Scan Groups command defines a scan chain group that contains scan chains for the
design. The procedures defined in test_procedure_filename control the set of scan chains which
make up the scan chain group.
If you specify “dummy” as the group name and provide a test procedure filename, the tool
expects the test procedure file to contain only the seq_transparent and test_setup procedures.
Doing so lets you run BIST simulation without having a scan structure currently in the design.
You can define multiple scan chain groups on one command line by repeating the argument pair
for each scan chain group.
Arguments
• group_name
A required string that specifies the name of the scan chain group that you want to add to the
system.
• test_procedure_filename
A required string that specifies the name of the test procedure file that contains the
information for controlling the scan chains in the specified scan chain group.
Examples
The following example defines a scan chain group, group1, which loads and unloads a set of
scan chains, chain1 and chain2, by using the procedures in the file, scanfile:
add scan groups group1 scanfile
add scan chains chain1 group1 indata2 testout2
add scan chains chain2 group1 indata4 testout4

Related Commands
Add Scan Chains Report Scan Groups
Delete Scan Groups

542 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Add Tied Signals

Add Tied Signals

Scope: Setup mode
Usage
ADD TIed Signals {0 | 1 | X | Z} floating_object_name… [-Pin]
Description
Adds a value to floating signals or pins.
The Add Tied Signals command assigns a specific value to not-clearly-defined floating signals
or pins. If there are floating signals or pins in the design, a warning appears when you leave the
Setup mode. If you do not assign a specific value, the tool ties the signal or pin values to the
default value. To change the default tied value, use the Setup Tied Signals command.
When you add tied signals or pins, the tool places them into the user class. This includes
instance-based, blackbox tied signals. When the netlist ties signals or pins to a value, the tool
places them into the system class.
Note
The tool will not tie a signal that is connected to I/O pins. This causes a problem if you
are considering UDD as an I/O pin.

Arguments
• 0
A literal that ties the floating nets or pins to logic 0 (low to ground).
• 1
A literal that ties the floating nets or pins to logic 1 (high to voltage source).
• X
A literal that ties the floating nets or pins to unknown.
• Z
A literal that ties the floating nets or pins to high-impedance.
• floating_object_name
A required, repeatable string that specifies the floating nets or pins to which you want to
assign a specific value. The tool assigns the tied value to all floating nets or pins in all
modules that have the names that you specify.
If you do not specify the -Pin option, the tool assumes the name is a net name. If you do
specify the -Pin option, the tool assumes the name is a pin name. If you specify a net
pathname, you cannot use the -Pin option.

LBISTArchitect Reference Manual, v2017.3 543

September 2017
Fault Simulation Command Dictionary
Add Tied Signals

• -Pin
An optional switch specifying that the floating_object_name argument that you provide is a
floating pin name.
Examples
The following example ties all floating signals in the circuit that have the net names vcc and
vdd, to logic 1 (tied to high):
add tied signals 1 vcc vdd

Related Commands
Delete Tied Signals Setup Tied Signals
Report Tied Signals

544 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Alias

Alias
Scope: All modes
Usage
ALIas [synonym {!unix_command; | tool_command; | alias_synonym;}…]
Description
Specifies the shorthand name for a Fault Simulation command, UNIX command, or existing
command alias, or any combination of the three.
Issuing the Alias command with no arguments will list 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.
In addition, you can parameterize the command strings 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 arguments, which are substituted into the command prior
to its execution.
You can also provide an optional file, .lbistarchitect_startup, that contains commands that you
want executed prior to any other batch or interactive commands. The primary purpose of this
file is to execute Alias commands that tailor the tool’s command language to your needs. Upon
invocation, the tool searches for the startup file in the following locations and order of
precedence:
1. The directory pointed to by the MGCDFT_STARTUP environment variable
2. The local invocation directory
3. Your home directory
The first startup file the tool encounters is the only one it executes if you have startup files in
multiple locations. If the tool does not locate a tool_specific startup file, it searches the same
locations for the generic startup file, .mgcdft_startup.
Arguments
• synonym {!unix_command; | tool_command; | alias_synonym;}
An optional string with a repeatable string that specifies a shorthand name, synonym, for the
specified UNIX or tool command or for a previously-defined alias synonym (which has the
effect of a command). Repeated commands must be separated by semicolons.
!unix_command — An optional, repeatable string that consists of any well-formed
UNIX command, with its arguments, or a UNIX script. You must precede this string
with an exclamation point to differentiate it from a tool-specific command.
tool_command — An optional, repeatable string that consists of any well-formed Fault
Simulation command and its arguments.

LBISTArchitect Reference Manual, v2017.3 545

September 2017
Fault Simulation Command Dictionary
Alias

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 Netscape 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 any “lckup” names:
alias findlockup !find . -name \*.v -print -exec egrep lckup {} \;

You could then use that new command within another Alias command that writes out the
current design:
alias findit write netlist -verilog temp.v -replace; findlockup

Related Commands
System Dofile
History
Command Summary

546 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Analyze Control Signals

Analyze Control Signals

Scope: All modes
Usage
ANAlyze COntrol Signals [-Report_only | -Auto_fix] [-Verbose]
Description
Identifies and optionally defines the primary inputs of control signals.
The Analyze Control Signals command identifies each control signal (clocks, set, reset, write-
control, read-control, and so on) of every sequential element (DFF, latch, RAM, ROM, etc.) and
optionally defines its primary input as a control signal. The purpose of analyzing the control
signals is to identify the primary input that needs to be defined as a clock, read-control, or write-
control. This analysis also considers pin constraints, but only traces through simple
combinational gates.

If the -Verbose option is specified, the tool issues messages that indicate why certain control
signals are not reported. At the end of the analysis, statistical information displays, listing the
number of primary inputs identified as control signals, their types, and additional information.

If the -Auto_fix option is specified, all identified primary inputs of control signals are
automatically defined. For example, when a clock is identified, an implicit Add Clocks
command is performed to define the primary input. By default, all control signals are only
reported.

Note
This command will perform the flattening process automatically, if executed prior to
performing flattening.

Arguments
• -Report_only
An optional literal that specifies to only identify control signals (does not define the primary
inputs as control signals). This is the invocation default.
• -Auto_fix
An optional literal that specifies to define the primary inputs of all identified control signals
as control signals. For example, when a clock is identified, an implicit Add Clocks
command is performed to define the primary input.
• -Verbose
An optional literal that specifies to display information on control signals (whether they are
identified or not, and why) while the analysis is performed.

LBISTArchitect Reference Manual, v2017.3 547

September 2017
Fault Simulation Command Dictionary
Analyze Control Signals

Examples
The following example analyzes the control signals, then only provides a verbose report on the
control signals in the design. After examining the transcript, you can then perform another
analysis of the control signals to add them.
analyze control signals -verbose
// command: analyze control signals -reports_only -verbose
------------------------------------------------------------------------
// Begin control signals identification analysis.
------------------------------------------------------------------------
// Warning: Clock line of ‘/cc01/tim_cc1/add1/post_latch_29/WRITEB_reg/r/
(7352)’ is uncontrolledat ‘/IT12 (4)’.
...
...
...
// Identified 2 clock control primary inputs.
// /IT23 (5) with off-state = 0.
// /IT12 (4) with off-state = 0.
// Identified 0 set control primary inputs.
// Identified 1 reset control primary inputs.
// /IRST (1) with off-state = 0.
// Identified 0 read control primary inputs.
// Identified 0 write control primary inputs.
-----------------------------------------------------------------------
// Total number of internal lines is 105 (35 clocks, 35 sets , 35 resets,
0 reads, 0 writes).
// Total number of controlled internal lines is 25 (17 clocks, 0 sets ,
8 resets, 0 reads, 0 writes).
// Total number of uncontrolled internal lines is 80 (18 clocks, 35 sets,
27 resets, 0 reads, 0 writes).
// Total number of added primary input controls 0 (0 clocks, 0 sets ,
0 resets, 0 reads, 0 writes).
-----------------------------------------------------------------------

analyze control signals -auto_fix

Related Commands
Add Clocks Report Clocks

548 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Bist Capture

Delete Bist Capture

Scope: All modes
Usage
DELETE BIst Capture capture_window_name | -All
Description
Deletes a named capture window.
Arguments
• capture_window_name
A required string that specifies the name of the capture window.
• -All
A switch that removes all defined capture windows.
Related Commands
Add Bist Capture

LBISTArchitect Reference Manual, v2017.3 549

September 2017
Fault Simulation Command Dictionary
Delete Chain Masks

Delete Chain Masks

Scope: All modes
Prerequisites: You can only delete chain masks added with the Add Chain Masks command.
Usage
DELete CHain Masks chain_name... | -All
Description
Removes chain masks from the specified scan chains.
The Delete Chain Masks command deletes chain masks from the specified scan chains defined
with the Add Chain Masks command. You can delete the definitions of specific chain name or
all chains.
Arguments
• chain_name
A repeatable string that specifies the names of the chain mask definitions that you want to
delete.
• -All
A switch that deletes all chain mask definitions.
Example
The following example defines two chain masks then deletes all chain masks:
add chain mask chain2 chain3
delete chain masks -all

Related Commands
Add Chain Masks Report Chain Masks

550 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Clocks

Delete Clocks
Scope: Setup mode
Prerequisites
You can only delete primary input pin names added with the Add Clocks command.
Usage
DELete CLocks primary_input_pin [-Internal]... | -All
Description
Removes primary input pins from the clock list.
The Delete Clocks command deletes primary input pins from the clock list. If you delete an
equivalence pin, the command also deletes all of the equivalent pins from the clock list.
Arguments
• primary_input_pin
A repeatable string that specifies the primary input pins that you want to delete from the
clock list.
• -Internal
An optional argument that deletes the internal clocks added with the Add Clocks ... -Internal
command. If you omit this arguement, then the tool only deletes the PI clocks.
• -All
A switch that deletes all pins from the clock list.
Examples
The following example deletes an incorrectly added clock from the clock list:
add clocks 1 clock1
add clocks 1 clock2
delete clocks clock1

Related Commands
Add Clocks Report Clocks

LBISTArchitect Reference Manual, v2017.3 551

September 2017
Fault Simulation Command Dictionary
Delete Faults

Delete Faults
Scope: Fault and Good modes
Prerequisites
You must add faults with the Add Faults or Load Faults commands before you can delete them.
Usage
Stuck/Toggle Faults Usage:
DELete FAults {-All | -Class class_type… | object_expression… [-PIn | -Instance]}
[-Stuck_at [01 | 0 | 1]] {[-CLOCK_Domains {ALL | clock_pathname…}
[-NO_EQUivalent_clocks]] | [-CAPture_procedures {ALL |
capture_procedure_name…}]}} | {[-SCAN_Enable] [-CLOCK_Cones] [-IO]
[-ASYnchronous_controls]} [-VERbose] [{> | >>} file_pathname]
Description
Removes faults from the current fault list.
The Delete Faults command deletes faults from the fault list added using the Add Faults
command or the Load Faults command.
You can optionally specify faults with a specific stuck-at value. If you do not specify a stuck-at
value when deleting a fault, the command deletes both the “stuck-at-0” and “stuck-at-1” faults
from the fault list.
When you issue this command, the tool discards all patterns in the current test pattern. To save
the current test patterns you must explicitly save them with the Save Patterns command prior to
issuing the Delete Faults command.
Arguments
• -All
A switch that deletes all faults in the current fault list.
• object_expression
A string representing a list of instances or pins, whose faults the tool should delete from the
current fault list. The string may include any number of embedded asterisk (*) or question
mark (?) wildcard characters. The asterisk matches any sequence of characters (including
none) in a name, and the question mark matches any single character.
Instance pathnames must be ATPG library cell instances. Pin pathnames must be ATPG
library cell instance pins, also referred to as design level pins. If the object expression
specifies a pin within an instance of an ATPG library model, the tool ignores it. By default,
pin pathnames are matched first. If a pin pathname match is not found, the tool next tries to
match instance pathnames. You can force the tool to match only pin pathnames or only
instance pathnames by including the -Pin or -Instance switch after the object_expression.

552 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Faults

• -Pin
An optional switch that specifies to use the preceding object expression to match only pin
pathnames; the tool will then delete faults for all the pins matched.
• -Instance
An optional switch that specifies to use the preceding object expression to match only
instance pathnames; the tool will then delete faults for all the pins on the instances matched.
• -Class class_type
An optional switch and repeatable literal pair that specifies to delete one or more classes of
faults. The class_type argument can be either a fault class code or a fault class name.
• -Stuck_at 01 | 1 | 0
An optional switch and literal pair that specifies the stuck-at values which you want to
delete. The valid stuck-at literals are as follows:
01 — A literal that deletes both of the “stuck-at-0” and “stuck-at-1” faults. This is the
default.
0 — A literal that only deletes the “stuck-at-0” faults.
1 — A literal that only deletes the “stuck-at-1” faults.
• -CLOCK_Domains {ALL | clock_pathname…}
An optional switch and literal or repeatable string pair that specifies a list of clocks and
directs the tool to delete faults that are potentially detectable using any of the specified
clocks (or equivalent clocks). For a transition fault to be potentially detectable, it must be
detectable when the same clock (one of the specified clocks or an equivalent) is used for
launch and capture. Any other type of fault must be detectable when one of the specified
clocks or equivalents is used as the capture clock. The argument choices are as follows:
ALL — A literal that specifies all the clocks in the design.
clock_pathname — A repeatable string that specifies a particular clock.
Be aware that a fault potentially detectable by a clock you specify with this switch will be
deleted even if it might also be detectable by an unspecified clock.
• -NO_EQUivalent_clocks
An optional switch that prevents the -Clock_domains switch from deleting faults in
equivalent clock domains.
• -CAPture_procedures {ALL | capture_procedure_name…}
An optional switch and literal or repeatable string pair that specifies a list of enabled named
capture procedures and directs the tool to delete faults that are potentially detectable by any
of the specified procedures. The argument choices are as follows:
ALL — A literal that specifies all enabled named capture procedures.
capture_procedure_name — A repeatable string that specifies a particular enabled
named capture procedure.

LBISTArchitect Reference Manual, v2017.3 553

September 2017
Fault Simulation Command Dictionary
Delete Faults

• -SCAN_Enable
An optional switch that specifies to delete faults that only fan out to the select lines of
multiplexers in the scan path. For this switch, a multiplexer is either a MUX simulation
primitive or a nonprimitive type multiplexer composed of AND and OR gates. Basically,
this switch deletes all faults that are in the fanin cone of local scan enable signals and are
dominated by them.
• -CLOCK_Cones
An optional switch that specifies to delete all faults that only fan out to clock ports,
Set/Reset ports or Read/Write control ports of memory elements, including RAM and
ROM. This switch considers any memory elements, not just scan cells.
• -IO
An optional switch that specifies to delete faults that are:
• Only controlled by PIs — To be acted on by the -IO switch, a PI either must not be
defined as a clock or, if defined as clock (or read/write control), must be constrained
off during capture.
• Only observed by POs
• -ASYnchronous_controls
An optional switch that specifies to delete all faults that only fan out to Set/Reset ports of
state elements and RAMs. Notice that this switch applies to a subset of the faults the
-CLOCK_Cones switch deletes.
• -VERbose
By default when you specify wildcard characters for instance (-INstance) or pin (-PIN)
names, the tool outputs a summary message similar to the following:
// Note: Adding faults for 330 fault sites.

When you specify the optional -VERbose switch, then the tool outputs the instance or pin
names instead of the summary. You can optionally redirect this output to a file using the >
or >> redirection operators.
If you use actual instance or pin names instead of wildcards, then this switch has no effect.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example deletes a stuck-at-0 fault from the current fault list after adding all the
faults to the circuit, but before performing a BIST simulation:

554 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Faults

set system mode fault

add faults -all
delete faults i_1006/i1 -stuck_at 0
run

Related Commands
Add Faults Report Faults
Load Faults Set Fault Mode
Save Patterns Write Faults

LBISTArchitect Reference Manual, v2017.3 555

September 2017
Fault Simulation Command Dictionary
Delete LFSR Connections

Delete LFSR Connections

Scope: Setup mode
Prerequisites
You must define LFSR connections with the Add LFSR Connections command before you can
delete them.
Usage
DELete LFsr Connections primary_pin… | -All
Description
Removes connections between the specified primary pins and Linear Feedback Shift Registers
(LFSRs).
The Delete LFSR Connections command deletes the connections between the LFSRs and the
primary pins specified with the Add LFSR Connections command. You can use the Report
LFSR Connections command to display all the current connections between LFSRs and
primary pins.
Arguments
• primary_pin
A repeatable string that lists the primary pins whose connections to LFSRs you want to
delete.
• -All
A switch that deletes all of the connections between LFSRs and primary pins.
Examples
The following example changes the definition of an LFSR connection by deleting it and then re-
adding it with a new definition:
add lfsrs lfsr1 prpg 5 15 -serial -in
add lfsr taps lfsr1 2 3 4
add lfsr connections scan_in.1 lfsr1 2
delete lfsr connections scan_in.1
add lfsr connections scan_in.2 lfsr1 2

Related Commands
Add LFSR Connections Report LFSR Connections

556 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete LFSR Taps

Delete LFSR Taps

Scope: Setup mode
Prerequisites
You must add LFSR taps with the Add LFSR Taps command before you can delete them.
Usage
DELete LFsr Taps lfsr_name {tap_position… | -All}
Description
Removes the tap positions from a Linear Feedback Shift Register (LFSR).
The Delete LFSR Taps command deletes the specified LFSR tap positions added with the Add
LFSR Taps command. To display the current tap positions of all defined LFSRs, use the Report
LFSRs command.
Arguments
• lfsr_name
A string that specifies the reference name of the LFSR whose tap positions you want to
delete.
• tap_position
A repeatable string that specifies the list of tap positions that you want to delete from the
lfsr_name.
• -All
A switch that deletes all of the tap positions from the lfsr_name.
Examples
The following example changes an LFSR tap position by deleting it and then adding a new tap
position:
add lfsrs lfsr1 prpg 5 15 -serial -in
add lfsrs lfsr2 Prpg 5 13 -serial -in
add lfsr taps lfsr1 2 3 4
add lfsr taps lfsr2 1 3
delete lfsr taps lfsr1 3
add lfsr taps lfsr1 1

Related Commands
Add LFSR Taps Setup LFSRs
Report LFSRs

LBISTArchitect Reference Manual, v2017.3 557

September 2017
Fault Simulation Command Dictionary
Delete LFSRs

Delete LFSRs
Scope: Setup mode
Prerequisites
You must define LFSRs with the Add LFSRs command before you can delete them.
Usage
DELete LFsrs lfsr_name… | -All
Description
Removes the specified Linear Feedback Shift Registers (LFSRs).
The Delete LFSRs command deletes LFSRs defined with the Add LFSRs command. You can
use the Report LFSRs command to display a list of the current LFSRs with their current values
and tap positions. When you delete an LFSR, the tool also deletes all its taps and pin
connections.
Arguments
• lfsr_name
A repeatable string that specifies the reference names of the LFSRs that you want to
remove.
• -All
A switch that deletes all defined LFSRs.
Examples
The following example changes the definition of an LFSR by deleting it and then re-adding it
with a new definition:
add lfsrs lfsr1 prpg 5 15 -serial -in
add lfsrs lfsr2 prpg 5 13 -serial -in
add lfsrs lfsr3 prpg 5 11 -parallel -out
delete lfsrs lfsr3
add lfsrs lfsr3 prpg 5 11 -parallel -in

Related Commands
Add LFSRs Setup LFSRs
Report LFSRs

558 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete MTPI Controller

Delete MTPI Controller

Scope: Setup mode
Prerequisites
This command intended for an LBISTArchitect design flow.
Usage
DELete MTpi Controller controller_name | -All
Description
Deletes the MTPI controller(s).
The Delete MTPI Controller command deletes the specified or all MTPI controllers defined
with the Add MTPI Controller command. All output data associated with the controller is also
deleted.
Arguments
• controller_name
A string that specifies the name of the MTPI controller to delete.
• -All
A switch that specifies to delete all MTPI controllers.
Examples
The following example deletes the “controller1” MPTI controller:
add mtpi controller controller1 /corecomp/core_i/phase_1 /corecomp/core_i/phase_2
/corecomp/core_i/phase_3
delete mtpi controller controller1

Related Commands
Add MTPI Controller Related Commands
Add MTPI Output
Delete MTPI Output

LBISTArchitect Reference Manual, v2017.3 559

September 2017
Fault Simulation Command Dictionary
Delete MTPI Output

Delete MTPI Output

Scope: All modes
Prerequisites
This command intended for an LBISTArchitect design flow.
Usage
DELete MTpi Output -All | {controller_name {-All | cycle_number…}
Description
Deletes the MTPI controller output definitions.
The Delete MTPI Output command deletes the output data definition for the specified or all
MTPI controllers. If you specify an individual controller, you may also specify for which cycle
to delete the output data.
Arguments
• -All
A switch that specifies to delete the output data of all MTPI controllers.
• controller_name {-All | cycle_number…}
A string that specifies the name of the MTPI controller whose output data you want to
delete.
-All —A switch that specifies to delete all output data for the specified MTPI controller.
cycle_number — A repeatable integer that specifies the number of the cycle whose output
data you want to delete.
Examples
The following example adds output data for the controller1 controller, deletes the output data of
the controller for the second and ninth cycles, and then enters new values:
add mtpi output controller1 0 001
add mtpi output controller1 2 010
add mtpi output controller1 9 100
add mtpi output controller1 18 000
delete mtpi output controller1 2 9
add mtpi output controller1 2 100
add mtpi output controller1 9 010

Related Commands
Add MTPI Controller Related Commands
Add MTPI Output
Delete MTPI Controller

560 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Nofaults

Delete Nofaults
Scope: Setup mode
Usage
DELete NOfaults {-All | {modulename -Module} | {object_expression… [-PIN | -Instance]}}
[-Stuck_at {01 | 0 | 1}] [-Class {User | System | Full}] [-VERbose] [{> | >>} file_pathname]
Description
Removes the nofault settings from either the specified pin or instance/module pathnames.
The Delete Nofaults command deletes the nofault settings specified with the Add Nofaults
command.
You can optionally specify nofault settings that have a specific stuck-at value. If you do not
specify a stuck-at value when deleting a nofault setting, the command deletes both the “stuck-
at-0” and “stuck-at-1” nofault settings.
You can also optionally specify nofault settings that have a specific class code: user-defined,
system netlist, or both. If you do not specify a class code, then the command deletes the nofault
setting from the user class.
You can use the Report Nofaults command to display all the current nofault settings.
Arguments
• -All
A switch that deletes all nofault settings.
• modulename
A string that specifies the name of a module from which you want to delete nofault settings.
You must include the -Module switch when you specify a module name.
• -Module
A switch that specifies interpretation of the modulename argument as a module pathname.
All instances of these modules are affected. You can use the asterisk (*) and question mark
(?) wildcards for the modulename argument, and the tool deletes the nofault for all
matching modules or library models.
• objection_expression
A string representing a list of pathnames of instances or pins from which you want to delete
nofault settings. The string may include any number of embedded asterisk (*) or question
mark (?) wildcard characters. The asterisk matches any sequence of characters (including
none) in a name, and the question mark matches any single character.
Pin pathnames must be ATPG library cell instance pins, also referred to as design level pins.
If the object expression specifies a pin within an instance of an ATPG library model, the
tool ignores it. By default, pin pathnames are matched first. If a pin pathname match is not
found, the tool next tries to match instance pathnames. You can force the tool to match only

LBISTArchitect Reference Manual, v2017.3 561

September 2017
Fault Simulation Command Dictionary
Delete Nofaults

pin pathnames or only instance pathnames by including the -Pin or -Instance switch after the
object_expression.
• -Pin
An optional switch that specifies to use the preceding object expression to match only pin
pathnames; the tool will then delete nofault settings from all the pins matched.
• -Instance
An optional switch that specifies to use the preceding object expression to match only
instance pathnames; the tool will then delete nofault settings from all boundary and internal
pins of the instances matched.
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies the stuck-at values which you want to
delete. The valid stuck-at literals are as follows:
01 — A literal that deletes both the “stuck-at-0” and “stuck-at-1” nofault settings. This
is the default.
0 — A literal that deletes the “stuck-at-0” nofault settings.
1 — A literal that deletes the “stuck-at-1” nofault settings.
• -Class User | System | Full
An optional switch and literal pair that specifies the source (or class) of the nofault settings
which you want to delete. The valid literals are as follows:
User — A literal that deletes the user-entered nofault settings. This is the default.
System — A literal that deletes netlist-based nofault settings.
Full — A literal that deletes all the nofault settings in the user and system classes.
• -VERbose
By default when you specify wildcard characters for instance (-INstance) or pin (-PIN)
names, the tool outputs a summary message similar to the following:
// Note: Adding faults for 330 fault sites.

When you specify the optional -VERbose switch, then the tool outputs the instance or pin
names instead of the summary. You can optionally redirect this output to a file using the >
or >> redirection operators.
If you use actual instance or pin names instead of wildcards, then this switch has no effect.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.

562 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Nofaults

Examples
The following example deletes an extra nofault setting from the instance i_1007 and then adds
all faults to the circuit, thereby allowing the tool to add faults to the pin names of the i_1007
instance:
add nofaults i_1006 i_1007 i_1008 -instance
delete nofaults i_1007 -instance
set system mode fault
add faults -all

Related Commands
Add Nofaults Report Nofaults

LBISTArchitect Reference Manual, v2017.3 563

September 2017
Fault Simulation Command Dictionary
Delete Notest Points

Delete Notest Points

Scope: Fault and Good modes
Prerequisites
You must add circuit points with the Add Notest Points command before you can delete them.
Usage
DELete NOtest Points pin_pathname… | -All
Description
Removes the circuit point that indicates to the tool which specified pins it cannot use for
testability insertion.
The Delete Notest Points command deletes circuit points added using the Add Notest Points
command. These notest circuit points identify output pins of cells that LBISTArchitect is not to
use for insertion of controllability and observability. You can display a list of the current circuit
points and their associated pins by using the Report Notest Points command.
Arguments
• pin_pathname
A repeatable string that specifies a list of pins for which you want to delete the circuit points
that LBISTArchitect cannot use for testability insertion.
• -All
A switch that causes deletion of all previously-added circuit points.
Examples
The following example deletes an incorrect notest circuit point and corrects it with a new circuit
point before performing testability analysis:
set system mode fault
add notest points i_1006/o i_1007/o i_1008/o
delete notest points i_1007/o
add notest points i_1009/o

Related Commands
Add Notest Points Report Notest Points

564 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Output Masks

Delete Output Masks

Scope: Setup mode
Prerequisites
You must add primary output pin masks with the Add Output Masks command before you can
delete them.
Usage
DELete OUtput Masks primary_output… | -All
Description
Removes the masking of the specified primary output pins.
The tools use primary output pins as the observe points during the fault detection process. When
you mask a primary output pin with the Add Output Masks command, the tools mark that pin as
an invalid primary output during the fault detection process.
Arguments
• primary_output
A repeatable string that specifies the names of the primary output pins that you want to
unmask.
• -All
A switch that unmasks all primary outputs masked using the Add Output Masks command.
Examples
The following example first incorrectly chooses two of the design’s primary output pins to
mask. The example then unmasks the one primary output that was inappropriate, masks the
correct primary output, and then displays the complete list of currently-masked primary output
pins no longer available as observation points:
add output masks q1 qb3
delete output masks q1
add output masks qb1
report output masks
qb1
qb3

Related Commands
Add Output Masks Report Output Masks

LBISTArchitect Reference Manual, v2017.3 565

September 2017
Fault Simulation Command Dictionary
Delete Pin Constraints

Delete Pin Constraints

Scope: Setup mode
Prerequisites
You must add pin constraints with the Add Pin Constraints command before you can delete
them.
Usage
DELete PIn Constraints primary_input_pin… | -All
Description
Removes the pin constraints from the specified primary input pins.
The Delete Pin Constraints command deletes pin constraints added to the primary inputs with
the Add Pin Constraints command. You can delete the pin constraints for specific pins or for all
pins.

FlexTest Specifics
Primary inputs that do not have any constraints use the default format of type NR, period 1, and
offset 0. You can change the default format by using the Setup Pin Constraints command.
Arguments
• primary_input_pin
A repeatable string that specifies a list of primary input pins whose pin constraints you want
to delete.
• -All
A switch that deletes the pin constraints of all primary input pins.
Examples
The following example adds two pin constraints and then deletes one of them:
add pin constraints indata2 c1
add pin constraints indata4 c1
delete pin constraints indata2

Related Commands
Add Pin Constraints Setup Pin Constraints
Report Pin Constraints

566 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Pin Equivalences

Delete Pin Equivalences

Scope: Setup mode
Prerequisites
You must add equivalences with the Add Pin Equivalences command before you can delete
them.
Usage
DELete PIn Equivalences primary_input_pin… | -All
Description
Removes the pin equivalence specifications for the designated primary input pins.
The Delete Pin Equivalences command deletes the equivalence specifications added to the
primary inputs with the Add Pin Equivalences command. You can delete pin equivalences for
specific pins or for all pins.
Arguments
• primary_input_pin
A repeatable string that specifies a list of primary input pins whose equivalence
specifications you want to delete.
• -All
A switch that deletes all pin equivalence effects.
Examples
The following example deletes an incorrect pin equivalence specification and adds the correct
one:
add pin equivalences indata2 -invert indata4
delete pin equivalences indata2
add pin equivalences indata3 -invert indata4

Related Commands
Add Pin Equivalences Report Pin Equivalences

LBISTArchitect Reference Manual, v2017.3 567

September 2017
Fault Simulation Command Dictionary
Delete Primary Inputs

Delete Primary Inputs

Scope: Setup mode
Usage
DELete PRimary Inputs {net_pathname… | primary_input_pin… | -All} [-Class {User |
System | Full}]
Description
Removes the specified primary inputs from the current netlist.
The Delete Primary Inputs command deletes from a circuit the primary inputs that you specify.
You can delete either the user class, system class, or full classes of primary inputs. If you do not
specify a class, the tool deletes the primary inputs from the user class.
You can display a list of any class of primary inputs by using the Report Primary Inputs
command.
Arguments
• net_pathname
A repeatable string that specifies the circuit connections that you want to delete. You can
specify the class of primary inputs to delete with the -Class switch.
• primary_input_pin
A repeatable string that specifies a list of primary input pins that you want to delete. You
can specify the class of primary inputs to delete with the -Class switch.
• -All
A switch that deletes all primary inputs. You can specify the class of primary inputs to
delete with the -Class switch.
• -Class User | System | Full
An optional switch and literal pair that specifies the class code of the designated primary
input pins. The valid class code literal names are as follows:
User — A literal specifying that the primary inputs were added using the Add Primary
Inputs command. This is the default class.
System — A literal specifying that the primary inputs derive from the netlist.
Full — A literal specifying that the primary inputs consists of both user and system
classes.
Examples
The following example deletes an extra added primary input from the user class of primary
inputs:
add primary inputs indata2 indata4 indata6
delete primary inputs indata4 -class user

568 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Primary Inputs

Related Commands
Add Primary Inputs
Report Primary Inputs

LBISTArchitect Reference Manual, v2017.3 569

September 2017
Fault Simulation Command Dictionary
Delete Primary Outputs

Delete Primary Outputs

Scope: Setup mode
Usage
DELete PRimary Outputs {net_pathname… | primary_output_pin… | -All} [-Class {User |
System | Full}]
Description
Removes the specified primary outputs from the current netlist.
The Delete Primary Outputs command deletes from a circuit the primary outputs that you
specify. You can delete either the user class, system class, or full classes of primary outputs. If
you do not specify a class, the tool deletes the primary outputs from the user class.
You can display a list of any class of primary outputs by using the Report Primary Outputs
command.
Note
LBISTArchitect removes the output for the tool’s internal representation of the netlist.
The output, however remains in the generated netlist.

Arguments
• net_pathname
A repeatable string that specifies the circuit connections that you want to delete. You can
specify the class of primary outputs to delete with the -Class switch.
• primary_output_pin
A repeatable string that specifies a list of primary output pins that you want to delete. You
can specify the class of primary outputs to delete with the -Class switch.
• -All
A switch that deletes all primary outputs. You can specify the class of primary outputs to
delete with the -Class switch.
• -Class User | System | Full
An optional switch and literal pair that specifies the class code of the primary output pins
that you specify. The valid literal names are as follows:
User — A literal specifying that the list of primary outputs were added using the Add
Primary Outputs command. This is the default class.
System — A literal specifying that the list of primary outputs derive from the netlist.
Full — A literal specifying that the list of primary outputs consists of both the user and
system class.

570 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Primary Outputs

Examples
The following example deletes a primary output from the system class of primary outputs:
delete primary outputs outdata1 -class system

Related Commands
Add Primary Outputs
Report Primary Outputs

LBISTArchitect Reference Manual, v2017.3 571

September 2017
Fault Simulation Command Dictionary
Delete Processors

Delete Processors
Tools Supported: Tessent FastScan and Tessent TestKompress
Scope: All modes
Usage
DELete PROcessors [hostname[:cpus]]…
Description
Removes processor definitions previously specified with the Add Processors command for
distributable commands for fault simulation.
The Delete Processors command deletes slave processor definitions you previously specified
using the Add Processors command. When you issue the command with no arguments, the tool
discontinues all current slave processes. If you specify one or more hostname arguments, the
tool will discontinue slave processes only on the specified host machines. If you include :cpus
with hostname, the tool will discontinue only the specified number of slave processes on that
host machine. Without the :cpus, all current slave processes on that host machine are
discontinued. When specifying hostname, you must specify the network name of the machine,
even if it was originally selected by an LSF, SGE, or custom job scheduler.
Be aware that the process run by an LSF, SGE, or custom job scheduler is a script rather than
the actual slave process. If you discontinue these slave processes with the Delete Processors
command, the corresponding scripts also terminate.

Tip: Alternatively, you can end execution of the scripts by using the job scheduler
commands (SGE’s qdel, LSF’s bkill, or whatever is used by the job scheduler invoked
by the Add Processors Generic command) or a UNIX kill command. There will be a
small delay before the slave process is actually shut down to allow for the detection of the
script death and for the shutdown to be coordinated with the master process. Slave
processes shut down in this manner will appear to have died in the master process’s
transcript. This is normal behavior. Detection of script deaths occurs only during the Add
Processors, Delete Processors, and Report Processors commands. You can force
detection from the command line without other side effects by issuing the Report
Processors command with no arguments.

Arguments
• hostname
A repeatable string that specifies a host machine you previously defined with the
Add Processors command or received via a job scheduler. The hostname choices are as
follows:
machine_name — A string that specifies the host machine by its network name.
LOCALHOST — A literal that specifies the host machine is the machine on which you
invoked the tool.

572 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Processors

IPaddress — A string that specifies the host machine by its IP address.

• : cpus
An optional colon (:) and positive integer pair that specifies the number of processes to
delete on the particular host machine.
Example
The following example begins by reporting the distributed status. It then discontinues all the
slave processes currently running on one remote host (nemo) and one of the slave processes
running on the other remote host (ahab):
report processors
hosts/processors arch CPU(s) %idle free RAM process size
---------------- ------- ----------- ----- ------------ ------------
ace (master) x86 2 x 2.2 GHz 81% 8393.52 MB 20.07 MB
nemo 1 x86 2 x 2.0 GHz 98% 382.33 MB 18.78 MB
2 18.78 MB
3 18.78 MB
4 18.78 MB
ahab 1 x86 1 x 1.7 GHz 99% 334.98 MB 18.78 MB
2 18.78 MB
master and 6 processors running.

delete processors nemo ahab:1

// Deleted host nemo:4
// Deleted host ahab:1
// Total processors: 1
// Note: Freeing 1 ’FastScan’ license.

report processors
hosts/processors arch CPU(s) %idle free RAM process size
---------------- ------- ----------- ----- ------------ ------------
ace (master) x86 2 x 2.2 GHz 81% 8393.52 MB 20.07 MB
ahab 1 x86 1 x 1.7 GHz 97% 229.83 MB 18.78 MB
master and 1 processor running.

Related Commands
Add Processors Run
Report Bist Capture Set Distributed
Report Processors

LBISTArchitect Reference Manual, v2017.3 573

September 2017
Fault Simulation Command Dictionary
Delete Scan Chains

Delete Scan Chains

Scope: Setup mode
Prerequisites
You must add scan chains with the Add Scan Chains command before you can delete them.
Usage
DELete SCan Chains chain_name… | -All
Description
Removes the specified scan chain definitions from the scan chain list.
The Delete Scan Chains command deletes scan chains defined with the Add Scan Chains
command. You can delete the definitions of specific scan chains or of all scan chains.
Arguments
• chain_name
A repeatable string that specifies the names of the scan chain definitions that you want to
delete.
• -All
A switch that deletes all scan chain definitions.
Examples
The following example defines several scan chains, adding them to the scan chain list, then
deletes one of the scan chains:
add scan chains chain1 group1 indata2 outdata4
add scan chains chain2 group1 indata3 outdata5
add scan chains chain3 group1 indata4 outdata6
delete scan chains chain2

Related Commands
Add Scan Chains Report Scan Chains

574 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Scan Groups

Delete Scan Groups

Scope: Setup mode
Prerequisites
You must add scan chain groups with the Add Scan Groups command before you can delete
them.
Usage
DELete SCan Groups group_name… | -All
Description
Removes the specified scan chain group definitions from the scan chain group list.
The Delete Scan Groups command deletes scan chain groups defined with the Add Scan Groups
command. You can delete the definitions of specific scan chain groups or of all scan chain
groups.
When you delete a scan chain group, the tool also deletes all scan chains within the group.
Arguments
• group_name
A repeatable string that specifies the names of the scan chain group definitions that you
want to delete.
• -All
A switch that deletes all the scan chain group definitions.
Examples
The following example defines two scan chain groups, adding them to the scan chain group list,
then deletes one of the scan chain groups:
add scan groups group1 scanfile1
add scan groups group2 scanfile2
delete scan groups group1

Related Commands
Add Scan Groups Report Scan Groups

LBISTArchitect Reference Manual, v2017.3 575

September 2017
Fault Simulation Command Dictionary
Delete Tied Signals

Delete Tied Signals

Scope: Setup mode
Usage
DELete TIed Signals {floating_object_name… | -All} [-Class {User | System | Full}] [-Pin]
Description
Removes the assigned (tied) value from the specified floating nets or pins.
The Delete Tied Signals command deletes the tied values assigned with the Add Tied Signals
command. You can delete tied values from either user class, system class, or full classes of
floating nets or pins. If you do not specify a class, the tool deletes the tied values from the user
class of floating nets or pins. You can display a list of any class of tied floating nets or pins by
using the Report Tied Signals command.
Whenever you delete tied values from nets or pins, be sure to re-add, using the Add Tied
Signals command, any necessary values before performing another simulation. If you do not
add required tied values to floating nets or pins, the tool displays a warning. The warning states
that the design has floating nets or pins and assumes they are tied to the default value; you set
the default value using the Setup Tied Signals command.
Arguments
• floating_object_name
A repeatable string that specifies the names of the tied floating nets or pins whose tied
values you want to delete. You can specify the class of floating nets or pins on which to
delete the tied values with the -Class switch.
If you do not specify the -Pin option, the tool assumes floating_object_name is a net name.
If you specify a full net pathname, the tool deletes only the specified instance-based
blackbox tied signal. If you specify the -Pin option, it assumes the floating_object_name is a
pin name.
• -All
A switch that deletes the tied values from all tied floating nets or pins in the class of tied
floating nets or pins, which you specify with the -Class switch. This also includes all
instance-based blackbox tied signals.
• -Class User | System | Full
An optional switch and literal pair that specifies the class code of the tied floating nets or
pins that you specify. The valid literal names are as follows:
User — A literal specifying that the tied floating nets or pins were added by using the
Add Tied Signals command. This is the default class.
System — A literal specifying that the tied floating nets or pins derive from the netlist.
Full — A literal specifying that the tied floating nets or pins consist of both user and
system classes.

576 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Delete Tied Signals

• -Pin
A switch specifying that the floating_object_name argument that you provide is a floating
pin name.
Examples
The following example deletes the tied value from the user-class tied net “vcc”; thereby leaving
“vcc” as a floating net:
add tied signals 1 vcc vdd
delete tied signals vcc -class user

Related Commands
Add Tied Signals Setup Tied Signals
Report Tied Signals

LBISTArchitect Reference Manual, v2017.3 577

September 2017
Fault Simulation Command Dictionary
Dofile

Dofile
Scope: All modes
Usage
DOFile filename [-History]
Description
Executes the commands contained within the specified file.
The Dofile command sequentially executes the commands contained in a specified file. This
command is especially useful when you must issue a series of commands. Rather than executing
each command separately, you can place them into a file in their desired order and then execute
them by using the Dofile command. You can also place comment lines in the file by starting the
line with a double slash (//); the tool handles these lines as comments and ignores them.
The Dofile command sends each command expression (in order) to the tool which in turn
displays each command line from the file before executing it. If the tool encounters an error due
to any command, the Dofile command stops its execution, and displays an error message. You
can enable the Dofile command to continue regardless of errors by setting the Set Dofile Abort
command to Off.
Arguments
• filename
A required string that specifies the name of the file that contains the commands that you
want the tool to execute.
• -History
An optional switch that specifies for the tool to add the commands from a dofile to the
command line history list. By default, the commands in a dofile are not inserted into the
history list, but the dofile command itself is added to the list.
Examples
The following example executes, in order, all the commands from the file, command_file:
dofile command_file

The command_file may contain any application command available. An example of a

command_file is as follows:
set system mode fault
add faults -all
run

Related Commands
History Set Dofile Abort
Save History

578 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Exit

Exit
Scope: All modes
Usage
EXIt [-Force]
Description
Terminates the application tool program.
The Exit command terminates the tool session and returns to the operating system. You should
either save the current test patterns before exiting the tool or specify the -Force switch to not
save the test patterns.
If you are operating in interactive mode (not running a dofile) and you neither saved the current
test pattern set nor used the -Force option, the tool displays a warning message, and you are
given the opportunity to continue the session and save the test patterns before exiting.
Arguments
• -Force
An optional switch that explicitly specifies to not save the current test pattern set and to
immediately terminate the tool session.
Examples
The following example quits the tool without saving the current test pattern set.
set system mode good
add faults -all
run
exit -force

LBISTArchitect Reference Manual, v2017.3 579

September 2017
Fault Simulation Command Dictionary
Find Design Names

Find Design Names

Scope: All modes
Usage
FINd DEsign Names regular_expression [-LOcal | -Hier]
[-Design | -NETList | -LIbrary | -All]
[-INStance | -Net | -Pin [INPut | OUtput | INOut | ALLIn | ALLOut]
-Cell | -Module]
[{> | >>} file_pathname]
Description
Displays design object hierarchical names matched by an input regular expression, which may
include asterisk (*) or question mark (?) wildcard characters in the pathname string.
Arguments
• regular_expression
A required, regular expression, which may include asterisk (*) or question mark (?)
wildcard characters.
• -LOcal
An optional switch that matches wildcard characters within the current hierarchy level.
• -Hier
An optional switch that matches the regular expression across hierarchy boundaries (for
example, a* matches a1/b/c). This is the default.
• -Design
An optional switch that matches only pathnames to objects at the topmost library cell level.
• -NETList
An optional switch that matches objects from the top of the design down to the topmost
library cell.
• -LIbrary
An optional switch that matches objects within any level of library cells.
• -All
An optional switch that specifies matches objects at all levels of the design. This is the
default.
• -INStance
An optional switch that matches only instance pathnames. This is the default.
• -Net
An optional switch that matches only net pathnames.

580 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Find Design Names

• -Pin
An optional switch that matches only pin pathnames (any pin direction). The following
optional pin filters restrict which pins are matched:
INPut — Match only input pin pathnames.
OUtput — Match only output pin pathnames.
INOut — Match only bidirectional pin pathnames.
ALLIn — Match both input and bidirectional pin pathnames.
ALLOut — Match both output and bidirectional pin pathnames.
• -Cell
An optional switch that finds all library cell (model) names matching the specified regular
expression.
• -Module
An optional switch that finds all netlist module names matching the specified regular
expression.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following examples display object pathnames for various input wildcard expressions, given
a netlist with the following instance hierarchy:
/
tiny_i
U5
ret_i
intreg1_reg_0 ... intreg1_reg_31
add_20
U1_0 ... U1_3
add_30
U5 ... U12
mul_18
U5 ... U868
FS
U5 ... U33
mul_19
FS
U5 ... U278
U5 ... U181
mul_22
U5 ... U735
FS

LBISTArchitect Reference Manual, v2017.3 581

September 2017
Fault Simulation Command Dictionary
Find Design Names

U15 ...

and assuming the U5 instances all reference the following library cell:
model LSR2BUFA(Q, QN, S, R, G, SD, RD) (
input(S, R, G, SD, RD) ()
output(Q) (primitive = _buf UP1 (QT, Q);)
output(QN) (primitive = _buf UP2 (QNT, QN);)
intern(QT_int) (instance = LSI_LSR2 UD1 (QT_int, S, R, G, SD, RD);)
intern(QNT_int) (instance = LSI_LSR2N UD2 (QNT_int, S, R, G, SD, RD);)
intern(QT) (instance = LSI_NOTI UD3 (QT, QT_int);)
intern(QNT) (instance = LSI_NOTI UD4 (QNT, QNT_int);)
)

Example 1:
SETUP> find design names /ret_i/add_2* -instance -design -hier
// Note: Matched 4 names
/ret_i/add_20/U1_0
/ret_i/add_20/U1_1
/ret_i/add_20/U1_2
/ret_i/add_20/U1_3

Example 2:
SETUP> find design names /ret_i/add_2* -instance -netlist -hier
// Note: Matched 5 names
/ret_i/add_20
/ret_i/add_20/U1_0
/ret_i/add_20/U1_1
/ret_i/add_20/U1_2
/ret_i/add_20/U1_3

Finds instance add_20 under /ret_i/, and also descends the hierarchy to find all netlist instances
under /ret_i/add_20/.

Example 3:

SETUP> find design names /ret_i/add_2* -inst -netlist -local

// Note: Matched 1 names
/ret_i/add_20

This example shows that -Local doesn’t descend the hierarchy to find more matches as the
previous example does.

Example 4:

SETUP> find design names /ret_i/add_2* -ins -design -local

// Note: Matched 0 names

There are no instances of a library cell under /ret_i/ with instance name starting with add_2.

582 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Find Design Names

Example 5:

SETUP> find design names /ret_i/*_2? -ins -netlist -local

// Note: Matched 2 names
/ret_i/add_20
/ret_i/mul_22

Found 2 instances under /ret_i/.

Note
/ret_i/gt_68_2 did not match because the ‘?’ in the wildcard expression requires another
character after the ‘_2’.

Example 6:

SETUP> find design names */U5 -inst -design -hier

// Note: Matched 7 names
/tiny_i/U5
/ret_i/add_20/U5
/ret_i/mul_18/U5
/ret_i/mul_18/FS/U5
/ret_i/mul_19/U5
/ret_i/mul_19/FS/U5
/ret_i/mul_22/U5

Example 7:

SETUP> find design names ret_i/mul*/U5 -ins -des -local

// Note: Matched 3 names
/ret_i/mul_18/U5
/ret_i/mul_19/U5
/ret_i/mul_22/U5

Example 8:

SETUP> find design names ret_i/mul*/U5 -ins -design -hier

// Note: Matched 5 names
/ret_i/mul_18/U5
/ret_i/mul_18/FS/U5
/ret_i/mul_19/U5
/ret_i/mul_19/FS/U5
/ret_i/mul_22/U5

Example 9:

SETUP> find design names ret_i/mul_18/U5* -ins -library -hier

// Note: Matched 5 names
/ret_i/mul_18/U5
/ret_i/mul_18/U5/UD1
/ret_i/mul_18/U5/UD2

LBISTArchitect Reference Manual, v2017.3 583

September 2017
Fault Simulation Command Dictionary
Find Design Names

/ret_i/mul_18/U5/UD3
/ret_i/mul_18/U5/UD4

Example 10:

SETUP> find design names ret_i/mul*/U5/* -pin output -design -local

// Note: Matched 6 names
/ret_i/mul_18/U5/Q
/ret_i/mul_18/U5/QN
/ret_i/mul_19/U5/Q
/ret_i/mul_19/U5/QN
/ret_i/mul_22/U5/Q
/ret_i/mul_22/U5/QN

584 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Flatten Model

Flatten Model
Scope: Setup mode
Usage
FLAtten MOdel
Description
Creates a primitive gate simulation representation of the design.
The tool automatically flattens the design hierarchy down to the logically equivalent design
when you exit Setup mode. However, there may be times that you would like to access the
flattened model without having to exit Setup mode.
Examples
The following example shows flattening the design to the simulation primitives before adding
constraints that the rule checker then uses when you run the design rule checker. The rule
checker runs when you first attempt to exit Setup mode
flatten model
add pin constraints 1 and_b_in
set system mode good

Related Commands
Add Bist Capture Set System Mode

LBISTArchitect Reference Manual, v2017.3 585

September 2017
Fault Simulation Command Dictionary
Help

Help
Scope: All modes
Usage
HELp [command_name] [-MANual]
Description
Displays the usage syntax and system mode for the specified command.
The Help command displays useful information for a selected command. You can display the
usage and syntax of a command by typing Help and the command name. 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 consists of any keyword or Fault Simulation command. You can use
minimum typing for the command name. If you do not supply a command_name, the default
is to display a list of all the command names.
• -MANual
An optional string that specifies to also display the reference manual description for the
specified command.
If you type HELp and include only the -MANual switch, the tool opens the product
bookcase, giving access to all the manuals for that product group.
Examples
The following example displays the usage and system mode for the Report Primary Inputs
command:
help report primary inputs
// Report primary inputs
// usage: REPort PRimary Inputs [-Class <User|System|Full>][-All |
// pin_pathname...]
// legal system modes: ALL

586 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
History

History
Scope: All modes
Usage
HIStory [list_count] [-Nonumbers] [-Reverse]
Description
Displays a list of previously-executed commands.
The History 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.
Examples
The following command displays the history list with leading numbers, starting with the oldest
command.
history
1 help hist
2 dof fault.do

LBISTArchitect Reference Manual, v2017.3 587

September 2017
Fault Simulation Command Dictionary
History

3 analyze fault /I$20/en -stuck_at 1

4 set system mode setup
5 set system mode fault
6 add faults -all
7 run
8 report statistics
9 history

Related Commands
Save History

588 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Identify Redundant Faults

Identify Redundant Faults

Usage
IDEntify REdundant Faults
Description
Identifies faults among current the faults whose redundancy has not yet been determined.
The Identify Redundant Faults command identifies combinational redundant (RE) faults from
among those faults in the current fault list whose redundancy has not been determined yet. This
command is useful in situations where the tool has not specifically checked some faults for
redundancy, but where establishing their redundancy might improve test coverage. The
following are examples of such situations where you might improve the test coverage by using
this command after the simulation:
• When the tool generates patterns using named capture procedures, it does not identify
RE faults.
• When the tool simulates external patterns, it does not identify RE faults among the
undetected faults.
• When the tool simulate random patterns (logic BIST fault simulation), it does not
identify RE faults among the undetected faults.
This command will only target faults not yet proven to be either RE or non-RE. For example,
the command will not target a fault currently classified as det_simulation (DS) or that was
classified as DS before but is now uncontrolled (UC) or unobserved (UO). The command is
only meaningful if the current fault type is stuck-at or transition.
Related Commands
Run Set Random Patterns

LBISTArchitect Reference Manual, v2017.3 589

September 2017
Fault Simulation Command Dictionary
Load Faults

Load Faults
Scope: Fault and Good modes
Usage
LOAd FAults filename
{[-ALLOW_fault_sampling] | [-RETain] | [-PROtect [-Only] [-Force]] | [-Delete] |
[-DELETE_Equivalent]} | {[-Merge [-NO_Warnings]]} [-Prefix]
Description
Updates the current fault population to include or exclude the faults contained in the specified
fault file.
The Load Faults command affects the current fault population by either adding or removing
faults which you specify in an external fault file. Because you must identify the faults before
performing a fault simulation, this command is useful when you have a large number of faults to
identify.
The format of the fault file data can be either in a three-, four-, or six-column standard format.
Regardless of the format, the Load Faults command uses only the information in the first,
second, and last columns.
The file follows the format illustrated below:
stuck fault_class (cellname) (netname) (ignore) pin_pathname

The following list describes the content of each of the columns of data:
• stuck
The first column must be the stuck-at value.
• fault_class
The second column must be the fault class value.
• cellname
The third column is the cell name enclosed in parenthesis. When present, this column
indicates the type of cell in which the fault resides.
• netname
The fourth column is the net name enclosed in parenthesis. When present, this column
indicates the net in which the fault resides.
• ignore
The fifth column is ignored.
• pin_pathname
The last column must be the pin pathname.

590 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Load Faults

When you issue this command, the tool discards all patterns in the current test pattern set.
The filename specified cannot have fault information lines with comments appended to the end
of the lines or fault information lines greater than 6 columns. The tool will not recognize the line
properly and will not add the fault on that line to the faultlist.

Arguments
• filename
A required string that specifies the name of the file containing the fault list that you want to
load.
• -ALLOW_fault_sampling
An optional switch that enables fault sampling when loading faults.
By default, the Load Faults command ignores fault sampling rate data unless you specify
this switch. If the fault sampling rate is other than 100%, and you do not specify the
-ALLOW_fault_sampling switch, then the tool resets the sampling rate; for subsequent
commands, you must re-specify the sampling rate.
Note
The behavior for the -Delete or -DELETE_equiv switches remain unchanged
irrespective.

• -RETain
An optional switch that specifies for the tool to retain the fault class of each fault that is in
the fault list. This switch ensures that no DS faults are reclassified as AU faults due to the
tool’s AU analysis.
• -PROtect
An optional switch that specifies to load all faults from the external fault list file and to
protect the detected faults from manipulation by subsequent tool commands.
The tool assigns the protected faults to class DI. Use this switch when you want the tool to
generate tests only for undetected faults (stuck-at, toggle, transition, or IDDQ), yet
determine coverage statistics based on all detected faults. This switch does not apply to
bridge faults.
Note
Any fault in the tool’s current internal fault list that is identical to a protected fault being
read in also becomes protected and the tool removes it from the fault list.

Caution
If you use -Protect to turn on fault protection, be sure you no longer need the protection
before issuing a subsequent “set fault type” command. The Set Fault Type command
erases all fault information, even the information about protected faults.

LBISTArchitect Reference Manual, v2017.3 591

September 2017
Fault Simulation Command Dictionary
Load Faults

-Only
An optional switch that, together with -Protect, specifies to load only the detected
faults from the external fault list file and then protect them.
In contrast to other Load Faults options, “-protect -only” does not delete the internal
pattern set. This is because the option adds and protects faults for which it assumes a
pattern set exists elsewhere (in an external pattern file, for example). It does reset the
fault classes, however, because the loaded protected faults also protect any equivalent
fault in memory and this will change the coverages. Therefore, be sure to perform a
fault simulation of the current pattern set:
set system mode fault
run
set system mode atpg

-Force
An optional switch that, together with -Protect, specifies for the tool to protect UC
faults as well as detected faults from manipulation by subsequent tool commands.
• -Delete
An optional switch that specifies for the tool to remove all the filename faults except the
protected faults from the current fault population. To delete protected faults, you must use
the Delete Faults command.
• -DELETE_Equivalent
An optional switch that specifies for the tool to remove all the unprotected filename faults
from the current fault population within the tool’s session, and to remove all the unprotected
faults that are equivalent to those in filename.
• -Merge
An optional switch that merges the loaded external faults with the internal fault list. This
allows you to combine the fault lists from different ATPG sessions. For example, if you
partition your design and run ATPG for each partition, you can get chip-level fault statistics
by merging the partition fault lists. Also, for a single design or design partition, you can run
ATPG once, then you can target more undetected faults by incrementally running ATPG
using different settings and merging fault lists. For more information, see Example 2.
If a fault being loaded does not exist in the internal fault list, it will be added to the internal
fault list.
If a fault being loaded already exists in the internal fault list, the fault class of the existing
fault will be updated to have with the highest priority fault class. For example, if the fault
being loaded has a DI class and the matching fault in the internal list has a PT class, then the
class of the fault in the internal list will be updated to DI because DI has a higher priority
than PT.
Fault classes are prioritized as follows:
1. (Highest) Untestable Faults: RE, TI, BL
2. Detected or Detectable Faults: DR > DS > DF > DI > PT > PU > OS > HY

592 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Load Faults

3. Aborted or Undetectable Faults: UO > UC > AU > UU

Note
The three untestable fault classes (RE, TI, and BL) have equal priority. It is a conflict to
have a fault with more than one untestable fault class. The tool issues a warning message
if a fault being loaded has a different untestable fault class than a matching fault in the
internal fault list.

-NO_Warnings
An optional switch that suppresses warnings about conflicting untestable fault classes while
merging fault lists. If a fault being loaded has a different untestable fault class than a
matching fault in the internal fault list, the fault class defined in the internal list will be used.
• -Prefix
An optional switch that adds a string to the beginning of each pin pathname in the fault list
that is output after simulation of the LBISTed core.
When simulating the whole design, the fault list resulting from the core simulation is used to
avoid re-simulating the core inside the design. Because the fault locations in the fault list are
relative to the LBISTed core, this option instructs LBISTArchitect to append a string to each
fault that reflects the path difference between the fault location in the core and the actual
location of the core after it is instantiated in the design.
Examples
The following example adds faults to the circuit from an external tool-created fault list before
you begin a BIST simulation:
set system mode fault
load faults faultlist
run

Related Commands
Add Faults Set Fault Mode (FT)
Delete Faults Write Faults
Report Faults

LBISTArchitect Reference Manual, v2017.3 593

September 2017
Fault Simulation Command Dictionary
Report Bist Capture

Report Bist Capture

Scope: All modes
Usage
REPort BIst Capture
Description
Displays a list of the currently defined BIST capture windows.
The Report Capture Window command displays the list of the capture windows that are
currently defined as a result of the Add Bist Capture command. The LBISTArchitect BIST
controller generation phase creates these commands based on user defined capture windows
(created using the Add Capture Windows command), or based on internal application defaults.
A BIST capture window is defined by a named capture procedure that is stored in the test
procedure file, and a range of patterns that will use this capture procedure. The complete range
of patterns reported by the Report Bist Capture command typically represents a small subset of
the entire pseudo-random pattern space, and is applied to the complete pattern space by
repeating the sequence until all the pseudo-random patterns have been simulated.
Examples
The following example shows the output from the Report Bist Capture command.
report bist capture
// List of currently dedined Logic BIST capture windows
// Window name from pattern to pattern
// ----------- ------------ ----------
// cap1 0 14
// cap2 15 15
//
// NOTE: This list defines the active named capture window during pseudo-
// random pattern simulation. The tool automatically restarts at the top
// of the list when the pattern counter matches the final “to pattern”
// value.

Related Commands
Add Bist Capture

Command Summary

594 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Chain Masks

Report Chain Masks

Scope: All modes
Usage
REPort CHain Masks
Description
Reports the list of masked scan chains and their associated unload value.
Arguments
None.
Example
The following example adds several chain masks and then reports the added chain masks:
add chain masks chain2 chain4 chain5
report chain masks
// Masked scan chain Unload value Cell constraints
// ----------------- ------------ ----------------
// chain2 X OX
// chain4 X OX
// chain5 X OX

Related Commands
Add Chain Masks Delete Chain Masks

LBISTArchitect Reference Manual, v2017.3 595

September 2017
Fault Simulation Command Dictionary
Report Clocks

Report Clocks
Scope: All modes
Usage
REPort CLocks [-Display {DEBug | DESign | DAta | ALl}] [-Internal] [{> | >>} file_pathname]
Description
Displays a list of all the primary input pins currently in the clock list.
The Report Clocks command displays a list of all clocks specified using the Add Clocks
command.
Arguments
• -Display {DEBug | DESign | DAta | ALl}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DEBug — Debug window
DESign — Design window
DAta — Data window
ALl— A literal that displays the information in all of the preceding windows.
• -Internal
An optional argument that reports the internal clocks added with the Add Clocks ... -Internal
command. If you omit this arguement, then the tool only reports the PI clocks.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example adds two clocks to the clock list and then displays a list of the clocks:
add clocks 1 clk1
add clocks 0 clk0
report clocks

Related Commands
Add Clocks Delete Clocks
Analyze Control Signals

596 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Drc Rules

Report Drc Rules

Scope: All modes
Usage
REPort DRc Rules [-Fails_summary | -Summary |
rule_id… | rule_id-occurence#… | -All_fails]
[{> | >>} file_pathname]
D5 Usage
REPort DRc Rules D5
[ { [-TYpe {I0 | I1 | IX | T0 | T1 | TX | TLA}…]
[-NOType {I0 | I1 | IX | T0 | T1 | TX | TLA}…]
[-EDge_triggered | -LEvel_sensitive] } | -Summary]
[{> | >>} file_pathname]
Description
Displays either a summary of DRC violations (fails) or violation occurrence message(s).
The Report Drc Rules command displays data about design rules and DRC violations. It can
display a report in one of two formats:
• Summary report—Lists for each reported design rule, one line of data per rule, the
current number of DRC violations (fails), the violation handling, and a brief description
of the rule. When you request a summary of D5 violations, the report lists the number of
D5 violations of each type (INIT-0, INIT-1, INIT-X, TIE-0, TIE-1, TIE-X, TLA).
• Occurrence report—Lists one or more violation occurrence messages that give details of
specific DRC violations
Table 4-3 summarizes the available information and the arguments you use to obtain them.
Refer to the Arguments subsection for complete details about the arguments.

Table 4-3. Report DRC Rules Available Information and Arguments

Desired Display Rules/Occurrences Covered Argument
Summary Design rules that resulted in violations (fails) during -Fails_summary
report DRC
All design rules -Summary
Occurrence Specific rule, specific occurrence rule_id-occurrence#
report 1
Specific rule, all occurrences rule_id
All occurrences -All_fails
1. Additional D5-specific arguments enable you to further customize the D5 information.

LBISTArchitect Reference Manual, v2017.3 597

September 2017
Fault Simulation Command Dictionary
Report Drc Rules

You can use the Set Drc Handling command to change the handling of many of the A (RAM), B
(BIST), C (clock), D (data), E (extra), T (trace), and W (timing) rules.
Arguments
• -Fails_Summary
A switch that specifies to display the following for each user-controllable rule that resulted
in a violation (fail) during DRC:
o Rule identification (ID)
o Number of failures of the rule
o Current handling status of the rule
o Brief description of the rule
This is the command’s default.
Note
This switch does not display anything if there are no rule violations, or if the tool has not
yet performed DRC.

• -Summary
A switch that specifies to display a summary report that varies depending on whether you
are reporting on all design rules or just on the D5 rule.
When you report on all rules (Report Drc Rules -Summary), the following is reported for
each user-controllable rule, whether or not it resulted in a violation (fail) during DRC:
o Rule identification (ID)
o Number of failures of the rule
o Current handling status of the rule
o Brief description of the rule
When you report on just the D5 rule (Report Drc Rules D5 -Summary) the tool displays the
number of non-scan memory elements of each type (INIT-0, INIT-1, INIT-X, TIE-0, TIE-1,
TIE-X or TLA) that resulted in a D5 violation during DRC. Refer to the description of the
-Type switch for the meaning of the types.

598 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Drc Rules

• rule_id
A repeatable string that specifies the identification literal (ID) of a particular design rule for
which you want to display all violation occurrence messages.
The design rules and their IDs divide into the following seven groups: A (RAM), B (BIST),
C (clock), D (data), E (extra), T (trace), and W (timing).
• rule_id-occurrence#
A repeatable string that specifies the identification literal (ID) of a particular design rule and
the violation occurrence for which you want to display the occurrence message. This
argument must include the specific design rule ID (rule_id), the specific occurrence number
of the violation, and the hyphen between them. For example, you can analyze the second
violation occurrence of the C3 rule by specifying C3-2. The tool assigns numbers to
occurrences of rule violations as it encounters them; you cannot change the number
assigned to a specific occurrence.
• -All_Fails
A switch that specifies to display all occurrence messages for all occurrences of rule
violations. The displayed information can be quite lengthy, as it is the same information you
would get if you consecutively entered a “report drc rules <rule_id>” command for each
rule that had a violation. Use this switch to output a report of all violation occurrences (most
likely to a log file) for later analysis.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
D5-only arguments
• -TYpe I0 | I1 | IX | T0 | T1 | TX | TLA
An optional switch and repeatable literal that displays D5 occurrence messages for only the
specified type(s) of non-scan sequential elements. The literal choices for the type of element
are as follows (the term you will see in occurrence messages for each type is shown in
parentheses):
I0 — If the element is at 0 at the beginning of the first capture cycle and may go to any
state during capture. (INIT-0)
I1 — If the element is at 1 at the beginning of the first capture cycle and may go to any
state during capture. (INIT-1)
IX — If the element’s state is unknown at the beginning of the first capture cycle and
may go to any state during capture. (INIT-X)
T0 — If the element is always at 0 during capture. (TIE-0)

LBISTArchitect Reference Manual, v2017.3 599

September 2017
Fault Simulation Command Dictionary
Report Drc Rules

T1 — If the element is always at 1 during capture. (TIE-1)

TX — If the element is always at an unknown state during capture. (TIE-X)
TLA — If the element is always transparent when its clock is at its off state. (TLA)

Tip: Except for TLAs, you can also direct the tool to display information for only those
D5 elements that are edge-triggered or level-sensitive. See the -Edge_triggered and
-Level_sensitive switch descriptions for details.

• -NOType I0 | I1 | IX | T0 | T1 | TX | TLA
An optional switch and repeatable literal that specify not to display occurrence messages for
the particular type(s) of D5 violations. See the description of the -Type switch for the
meaning of the literal choices.
• -EDge_triggered | -LEvel_sensitive
Optional switches that specify to display D5 occurrence messages either for edge-triggered
or level-sensitive elements only. The default (when neither option is specified) is to display
information for both edge-triggered and level-sensitive elements.
Examples
The following example displays a summary of the rules that resulted in violations during an
attempted run:
report drc rules
C3: #fails=2 handling=warning (clock may capture data affected by its
captured data)
C5: #fails=1 handling=error (clock is connected to multiple ports of same
latch)
C7: #fails=19 handling=warning (scan cell capture ability check)
C8: #fails=2 handling=warning (PO connected to a clock line)
C9: #fails=2 handling=warning (PO connected to a clock line gated by scan
cell that uses same clock)
D5: #fails=23 handling=warning (non-scan memory element)
D6: #fails=22 handling=warning (non-transparent non-scan latches)
D7: #fails=22 handling=warning (stable high edge-triggered clock ports)

This example displays the occurrence message for the two C3 violations, and the first C7, and
first D7 violation reported in the preceding example:
report drc rules c3 c7-1 d7-1
// Warning: Clock /sgst failed rule C3 on input 3 of /sp_b_i0.latch
(1501). (C3-1)
// Source of violation: input 3 of /sp_c_i1.slave (1482).
// Warning: Clock /sgst failed rule C3 on input 3 of /sp_c_i0.latch
(1527). (C3-2)
// Source of violation: input 3 of /sp_c_i1.slave (1482).
// Warning: Clock input 5 of /c8.master (1495) cannot capture data
with single clock on. (C7-1)
// Warning: Flipflop /FF1 (103) has clock port set to stable high. (D7-1)

600 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Drc Rules

This example displays the occurrence message for the D7 violation:

report drc rules d7-1
//Error: Flipflop /FF1 (103) has clock port set to stable high. (D7-1)

The next example displays a summary of the non-scan memory elements that resulted in D5
rule violations:
report drc rules d5 -summary
// --------------------------------------------------------------------
// 44 non-scan memory elements are identified.
// --------------------------------------------------------------------
// 9 non-scan memory elements are identified as TIE-0. (D5)
// 2 non-scan memory elements are identified as TIE-1. (D5)
// 5 non-scan memory elements are identified as TIE-X. (D5)
// 3 non-scan memory elements are identified as INIT-0. (D5)
// 11 non-scan memory elements are identified as INIT-1. (D5)
// 4 non-scan memory elements are identified as INIT-X. (D5)
// 10 non-scan memory elements are identified as TLA. (D5)
// --------------------------------------------------------------------

The next example displays details about the preceding example’s D5 violations that occurred on
non-scan memory elements the tool identified as type INIT-X:
report drc rules d5 -type ix
// Warning: /U1 (78) is a non-scan flip-flop identified as INIT-x.(D5-1)
// Warning: /U6 (56) is a non-scan flip-flop identified as INIT-x.(D5-7)
// Warning: /U7 (82) is a non-scan flip-flop identified as INIT-x.(D5-8)
// Warning: /U9 (11) is a non-scan latch identified as INIT-x.(D5-9)
// Number of non-scan memory elements reported = 4.

The next example displays the information for just the INIT-X non-scan latch:
report drc rules d5 -type ix -level_sensitive
// Warning: /U9 (11) is a non-scan latch identified as INIT-x.(D5-9)
// Number of non-scan memory elements reported = 1.

You could obtain the same information using the -Notype switch:
report drc rules d5 -notype i1 i0 tx t1 t0 tla -level_sensitive
// Warning: /U9 (11) is a non-scan latch identified as INIT-x.(D5-9)
// Number of non-scan memory elements reported = 1.

Related Commands
Set Drc Handling

LBISTArchitect Reference Manual, v2017.3 601

September 2017
Fault Simulation Command Dictionary
Report Environment

Report Environment
Scope: All modes
Usage
REPort ENvironment [{> | >>} file_pathname]
Description
Displays the current values of all the “set” commands.
When you first invoke the tool, the Report Environment command shows all of the default
values for the “set” commands. By default, the output of the command is written to the
transcript window of the tool.
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example shows the current conditions under which the tool tests the circuit, then
performs a simulation run:
set system mode fault
add faults -all
report environment
run

The output from the Report Environment command may look like the following:
abort limit = 30/50
atpg compression = OFF
bist initialization = 0
capture clock = none
checkpoint = OFF
clockpo patterns = ON
clock restriction = clock_po
contention check = ON, mode = bus, handling = warning
fails report = OFF
fault mode = uncollapsed
fault type = stuck
gate level = design
gate report = normal
learn reporting = OFF

602 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Environment

logfile handling = OFF

net dominance = wired-gate
net resolution = wired-gate
observation point = master
pattern source = internal
possible credit = 50%
pulse generators = ON
RAM initialization = uninitialized
RAM test mode = static_pass_thru
random atpg = ON
random clocks = none
random patterns = 1024
screen display = ON
simulation mode = combinational depth = 0
skew load = OFF
system mode = setup
trace report = off
Z handling = int=X ext=X
Zhold behavior = ON

Related Commands
All SET commands

LBISTArchitect Reference Manual, v2017.3 603

September 2017
Fault Simulation Command Dictionary
Report Failures

Report Failures
Scope: Good and Fault modes
Prerequisites
You must specify the current pattern source with the Set Pattern Source command.
Usage
REPort FAIlures [pin_pathname -Stuck_at {0 | 1}] [-Max integer] [-Pdet]
[{> | >>} file_pathname]
Description
Displays the failing pattern results.
The Report Failures command performs either a good simulation or a fault simulation
depending on whether you provide any arguments. If you issue the command without any
arguments, the command performs a good machine simulation. If you specify a pin and a stuck-
at value, the command performs a fault simulation for those values. In either case, the command
uses the current pattern source (except pseudorandom patterns) and displays information on any
failing patterns. The command presents the failing patterns information in “scan test” and
“chain test” format as follows:
• “scan test” — For a failing response that occurs during the parallel measure of the
primary outputs, the command displays the following two columns:
o The test pattern number that causes the failure.
o The pin name of the failing primary output.
• “chain test” — For a failing response that occurs during the unloading of the scan chain,
the command displays the following three columns:
o The test pattern number that causes the failure.
o The name of the scan chain where the failing scan cell is located.
o The position in the scan chain of the failing scan cell. This position is 0- based, and 0
position is the scan cell closest to the scan-out pin.
You use this command primarily for diagnostics.
Arguments
The Report Failures command requires that you, at minimum, either provide no arguments or
provide the pin_pathname and -Stuck_at value. If you choose to provide the pin_pathname and
-Stuck_at value, you can further modify the command’s behavior by adding the -Max and -Pdet
switches.

604 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Failures

• pin_pathname -Stuck_at 0 | 1
A string paired with a switch and literal pair that specifies both the location and the value of
the fault that you want to check for failing patterns. The following describes each of the
arguments in more detail:
pin_pathname — A string that specifies the pin pathname of the fault whose failing
patterns you want to identify.
If you do not specify a pin_pathname, the command performs a “good” machine
simulation. You can use this good machine simulation to check that the measured
values from the test patterns are consistent with simulated values. Any columnar
failing patterns results indicate a mismatch.
-Stuck_at 0 | 1 — A switch and literal pair specifying the stuck-at values that you want
to simulate. The stuck-at literal choices are as follows:
0 — A literal that specifies to simulate the “stuck-at-0” fault.
1 — A literal that specifies to simulate the “stuck-at-1” fault.
• -Max integer
An optional switch and integer pair specifying the maximum number of failing patterns that
you want to occur on the specified fault before the command stops the simulation. The
default is: all failing patterns.
To use this option, you must also specify the pin_pathname and -Stuck_at value.
• -Pdet
An optional switch that specifies reporting of possible detections in addition to the binary
detections for the specified fault. The default is: report only the binary detections.
To use this option, you must also specify the pin_pathname and -Stuck_at value.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Example 1
The following example displays all failing pattern results from the simulation of a fault using an
external test pattern set:
set system mode good
set pattern source external file1
report failures i_1006/i1 -stuck_at 1

LBISTArchitect Reference Manual, v2017.3 605

September 2017
Fault Simulation Command Dictionary
Report Failures

4 /D_OUT(0)
4 chain1 3
6 /D_OUT(0)
7 /D_OUT(0)
7 /D_OUT(1)
7 chain1 3
.
.
.
29 /D_OUT(1)
29 /D_OUT(2)
29 chain1 0
29 chain1 3
31 /D_OUT(1)
31 /D_OUT(2)
// failing_patterns=15 simulated_patterns=36
fault_simulation_time=0.00 sec

Related Commands
Set Pattern Source

606 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Faults

Report Faults
Scope: Fault and Good modes
Usage
Stuck/Toggle Faults Usage:
REPort FAults [-Class class_type] [-Stuck_at {01 | 0 | 1}] [-All | object_pathname…]
[-Hierarchy integer [-Min_count integer]] [-Noeq] [-VErilog] [-CLOCK_Domains {ALL |
clock_pathname…} [-NO_EQUivalent_clocks]] [-CAPture_procedures {ALL |
capture_procedure_name…}]} | {[-SCAN_Enable] [-CLOCK_Cones] [-IO]
[-ASYnchronous_controls]} [{> | >>} file_pathname]
Description
Displays fault information from the current fault list.
The Report Faults command displays faults from the fault list added using the Add Faults or the
Load Faults commands. You can use the optional arguments to narrow the focus of the report to
only specific stuck-at faults that occur on a specific object in a specific class. If you do not
specify any arguments, Report Faults displays information on all the known faults.
The Report Faults command displays the following three columns of information for each fault:
• fault value - The fault value may be either 0 (for stuck-at-0) or 1 (for stuck-at-1).
• fault code - A code name that indicates the lowest-level fault class assigned to the fault.
• fault site - The pin pathname of the fault site.
You can use the -Hierarchy option to display a hierarchical summary of the selected faults. The
summary identifies the number of faults in each level of hierarchy whose level does not exceed
the specified level number. You can further specify the hierarchical summary by using the
-Min_count option which specifies the minimum number of faults that must be in a hierarchical
level before the tool displays them.
You may select to display either collapsed or uncollapsed faults by using the Set Fault Mode
command. Also, some fault data is large and it would be more appropriate to use the Write
Faults command, and then read the file contents.
Arguments
• -Class class_type
An optional switch and literal pair that specifies the class of faults that you want to display.
The class_type argument can be either a fault class code or a fault class name.

LBISTArchitect Reference Manual, v2017.3 607

September 2017
Fault Simulation Command Dictionary
Report Faults

Table 4-4 lists the valid fault class codes and their associated fault class names; use either
the code or the name when specifying the class_type argument:
Table 4-4. Fault Class Codes and Names
Fault Class Codes Fault Class Names Fault Class
Coverage
FU Full TE+UT
TE TEstable DT+PD+OS+
HY+AU+UD
DT DETEcted DS+DI+DR
DS DET_Simulation
DI DET_Implication
PD POSDET PT+PU
PU POSDET_Untestable
PT POSDET_Testable
OS OSCIllatory (FlexTest Only) OU+OT
OU OSC_Untestable
OT OSC_Testable
HY HYPErtrophic (FlexTest Only) HU+HT
HU HYP_Untestable (FlexTest Only)
HT HYP_Testable (FlexTest Only)
UI Uninitializable (FlexTest Only)
AU Atpg_untestable
UD UNDetected UC+UO
UC UNControlled
UO UNObserved
UT UNTestable UU+TI+BL+RE
UU UNUsed
TI TIed
BL Blocked
RE Redundant

• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies the stuck-at faults that you want to display.
The stuck-at literal choices are as follows:

608 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Faults

01 — A literal that displays both the “stuck-at-0” and “stuck-at-1” faults. This is the
default.
0 — A literal that displays the “stuck-at-0” faults.
1 — A literal that displays the “stuck-at-1” faults.
• -All
An optional switch that displays all of the faults on all model, netlist primitive, and top
module pins. This is the default.
• object_pathname
An optional repeatable string that specifies a list of pins or instances whose faults you want
to display.
• -Hierarchy integer
An optional switch and integer pair that specifies the maximum hierarchy level for which
you want to display a summary of the faults.
• -Min_count integer
An optional switch and integer pair that you can use with the -Hierarchy option to specify
the minimum number of faults that must be in a hierarchical level to display the hierarchical
summary. The default is 1.
• -Noeq
An optional switch that displays the fault class of equivalent faults. When you do not
specify this switch, the tool displays an “EQ” as the fault class for any equivalent faults.
• -Verilog
An optional switch that outputs the fault paths in Verilog syntax, rather than using the
existing netlist independent format.
• -CLOCK_Domains {ALL | clock_pathname…}
An optional switch and literal or repeatable string pair that specifies a list of clocks and
directs the tool to report only faults that are potentially detectable using any of the specified
clocks (or equivalent clocks). For a transition fault to be potentially detectable, it must be
detectable when the same clock (one of the specified clocks or an equivalent) is used for
launch and capture. Any other type of fault must be detectable when one of the specified
clocks or equivalents is used as the capture clock. The argument choices are as follows:
ALL — A literal that specifies all the clocks in the design.
clock_pathname — A repeatable string that specifies a particular clock.
Be aware that a fault reported using this switch might also be detectable by an unspecified
clock.
• -NO_EQUivalent_clocks
An optional switch that prevents the -Clock_domains switch from reporting faults in
equivalent clock domains.

LBISTArchitect Reference Manual, v2017.3 609

September 2017
Fault Simulation Command Dictionary
Report Faults

• -CAPture_procedures {ALL | capture_procedure_name…}

An optional switch and literal or repeatable string pair that specifies a list of enabled named
capture procedures and directs the tool to report faults that are potentially detectable by any
of the specified procedures. The argument choices are as follows:
ALL — A literal that specifies all enabled named capture procedures.
capture_procedure_name — A repeatable string that specifies a particular enabled
named capture procedure.
• -SCAN_Enable
An optional switch that specifies to report faults that fan out to the select lines of
multiplexers in the scan path. For this switch, a multiplexer is either a MUX simulation
primitive or a nonprimitive type multiplexer composed of AND and OR gates. Basically,
this switch reports all faults that are in the fanin cone of local scan enable signals and are
dominated by them.
• -CLOCK_Cones
An optional switch that specifies to report all faults that only fan out to clock ports,
Set/Reset ports or Read/Write control ports of memory elements, including RAM and
ROM. Notice that this applies to any memory elements, not just scan cells.
• -IO
An optional switch that specifies to report faults that are:
• Only controlled by PIs — To be acted on by the -IO switch, a PI either must not be
defined as a clock or, if defined as clock (or read/write control), must be constrained
off during capture.
• Only observed by POs
• -ASYnchronous_controls
An optional switch that specifies to report all faults that only fan out to Set/Reset ports of
state elements and RAMs. This switch applies to a subset of the faults the -CLOCK_Cones
switch reports.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays all faults that have been added to the circuit before performing
a simulation run:

610 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Faults

set system mode fault

add faults -all
report faults -all
run

Related Commands
Add Faults Set Fault Mode
Delete Faults Write Faults
Load Faults

LBISTArchitect Reference Manual, v2017.3 611

September 2017
Fault Simulation Command Dictionary
Report Feedback Paths

Report Feedback Paths

Scope: All modes
Prerequisites
You can use this command only after the tool performs the learning process, which happens
immediately after flattening a design to the simulation model. Flattening occurs when you first
attempt to exit Setup mode or when you issue the Flatten Model command.
Usage
REPort FEedback Paths [-All | loop_id#…] [-Display {DEBug | DESign | DAta | ALl}] [{> |
>>} file_pathname]
Description
Displays a textual report of the currently identified feedback paths.
The Report Feedback Paths command displays any feedback paths the tool identified during the
last circuit learning process. By default, the command displays all currently identified feedback
paths and their identification numbers. Issuing the command with the identification numbers of
specific paths of interest will limit the display to just those paths.
Note
Feedback paths include, by default, any duplicated gates.

Arguments
• -ALl
An optional switch that specifies to report all currently identified feedback paths. This is the
default.
• loop_id#
An optional, repeatable, non-negative integer that specifies the identification number of a
particular feedback path to report. The tool assigns the numbers consecutively, starting with
0.
• -Display {DEBug | DESign | DAta | ALl}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DEBug — Debug window
DESign — Design window
DAta — Data window
ALl— A literal that displays the information in all of the preceding windows.

612 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Feedback Paths

• > 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 for appending to the contents of
file_pathname.
Examples
The following example leaves the Setup mode (which, among other abilities, flattens the
simulation model and performs the learning process) and displays the identification numbers of
any learned feedback paths:
set system mode fault
report feedback paths
Loop#=0, feedback_buffer=26, #gates_in_network=5
INV /I_956__I_582/ (51)
PBUS /I_956__I_582/N1/ (96)
ZVAL /I_956__I_582/N1/ (101)
INV /I_956__I_582/ (106)
TIEX /I_956__I_582/ (26)
Loop#=1, feedback_buffer=27, #gates_in_network=5
INV /I_962__I_582/ (52)
PBUS /I_962__I_582/N1/ (95)
ZVAL /I_962__I_582/N1/ (100)
INV /I_962__I_582/ (105)
TIEX /I_962__I_582/ (27)

LBISTArchitect Reference Manual, v2017.3 613

September 2017
Fault Simulation Command Dictionary
Report Gates

Report Gates
Scope: All modes
Prerequisites
Although you can use this command in all modes, you can use it in the Setup mode only after
the tool flattens the netlist. This happens when you first attempt to exit Setup mode or when you
issue the Flatten Model command.
Usage
REPort GAtes {gate_id# | pin_pathname | instance_name}…
[-Type {gate_type}] [{-Sequential_test_depth | -0Control_depth |
-1Control_depth | -Observe_depth} depth_number]
[-Path {pin_pathname | gate_id} {pin_pathname | gate_id}]
[[-Endpoints] [-COnstraint] [-Forward | -Backward]
{pin_pathname | gate_id}…]
[{> | >>} file_pathname]
Description
Displays the netlist information and simulation results for the specified gates and the simulation
results.
The Report Gates command displays the netlist information for either the design-level or the
primitive-level gates you specify. You designate the gate by its gate identification number
(ID#), a pathname of a pin connected to a gate, an instance name (design level only), or a gate
type. You can specify a design cell by the pathname of a pin on the design cell. If you use a gate
ID# or gate type, the command always reports the primitive-level gate. You must flatten the
netlist before issuing this command.
The pin_pathname and instance_name arguments support regular expressions, which may
include any number of ‘*’ or ‘?’ wildcard characters embedded in the pathname string. The ‘*’
character matches any sequence of characters (including none) in a name, and the ‘?’ character
matches any single character. If a wildcard name is specified, the command will search for
matching instance names from the top library cell level, down to the primitive gates.
The format for the design-level report is:
instance_name cell_type
input_pin_name I (data) pin_pathname...
...
output_pin_name 0 (data) pin_pathname...
...

The format for the primitive-level report is:

instance_name (gate_ID#) gate_type
input_pin_name I (data) gate_ID#-pin_pathname...
...
output_pin_name O (data) gate_ID#-pin_pathname...
...

614 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Gates

The list associated with the input and output pin names indicate the pins to which they connect.
For the primitive level, this also includes the gate index number of the connecting gate and only
includes the pin pathname if one exists at that point. There is a limitation on reporting gates at
the design level. If some circuitry inside the design cell is completely isolated from other
circuitry, the command only reports the circuitry associated with the pin pathname.
You can also report the fan-in or fan-out cone of a specified gate with the Report Gates
command. The endpoints of a cone are defined as the primary inputs, primary outputs, tied
gates, rams, roms, flip-flops, and latches. All gates reported are at the primitive level.
You can change the output of the Report Gates command by using the Set Gate Report
command.
You must flatten the netlist before issuing this command.

Output of the Report Gates Command

Most of the data reported by the Report Gates command is simulation data regarding the
load_unload procedure immediately following the test_setup procedure. Statements like apply
shift are broken out by surrounding ()s.

The last group of data is more specialized. Its contents depend on the capture clock being set
with the Set Capture Clock command. The starting state for this simulation results from
simulating the events of the test setup procedure, followed by the load_unload procedure and its
apply procedures (shift and shadow_control).

• Case 1: No Capture Clock

There will be 1 or 2 values in the last pair of ()s. The first value is the simulation state
that results from holding all PIs at their pin constrained value and setting all clocks to X
at the end of load/unload.
If any state element has a different binary value than the one it had at the end of
simulating test setup, its value will be changed to X, the affect propagated, and the final
values saved in the second value between the ()s. See the following examples:
procedure shift =
force_sci 0;
measure_sco 0;
force clk 1 1;
force clk 0 2;
period 3;

procedure load_unload =
force clk 0 0;
force rst 0 0;
force sen 1 0;
apply shift 7 1;
period 3;
end;

LBISTArchitect Reference Manual, v2017.3 615

September 2017
Fault Simulation Command Dictionary
Report Gates

rep ga clk
// /CLK primary_input
// CLK O (0)(0X0)(0)(X)

The first (0) is the simulation of the events in the load_unload procedure prior to the
apply shift, (0X0) is the simulation of the shift procedure, (0) is the simulation of the
events in the load_unload after the shift, and finally (X) is the simulation of the clocks at
X.
• Case 2: Capture Clock Specified
There will be 3 or 4 values in the last pair of ()s. The first three values result from
simulating a pulse of the specified capture clock with all other clocks set to the off value.
If any state element has a different binary value than the one it had at the end of
simulation test setup, its value is changed to X, the effect is propagated, and the final
values are saved in the fourth value between the ()s.

Reporting on the First Input of a Gate

Report Gates provides a shortcut to display data on the gate connected to the first input of the
previously-reported gate. This lets you quickly and easily trace backward through circuitry. To
use Report Gates in this manner, first report on a specific gate and then enter:

SETUP> b

The following example shows how to use Report Gate and B commands to trace backward
through the first input of the previously-reported gate.

SETUP> rep gate 26

// /u1/inst__565_ff_d_1__13 (26) BUF
// "I0" I 269-
// "OUT" O 268- 75-

SETUP> b
// /u1/inst__565_ff_d_1__13 (269) LA
// "S" I 14-
// "R" I 145-
// SCLK I 4-/clk
// D I 265-/u1/_g32/X
// ACLK I 2-/scan_mclk
// SDI I 20-/u1/inst__565_ff_d_0__dff/Q2
// "OUT" O 26- 27-

SETUP> b
// /u1/inst__565_ff_d_1__13 (14) TIE0
// "OUT" O 269- 268-

When using the B and F commands, all arguments must be given at the primitive level.

616 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Gates

For pins that are not at the library cell boundary (pins internal to the model), the pin name is
enclosed in (“). The following example displays this issue.
FAULT> set gate leve prim
FAULT> rep gate /I_20/I_226/q
// /I_20/I_226 dffsr
// clk I (HX) /I_20/I_225/out
// d I (X) /I_20/I_222/out
// pre I (H1) /PRE
// clr I (H1) /CLR
// q O (X) /I_16/i0 /I_23/I_221/i0 /I_6/i0
// qb O (X)

FAULT> set gate leve prim

// Creating schematic for 5 instances (1 was compacted).

FAULT> rep gate /I_20/I_226/q

// /I_20/I_226 (12) BUF
// "I0" I (0) 39-
// q O (X) 16-/I_16/i0 31-/I_23/I_221/i0
17- /I_6/i0

FAULT> b
// /I_20/I_226 (39) DFF
// "S" I (LX) 26-
// "R" I (LX) 23-
// clk I (HX) 20-/I_20/I_225/out
// d I (X) 36-/I_20/I_222/out
// "OUT" O (0) 12- 13-
// MASTER cell_id=1 chain=c1 group=g1 invert_data=FFFF

Reporting on the First Fanout of a Gate

Similar to tracing backward through circuitry, you can also use a shortcut to trace forward
through the first fanout of the previously-reported gate. To use Report Gates in this manner,
first report on a specific gate and then enter:
SETUP> f

The following example shows how to use Report Gate and F commands to trace forward
through the first fanout of the previously reported gate.

SETUP> rep ga 269

// /u1/inst__565_ff_d_1__13 (269) LA
// "S" I 14-
// "R" I 145-
// SCLK I 4-/clk
// D I 265-/u1/_g32/X
// ACLK I 2-/scan_mclk
// SDI I 20-/u1/inst__565_ff_d_0__dff/Q2
// "OUT" O 26- 27-

LBISTArchitect Reference Manual, v2017.3 617

September 2017
Fault Simulation Command Dictionary
Report Gates

SETUP> f
// /u1/inst__565_ff_d_1__13 (26) BUF
// "I0" I 269-
// "OUT" O 268- 75-

SETUP> f
// /u1/inst__565_ff_d_1__13 (268) LA
// "S" I 14-
// "R" I 145-
// BCLK I 1-/scan_sclk
// "D0" I 26-
// "OUT" O 24- 25-

When using the B and F commands, all arguments must be given at the primitive level.
When using LBISTArchitect to report on RAM or ROM gates, the Report Gates command
displays the RAM and ROM data that describes their behavior. The RAM and ROM simulation
primitives are the same as the library primitives with the outputs being OUT gates in the
RAM/ROM fanout list. The command gives RAM behavior summary information at the end of
the displayed data. The report displays the following messages:
write port: write=G/G (vvv-v-v) first_adr=G first_di=G stability=vv
read port: read=G/G (vvv-v-v) first_adr=G first_do=G stability=vv
Test behavior: Stability=vvvv tiex_flag=v read_only_flag=v
ramseq_flags=v/v(vv)
Contention Behavior: write_write=v/v read_read=v read_write=v/v

618 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Gates

The following describes the fields for the write port message line:

LBISTArchitect Reference Manual, v2017.3 619

September 2017
Fault Simulation Command Dictionary
Report Gates

The following describes the fields for the read port message line:

620 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Gates

The following describes the fields for the Test behavior message line:

LBISTArchitect Reference Manual, v2017.3 621

September 2017
Fault Simulation Command Dictionary
Report Gates

The following describes the fields for the Contention Behavior message line:

622 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Gates

Arguments
The following lists the three methods for naming the objects on which you want the tool to
display gate information. You can use any number of the three argument choices, in any order.
• gate_id# — A repeatable integer that specifies the gate identification numbers of the
objects. The value of the gate_id# argument is the unique identification number that the tool
automatically assigns to every gate within the design during the model flattening process.
• pin_pathname — A repeatable string that specifies the names of pins within the design.
• instance_name — A repeatable string that specifies the top-level boundary instance names
within the design. This is used for the design level only.
• -Type gate_type
A repeatable switch where gate_type is a name pair that specifies the gate types for which
you want to display the gate information. Table 4-5 lists the supported types for each tool.
Table 4-6 lists the valid clock port categories.
• -Forward {pin_pathname | gate_id}
An optional switch and repeatable string or integer pair that reports the fan-out cone of the
specified gate.
• -Backward {pin_pathname | gate_id}
An optional switch and repeatable string or integer pair that reports the fan-in cone of the
specified gate.
• -Endpoints [-Forward | -Backward] {pin_pathname | gate_id}
An optional switch and repeatable string or integer pair that reports only the endpoint of the
cone.
Note
Immediately after -Endpoints, you must specify either -Forward or
-Backward followed by the specified gate. When using -Endpoints or -COnstraint
simultaneously, -Forward or -Backward followed by the specified gate need only be
entered once.

• -COnstraint [-Forward | -Backward] {pin_pathname | gate_id}

An optional switch that takes into account the effects of pin and cell constraints.
For a gate whose output is constrained to a fixed value, the tool reports only other gates
whose output is also constrained. For a gate whose output is not constrained to a fixed value,
the tool reports only other gates with unconstrained outputs. During backwards tracing, a
mux input, which is always blocked by a constrained value on the select line of the mux,
will never be backtraced.

LBISTArchitect Reference Manual, v2017.3 623

September 2017
Fault Simulation Command Dictionary
Report Gates

Note
Immediately after -Constraint, you must specify either -Forward or
-Backward followed by the specified gate. When using -Endpoints or -COnstraint
simultaneously, -Forward or -Backward followed by the specified gate need only be
entered once.

• -Path {gate_id# | pin_pathname} {gate_id# | pin_pathname}

An optional switch that reports on the path between the first gate_id# | pin_pathname and
the second gate_id# | pin_pathname. All paths must be specified at the primitive level. Paths
do not extend through sequential elements. The output generates a report on each primitive
in the path(s), in order of increasing gate_id#.
• -Sequential_test_depth depth_number
An optional switch and integer pair that specifies for the tool to report gates with a
sequential test depth greater than the specified depth_number. The sequential test depth is
the greater of the control 0 and control 1 depths plus the observe depth for the primitive
output. This is the minimum depth required to test stuck faults at the primitive output. This
is also the number used to determine the maximum sequential test depth of the circuit.
• -0Control_depth depth_number
An optional switch and integer pair that specifies for the tool to report gates with a control 0
depth greater than the specified depth_number. The control 0 depth is the minimum
sequential depth required to set the primitive output to a 0.
• -1Control_depth depth_number
An optional switch and integer pair that specifies for the tool to report gates with a control 1
depth greater than the specified depth_number. The control 1 depth is the minimum
sequential depth required to set the primitive output to a 1.
• -Observe_depth depth_number
An optional switch and integer pair that specifies for the tool to report gates with an observe
depth greater than the specified depth_number. The observe depth is the minimum
sequential depth required to observe the output of the primitive at either a primary output or
scan cell
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.

624 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Gates

Table 4-5. Reportable Gate Types

gate_type Description
BUF buffer
INV inverter
AND and
NAND inverted and
OR or
NOR inverted or
XOR exclusive-or
NXOR inverted exclusive-or
DFF D flip-flop, same as _dff library primitive
LA latch, same as _dlat library primitive
PI primary input
PO primary output
TIE0 tied low
TIE1 tied high
TIEX tied unknown
TIEZ tied high impedance
HIST histogram of each primitive type used
TSD tri-state driver, first input is active high enable line
BUS tri-state bus
ZVAL Z converter gate, converts Z to X
WIRE undetermined wired gate
MUX 2-way multiplexer,
first line is select line
SW switch gate, first input is active high enable line
PBUS pulled bus gate,
where the second input is the pulled value
OUT memory model gate,
created for each read data bit
RAM random access memory

LBISTArchitect Reference Manual, v2017.3 625

September 2017
Fault Simulation Command Dictionary
Report Gates

Table 4-5. Reportable Gate Types (cont.)

gate_type Description
ROM read only memory
XDET X detector, gives 1 when input is X
ZDET Z detector, gives 1 when input is Z
TLA transparent latch
STLA seq_transparent latch
STFF seq_transparent flip-flip

Table 4-6. Clock Port Categories

Category Description
IL inactive low
IH inactive high
AHS active high slave
ALS active low slave

Examples
The following example displays the simulated values of the gate and its inputs at the primitive
level:
set system mode fault
set gate report error_pattern
set gate level primitive
report gates i_1006/o

The gate report for the design level may look like the following:
/P2.13P ND2
A I /LD.1
B I /M1.1
Z O /P2.2P/S

The gate report for the primitive level may look like the following:
/P2.13P (23) NAND
A I 9-/LD.1
B I 6-/M1.1
Z O 33-/P2.2P/S

The gate report for the primitive level of a RAM gate may look like the following:
// /P1.RAM/U1 (67) RAM
// "I0" I 27-
// "I1" I 20-
// RCK0 I 36-

626 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Gates

// "I3" I
26-
// "I4" I
42-
// "I5" I
43-
// "I6" I
44-
// "I7" I
45-
// "I8" I
46-
// WCK0 I
28-
// "I10" I
19-
// A14 I
29-
// A13 I
30-
// A12 I
31-
// A11 I
32-
// A10 I
34-
// D14 I
66-/P1.RAM/D1[0]
// D13 I
65-/P1.RAM/D1[1]
// D12 I
64-/P1.RAM/D1[2]
// D11 I
63-/P1.RAM/D1[3]
// D10 I
62-/P1.RAM/D1[4]
// "OUT" O
68- 69- 70-
// 71- 72-
// address size = 5
// data size = 5
// minimum address = 0
// maximum address = 31
// number write ports = 1
// number read ports = 1
// edge_triggered = no
// initialization file = ram.init_file
// write port: write=28/- (H) first_adr=29 first_di=66 stability=SS
// read port: read=36/- (0) first_adr=42 first_do=68 stability=SS
// Test behavior: stability=SSSS tiex_flag=0 read_only_flag=1
// ramseq_flags=1/0(00)
// Contention behavior: write_write=allow/X read_read=normal
// read_write=read_new/write_normal

Related Commands
Set Gate Report

LBISTArchitect Reference Manual, v2017.3 627

September 2017
Fault Simulation Command Dictionary
Report LFSR Connections

Report LFSR Connections

Scope: All modes
Usage
REPort LFsr Connections
Description
Displays a list of all the connections between Linear Feedback Shift Registers (LFSRs) and
primary pins.
The Report LFSR Connections command displays all of the connections between the LFSRs
and the primary pins. These connections were specified with the Add LFSR Connections
commands.
Examples
The following example displays the connections between the LFSRs and primary pins:
add lfsrs lfsr1 prpg 5 15 -serial -in
add lfsrs lfsr2 prpg 5 13 -serial -in
add lfsrs misr1 misr 5 11 -parallel -in
add lfsr taps lfsr1 1 3
add lfsr taps lfsr2 2 3
add lfsr connections scan_in.1 lfsr1 3
add lfsr connections scan_out.0 misr1 2
report lfsr connections

Related Commands
Add LFSR Connections Delete LFSR Connections

628 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report LFSRs

Report LFSRs
Scope: All modes
Usage
REPort LFsrs [ -Binary | -Hexadecimal ] [{> | >> }file_pathname]
Description
Displays a list of definitions for all the current Linear Feedback Shift Registers (LFSRs).
The Report LFSRs command displays all of the LFSRs with their current values and tap
positions, which you specified using the Add LFSRs and Add LFSR Taps commands.
Arguments
• -Binary
An optional switch that specifies to report all values in binary format. This is the default.
• -Hexadecimal
An optional switch that specifies to report all values in hexadecimal format.
• > 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 for appending to the contents of
file_pathname.
Examples
The following example displays the definitions of all the current LFSRs:
add lfsrs lfsr1 prpg 5 15 -serial -in
add lfsrs lfsr2 prpg 5 13 -serial -in
add lfsrs misr1 misr 5 11 -parallel -in
report lfsrs

The following example displays the definitions of all the current LFSRs in hexadecimal format
and appends them to the file named report_hex:

add lfsrs lfsr1 prpg 5 15 -serial -in

add lfsrs lfsr2 prpg 5 13 -serial -in
add lfsrs misr1 misr 5 11 -parallel -in
report lfsrs -hex >> report_hex

Related Commands
Add LFSRs Set LFSR Seed
Add LFSR Taps Setup LFSRs
Delete LFSRs

LBISTArchitect Reference Manual, v2017.3 629

September 2017
Fault Simulation Command Dictionary
Report Loops

Report Loops
Scope: All modes
Usage
REPort LOops [-All | loop_id#…] [-Display {DESign | DAta}] [{> | >>} file_pathname]
Description
Displays information about circuit loops.
The Report Loops command displays information about currently identified loops in the circuit.
For each loop, the report indicates whether the loop was broken by duplication. Loops that are
not broken by duplication are shown as being broken by a constant value, which means the loop
is either a coupling loop or has a single multiple fanout gate. The report also includes the pin
pathname and gate type of each gate in each loop.
You can write the loops report information to a file by using the command’s redirection
operators.
Arguments
• -ALl
An optional switch that specifies to report all the loops in the circuit. This is the default.
• loop_id#
An optional, repeatable, positive integer that specifies the identification number of a
particular loop to report. The tool assigns loop identification numbers consecutively,
starting with 1.
• -Display {DESign | DAta}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DESign — Design window
DAta — Data window
• > 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 for appending to the contents of
file_pathname.
Examples
The following example lists all the loops in the circuit:
report loops

630 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Loops

Loop = 1: not_duplicated (coupling loop)

my_design/my_minibus (SBUS)
my_design/PAD (BUF)
my_design/my_minibus (Z2X)
Loop = 2: not_duplicated (coupling loop)
...
Loop = 8: not_duplicated (single multiple fanout)
my_design/al/pl/padx (BUF)
my_design/al/pl/pad (BUF)
my_design/pad (WIRE)

The next example displays loop 8 only:

report loops 8
Loop = 8: not_duplicated (single multiple fanout)
my_design/al/pl/padx (BUF)
my_design/al/pl/pad (BUF)
my_design/pad (WIRE)

The next example writes the display information for loop 8 to a new file named my_loop_file:
report loops 8 > my_loop_file
... writing to file my_loop_file

Related Commands
Report Feedback Paths

LBISTArchitect Reference Manual, v2017.3 631

September 2017
Fault Simulation Command Dictionary
Report MTPI Controller

Report MTPI Controller

Scope: All modes
Usage
REPort MTpi Controller controller_name | -All
Description
Reports the state data related to the MTPI controller(s).
The REPort MTPI Controller command lists the state data for the specified or all MTPI
controllers in the design.
Arguments
• controller_name
A string that specifies the name of the MTPI controller to report on.
• -All
A switch that specifies to report on all defined MTPI controllers.
Examples
The following example lists the state data for the “controller1” MTPI controller:
report mtpi controller controller1
MTPI Controller controller1 Connections =
corecomp/core_i/phase_1 corecomp/core_i/phase_2
corecomp/core_i/phase_3
Output_states:
cycle = 0 output = 001
cycle = 2 output = 010
cycle = 10 output = 100
cycle = 18 output = 000

Related Commands
Add MTPI Controller Delete MTPI Output
Add MTPI Output
Delete MTPI Controller

632 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Nofaults

Report Nofaults
Scope: All modes
Usage
REPort NOfaults pathname… | -All [-Instance] [-Stuck_at {01 | 0 | 1}] [-Class {Full | User |
System}] [{> | >>} file_pathname]
Description
Displays the nofault settings for the specified pin pathnames or pin names of instances.
The Report Nofaults command displays for pin pathnames or pin names of instances the nofault
settings which you previously specified with the Add Nofaults command.
Arguments
• pathname
A repeatable string that specifies the pin pathnames or the instance pathnames for which
you want to display the nofault settings. If you specify an instance pathname, you must also
specify the -Instance switch.
• -All
A switch that displays the nofault settings on either all pin pathnames or, if you also specify
the -Instance switch, all pin names of instances.
• -Instance
An optional switch that specifies that the pathname or -All argument indicates instance
pathnames.
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies the stuck-at nofault settings which you
want to display. The stuck-at literal choices are as follows:
01 — A literal that displays both the “stuck-at-0” and “stuck-at-1” nofault settings. This
is the default.
0 — A literal that displays only the “stuck-at-0” nofault settings.
1 — A literal that displays only the “stuck-at-1” nofault settings.
• -Class Full | User | System
An optional switch and literal pair that specifies the source (or class) of the nofault settings
which you want to display. The literal choices are as follows:
Full — A literal that displays all the nofault settings in the user and system class. This is
the default.
User — A literal that displays only the user-entered nofault settings.
System — A literal that displays only the netlist-described nofault settings.

LBISTArchitect Reference Manual, v2017.3 633

September 2017
Fault Simulation Command Dictionary
Report Nofaults

• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays all pin names of the instances that have the nofault settings:
add nofaults i_1006 i_1007 i_1008 -instance
report nofaults

Related Commands
Add Nofaults Delete Nofaults

634 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Notest Points

Report Notest Points

Scope: Fault and Good modes
Usage
REPort Notest Points [{> | >>} file_pathname]
Description
Displays all the circuit points for which you do not want to insert controllability and
observability.
The Report Notest Points command displays the circuit points added using the Add Notest
Points command and that LBISTArchitect cannot use for testability insertion.
Arguments
• > 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 for appending to the contents of
file_pathname.
Examples
The following example displays the list of all circuit points that LBISTArchitect cannot use for
testability insertion:
set system mode fault
add notest points i_1006/o i_1007/o
add notest points i_1009/o
report notest points

Related Commands
Add Notest Points Delete Notest Points

LBISTArchitect Reference Manual, v2017.3 635

September 2017
Fault Simulation Command Dictionary
Report Output Masks

Report Output Masks

Scope: All modes
Usage
REPort OUtput Masks [{> | >>} file_pathname]
Description
Displays a list of the currently masked primary output pins.
The Report Output Masks command displays the masked primary output pins using the Add
Output Masks command. When you mask a primary output pin, the tool marks that pin as an
invalid observation point during the fault detection process. The tool uses all unmasked primary
output pins as possible observation points to which the effects of all faults propagate for
detection.
Arguments
• > 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 for appending to the contents of
file_pathname.
Examples
The following example masks two primary outputs and then displays the results:
add output masks qb1 qb2
report output masks
qb1
qb2

Related Commands
Add Output Masks Delete Output Masks

636 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Pin Constraints

Report Pin Constraints

Scope: All modes
Usage
REPort PIn Constraints [-Display {DEBug | DESign | DAta | ALl}] [{> | >>} file_pathname]
Description
Displays the pin constraints of the primary inputs.
The Report Pin Constraints command displays the pin constraints added to the primary inputs
with the Add Pin Constraints command.
The command displays the constraints on all the primary inputs which you restricted to be at a
constant value during BIST simulation.
Arguments
• -Display {DEBug | DESign | DAta | ALl}
A switch and literal that displays the reported information graphically in the specified
DFTVisualizer window(s). The choices are as follows:
DEBug — Debug window
DESign — Design window
DAta — Data window
ALl— A literal that displays the information in all of the preceding windows.
• > 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 for appending to the contents of
file_pathname.
Examples
The following example displays the constraints of all primary inputs:
add pin constraints indata2 c1
add pin constraints indata4 c0
report pin constraints

Related Commands
Add Pin Constraints Setup Pin Constraints (FT)
Delete Pin Constraints

LBISTArchitect Reference Manual, v2017.3 637

September 2017
Fault Simulation Command Dictionary
Report Pin Equivalences

Report Pin Equivalences

Scope: All modes
Usage
REPort PIn Equivalences [{> | >>} file_pathname]
Description
Displays the pin equivalences of the primary inputs.
The Report Pin Equivalences command displays a list of primary inputs which you restricted to
be at equivalent or complementary values using the Add Pin Equivalences command.
Arguments
• > 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 for appending to the contents of
file_pathname.
Examples
The following example displays all pin equivalences added to the primary inputs:
add pin equivalences indata2 indata4
add pin equivalences indata3 -invert indata5
report pin equivalences

Related Commands
Add Pin Equivalences Delete Pin Equivalences

638 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Primary Inputs

Report Primary Inputs

Scope: All modes
Usage
REPort PRimary Inputs [-All | net_pathname… | primary_input_pin…] [-Class {Full | User |
System}] [{> | >>} file_pathname]
Description
Displays the specified primary inputs.
The Report Primary Inputs command displays a list of the primary inputs of a circuit. You can
choose to display either the user class, system class, or full classes of primary inputs.
Additionally, you can display all of the primary inputs or a specific list of primary inputs. If you
issue the command without specifying any arguments, then the tool displays all the primary
inputs.
Arguments
• -All
An optional switch that displays all the primary inputs. This is the default.
• net_pathname
An optional repeatable string that specifies the circuit connections whose user-class primary
inputs you want to display.
• primary_input_pin
An optional repeatable string that specifies a list of system-class primary input pins that you
want to display.
• -Class Full | User | System
An optional switch and literal pair that specifies the source (or class) of the primary input
pins which you want to display. The literal choices are as follows:
Full — A literal that displays all the primary input pins in the user and system class. This
is the default.
User — A literal that displays only the user-entered primary input pins.
System — A literal that displays only the netlist-described primary input pins.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.

LBISTArchitect Reference Manual, v2017.3 639

September 2017
Fault Simulation Command Dictionary
Report Primary Inputs

Examples
The following example displays the full classes of primary inputs:
add primary inputs indata2 indata4
report primary inputs -class full

Related Commands
Add Primary Inputs
Delete Primary Inputs

640 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Primary Outputs

Report Primary Outputs

Scope: All modes
Usage
REPort PRimary Outputs [-All | net_pathname… | primary_output_pin…] [-Class {Full | User |
System}] [{> | >>} file_pathname]
Description
Displays the specified primary outputs.
The Report Primary Outputs command displays a list of primary outputs of a circuit. You can
choose to display either the user class, system class, or full classes of primary outputs.
Additionally, you can display all of the primary outputs or a specific list of primary outputs. If
you issue the command without specifying any arguments, then the tool displays all the primary
outputs.
Arguments
• -All
An optional switch that displays all primary outputs. This is the default.
• net_pathname
An optional, repeatable string that specifies the circuit connections whose user-class
primary outputs you want to display.
• primary_output_pin
An optional, repeatable string that specifies a list of system-class primary output pins that
you want to display.
• -Class Full | User | System
An optional switch and literal pair that specifies the source (or class) of the primary output
pins that you want to display. The literal choices are as follows:
Full — A literal that displays all of the primary output pins in the user and system class.
This is the default.
User — A literal that displays only the user-entered primary output pins.
System — A literal that displays only the netlist-described primary output pins.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.

LBISTArchitect Reference Manual, v2017.3 641

September 2017
Fault Simulation Command Dictionary
Report Primary Outputs

Examples
The following example displays all primary outputs in the user class:
add primary outputs outdata1 outdata3 outdata5
report primary outputs -class user

Related Commands
Add Primary Outputs Delete Primary Outputs

642 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Processors

Report Processors
Tools Supported: Tessent FastScan and Tessent TestKompress
Scope: All modes
Usage
REPort PROCESsors [-Verbose]
Description
Displays information about the current distributed processing environment when executing
distributed commands for fault simulation.
The Report Processors command displays the information listed in Table 4-7 for the current
distributed processing environment:
Table 4-7. Default Report Processors Information Display
Column Name Description
hosts/processors Network names of host machines, along with an identification
number for each slave process
arch Architecture of host machines (similar to entering “uname -m”
on each host)
CPU(s) Number of hardware processors and their speed for each host
machine
%idle Current CPU idle percentage (a small interval of time is
sampled)
free RAM A machine’s total free memory
process size Size of the master or slave process

This information enables you to determine whether to use the current set of host machines for
slave processes or whether to use different machines. For example, a host machine with a low
%idle is not as likely to provide as much CPU time to slave processes as one that is 100% idle.
The free RAM may also help you decide which machines to avoid at the present time.
Note
Be sure to consider the number of processors on the host machine when evaluating the
idle percentage (%idle), as a partially idle machine may have one or more completely idle
processors available to run slave processes.

LBISTArchitect Reference Manual, v2017.3 643

September 2017
Fault Simulation Command Dictionary
Report Processors

Arguments
• -Verbose
An optional switch that adds the data listed in Table 4-8 to the normal display:

Table 4-8. Additional Data Displayed by -Verbose

Column Name Description
free swap Total available swap space minus the swap space currently in
use
total RAM Total available RAM
total swap Total available swap space
user CPU Current sum of the time spent executing the master or slave
process
sys CPU Current sum of the time spent in system routines on behalf of
the master or slave process

Note
Mentor Graphics engineers have observed that on certain 64-bit X86 platforms, processes
that should be idle place a small load on the machine. You can see this effect in the
reported CPU times. It has very little impact on the process throughput when actively
performing distributed processing.

Example
The following example summarizes the performance statistics for the current distributed
environment:
report processors
hosts/processors arch CPU(s) %idle free RAM process size
---------------- ------ ----------- ----- ------------ ------------
nemo (master) x86-64 2 x 2.2 GHz 99% 5.82 GB 40.82 GB
ahab 1 x86-64 2 x 2.0 GHz 0% 10.21 GB 20.45 GB
2 20.45 GB

Related Commands
Add Processors Set Distributed
Delete Processors

644 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Scan Cells

Report Scan Cells

Scope: Fault and Good modes
Usage
REPort SCan CElls [-All | chain_name…] [-Display DEBug] [{> | >>} file_pathname]
Description
Displays a report on the scan cells that reside in the specified scan chains.
The Report Scan Cells command provides a report on the scan cells within specific scan chains.
The report provides the following information for each scan cell:
• Chain cell index number, where 0 is the scan cell closest to the scan-out pin.
• Scan chain and the scan chain group in which the scan cell resides
• Memory element type
• Inversion data
• Gate index number
• Instance name
• Model name
• Cell input and output pins
If you issue the command without specifying any arguments, then the tool displays a report on
the scan cells for all scan chains.
Note
Although scan cells are listed in the order of nearest-to-output first, the latch elements
inside one cell are not listed in that order (in fact, the master is always listed first).

Arguments
• -All
An optional switch that displays the scan cells for all scan chains. This is the default.
• chain_name
An optional repeatable string that specifies the scan chains whose scan cells you want to
display.
• -Display DEBug
A switch and literal that displays the reported information graphically in the debug
DFTVisualizer window.

LBISTArchitect Reference Manual, v2017.3 645

September 2017
Fault Simulation Command Dictionary
Report Scan Cells

• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays a list of the scan cells for all the scan chains:
add scan groups group1 scanfile
add scan chains chain1 group1 indata2 outdata4
set system mode fault
report scan cells
cell# chain group mem_type inv. gate# ins_name (ext.pin name)
-------------------------------------------------------------
0 chain1 group1 MASTER FFFF 7402 /MQ_I400 ““ (TI,QN)
1 chain1 group1 MASTER FFFF 7394 /FH_I400 ““ (TI,QN)
2 chain1 group1 MASTER FFFF 7367 /FQ_I10 ““ (TI,QN)
3 chain1 group1 MASTER FFFF 7366 /RP_I10 ““ (TI,QN)
4 chain1 group1 MASTER FFFF 7365 /IS_I10 ““ (TI,QN)
5 chain1 group1 MASTER FFFF 7386 /CZ_I400 ““ (TI,QN)

The first column in the report displays the chain cell index number, where 0 is the scan cell
closest to the scan-out pin.
The second column displays the name of the scan chain in which the scan cell resides.
The third column displays the name of the scan group in which the scan chain resides.
The fourth column displays the scan cell’s type of memory element.
The fifth column contains inversion data using F (false) to indicate no inversion difference and
T (true) to indicate inversion difference. The inversion data has four elements; one for each scan
cell memory element. The report presents the elements (left-to-right) as follows:
1. Inversion of the scan cell input pin, library cell input pin, or scan subchain relative to
the scan chain input pin.
2. Inversion of the scan cell output pin, library cell output pin, or scan subchain relative to
the scan chain output pin.
3. Inversion of the scan cell memory gate relative to the library cell input pin.
4. Inversion of the scan cell memory gate relative to the library cell output pin.
The sixth column displays the gate index number.
The seventh column displays the instance name of the memory element.
The eighth column displays the library instance name. If there is no library instance name, then
the report shows two double-quotes in the library instance name field.

646 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Scan Cells

The last column displays the library cell input and output pins of the scan cell. If the scan cell
input or output pin does not directly connect to the library cell boundary pin, the report shows a
dash (-) in the corresponding pin field.
Related Commands
Add Scan Chains Add Scan Groups

LBISTArchitect Reference Manual, v2017.3 647

September 2017
Fault Simulation Command Dictionary
Report Scan Chains

Report Scan Chains

Scope: All modes
Usage
REPort SCan CHains [{> | >>} file_pathname]
Description
Displays a report on all the current scan chains.
By default, the output of the command is written to the transcript window of the tool. The
Report Scan Chains command provides the following information in a report for each scan
chain:
• Name of the scan chain
• Name of the scan chain group
• Scan chain input and output pins
• Length of the scan chain
• Name of the scan clock(s)
If the DRC E8 handling is set to anything other than Ignore when you leave Setup system mode,
the command additionally lists the clocks you specified to be pulsed in the shift procedure in
your test procedure file. This enhanced report is only available in non-Setup modes. Be aware
that the clocks reported are likely a superset of the clocks that are actually used to clock the scan
cells. For a precise report of the shift clocks, use the Report Scan Cells command.
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays a report of all the scan chains:
add scan groups group1 scanfile
add scan chains chain1 group1 indata2 outdata4
add scan chains chain2 group1 indata3 outdata5
report scan chains

Related Commands
Add Scan Chains Delete Scan Chains

648 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Scan Groups

Report Scan Groups

Scope: All modes
Usage
REPort SCan Groups [{> | >>} file_pathname]
Description
Displays a report on all the current scan chain groups.
By default, the output of the command is written to the transcript window of the tool. The
Report Scan Groups command provides the following information in a report for each scan
chain group:
• Name of the scan chain group
• Number of scan chains within the scan chain group
• Number of shifts
• Name of the test procedure file, which contains the information for controlling the scan
chains in the reported scan chain group
Arguments
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays a report of all the scan groups:
add scan groups group1 scanfile
add scan groups group2 scanfile1
report scan groups

Related Commands
Add Scan Groups Delete Scan Groups

LBISTArchitect Reference Manual, v2017.3 649

September 2017
Fault Simulation Command Dictionary
Report Statistics

Report Statistics
Scope: All modes
Usage
REPort STAtistics [-Instance instance_pathname] [{> | >>} file_pathname]
Description
Displays a detailed report of the design’s simulation statistics.
The Report Statistics command displays a detailed statistics report to the screen. The statistics
report lists the following three groups of information:
• The current number of collapsed and total faults in each class. The report does not
display fault classes with no members.
• The percentage of test coverage, fault coverage, and ATPG effectiveness for both
collapsed and total faults
• The total numbers for the following:
o Total patterns simulated in the preceding fault simulation process. This subgroup
may additionally contain total numbers for the following internal patterns sets:
basic scan patterns
Clock_po patterns
Ram_sequential patterns
Clock_sequential patterns
o Total patterns currently in the test pattern set
o Total CPU time
If a pattern type has no patterns, the report does not display the count for that type. If all patterns
are basic patterns, it will not display any count. And it counts clock_sequential patterns that are
also clock_po only as clock_sequential patterns.
Arguments
• -Instance instance_pathname
An optional switch and string pair that allows fault statistics to be reported for a specific
instance. The instance_pathname is the name of a circuit block whose statistics you want to
report. Only fault statistics are affected by this option; pattern count statistics apply to the
entire design.
As illustrated in Figure 4-2, this switch uses the representative fault to determine whether to
include a fault in the count for the specified block. For more information about
representative faults, refer to the Fault Collapsing and Fault Reporting sections in the Scan
and ATPG User’s Manual.

650 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Statistics

Figure 4-2. How the -Instance Switch Determines Fault Counts

Equiv. faults included in B’s count
Representative fault
in instance B: s-a-0 s-a-0 s-a-0 s-a-1

Instance A Instance B Instance C

Representative fault
in instance A Equiv. faults excluded from B’s count

• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays a statistics report after performing BIST simulation:
set system mode fault
add faults -all
run
report statistics

The following shows a statistics report for the Report Statistics command:
Statistics report
--------------------------------------
#faults #faults
fault Class (coll.) (total)
--------------------------------------
FU (full) 15923 39904
--------------------------------------
DS (det_simulation) 11333 32714
DI (det_implication) 2730 4578
UU (unused) 1039 1202
TI (tied) 435 604
BL (blocked) 22 28
RE (redundant) 364 778
--------------------------------------
test_coverage 100.00% 100.00%
fault_coverage 88.32% 93.45%
atpg_effectiveness 100.00% 100.00%

LBISTArchitect Reference Manual, v2017.3 651

September 2017
Fault Simulation Command Dictionary
Report Statistics

--------------------------------------
#test_patterns 383
#basic_patterns 259
#clock_po_patterns 124
#simulated_patterns 864
CPU_time (secs) 28.2

FlexTest Example
The following shows a FlexTest statistics report for the Report Statistics command:
Total number of sequential instances = 2
*****Circuit Statistics*****
# of primary inputs = 12
# of primary outputs = 6
# of library model instances = 14
# of combinational gates = 12
# of sequential elements = 2
# of simulation primitives = 62
# of scan cells = 2
# of scan sequential elements = 2
*****Fault List Statistics*****
Fault Class Uncollapsed Collapsed
Full (FU) 120 56
Det_simulation (DS) 72 28
Det_implication (DI) 48 28
Fault coverage 100.00% 100.00%
Test coverage 100.00% 100.00%
Atpg effectiveness 100.00% 100.00%
*****Test Patterns Statistics*****
Total Test Cycles Generated = 26
Total Scan Operations Generated = 13
Total Test Cycles Simulated = 26
Total Scan Operations Simulated = 13
***** Runtime Statistics *****
Machine Name : checklogic
User Name : Steve
User CPU Time : 1.9 seconds
System CPU Time : .6 seconds
Memory Used : 2.137M

652 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Tied Signals

Report Tied Signals

Scope: All modes
Usage
REPort TIed Signals [-Class {Full | User | System}] [{> | >>} file_pathname]
Description
Displays a list of the tied floating signals and pins.
The Report Tied Signals command displays either the user class, system class, or full classes of
tied floating signals and pins. If you do not specify a class, the command displays all the tied
floating signals and pins.
Arguments
• -Class Full | User | System
An optional switch and literal pair that specifies the source (or class) of the tied floating
signals or pins which you want to display. The literal choices are as follows:
Full — A literal that displays all the tied floating signals or pins in the user and system
class. This is the default.
User — A literal that displays only the tied floating signals or pins created using the Add
Tied Signals command. This includes all instance-based blackbox tied signals.
System — A literal that displays only the netlist-described tied floating signals or pins.
• > 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, used at the end of the argument list, for
appending to the contents of file_pathname.
Examples
The following example displays the tied floating signals from the user class:
add tied signals 1 vcc vdd
report tied signals -class user

Related Commands
Add Tied Signals Setup Tied Signals
Delete Tied Signals

LBISTArchitect Reference Manual, v2017.3 653

September 2017
Fault Simulation Command Dictionary
Report Variables

Report Variables
Scope: All modes
Usage
REPort VAriables
Description
Displays user-defined variables and values.
The Report Variables command displays variables you previously defined within the tool and
their corresponding values. This does not include environment variables defined in the parent
shell environment.
You define, reference, and report on user-defined variables as follows:
• Defining — You can define a variable from the tool’s command line, from a dofile, or
from a startup file. Variable names are case sensitive. Use the following syntax to create
and set a variable’s value:
$variable = value

• Referencing — After a variable is defined, you can reference it in a tool command in

one of two ways to cause the variable’s value to be substituted into the command:
o If the variable is concatenated with any other string, it must be referenced as
${variable-name}, as in this example:
$design_base_file = my_transition_patt
$design_base_dir = /my_test_patterns/my_patterns
save patterns ${design_base_dir}/${design_base_file}.v -verilog

o If the variable is not meant to be concatenated with any other string, it can be
referenced simply as $variable-name. For example:
$INDENT = 8
report statistics -hierarchy -indent $INDENT

Multiple references are allowed in a single command. A reference to an undefined

variable results in a syntax error.
• Reporting — Use the Report Variables command to display user-defined variables and
values:
report variables
INDENT 8
design_base_dir /my_test_patterns/my_patterns
design_base_file my_transition_patt

654 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Report Variables

Examples
The following example defines two variables, refers to them within a tool command, and
displays a list of all user-defined variables:
...
$design_base_file = my_transition_patt
$design_base_dir = $HOME/my_patterns
save patterns ${design_base_dir}/${design_base_file}.v -verilog
report variables
design_base_dir $HOME/my_patterns
design_base_file my_transition_patt

Note
As $HOME is defined in the parent shell environment, it is available for use within the
tool and in other variable definitions.

LBISTArchitect Reference Manual, v2017.3 655

September 2017
Fault Simulation Command Dictionary
Report Version Data

Report Version Data

Scope: All modes
Usage
REPort VErsion Data [{> | >>} file_pathname]
Description
Displays the current software version information.
The Report Version Data command displays information relating to the software title, version,
and date.
Arguments
• > 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 for appending to the contents of
file_pathname.
Example
The following is an example of the Report Version Data display information:
Version data: LBISTArchitect v8.2004_1.10 Mon Feb 9 22:43:45 PST 2004

656 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Reset Di Faults

Reset Di Faults
Scope: Fault and good modes
Usage
RESet DI Faults {-ALL | -END_of_chains | -CHain chain_name | pin_pathname}
[-Stuck_at {01 | 0 | 1}] [-Both | -Rise | -Fall]
Description
Re-classifies DI faults to UC.
The Reset Di Faults command re-classifies det_implication (DI) faults to the uncontrolled (UC)
category. When the fault type is stuck-at or transition, this command by default resets both
stuck-at-0 (or slow-to-rise for transition faults) and stuck-at-1 (or slow-to-fall for transition
faults) faults at each DI fault site. You can use one of the optional switches to reset just one,
rather than both, faults at each DI fault site.
Use this command when you want faults that were previously classified as DI (and thus no
longer targeted for detection) retargeted in the next run. For example, the tool currently declares
scan path faults DI because they are tested by the chain test. This is not optimal in some cases;
the end of each scan chain (after the last scan cell) is often used as a system path and it is
sometimes desirable to create an at-speed transition fault test to exercise this path. The DI fault
category prevents the tool from targeting or simulating such faults. When the fault classification
is changed to UC, the tool then has the ability to target those faults.
• -ALL
A switch that specifies for the tool to reset all unprotected DI faults to UC. This is the
invocation default.
• -END_of_chains
A switch that specifies to reset, for each scan chain, the unprotected scan path DI faults from
the output of the last scan cell in the chain to the scan output pin.
• -CHain chain_name
A switch and string pair that specifies to reset the unprotected DI faults along the specified
scan chain to UC. This includes scan input and output pin faults.
• pin_pathname
A string that specifies to reset the unprotected DI faults on a particular pin. The
pin_pathname must be an instance/pin name that exists in the flattened model. These are
typically model boundary pins, primary input pins, and primary output pins.

LBISTArchitect Reference Manual, v2017.3 657

September 2017
Fault Simulation Command Dictionary
Reset Di Faults

• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies which unprotected DI faults to reset to UC.
Mentor Graphics recommends you use this switch only if the fault type is stuck; the tool
accepts it, however, regardless of fault type.
01 — A literal specifying that for stuck-at faults the tool reset both the “stuck-at-0” and
“stuck-at-1” faults; or for transition faults the tool reset both “slow-to-rise” and
“slow-to-fall” faults. This is the default.
0 — A literal specifying that for stuck-at faults the tool reset only the “stuck-at-0” faults;
or for transition faults the tool reset only “slow-to-rise” faults.
1 — A literal specifying that for stuck-at faults the tool reset only the “stuck-at-1” faults;
or for transition faults the tool reset only “slow-to-fall” faults.
• -Both | -Rise | -Fall
Optional switches that specify which unprotected transition faults to reset to UC. These
switches apply to transition faults only.
-Both - An optional switch that specifies to reset both slow-to-rise and slow-to-fall
transition faults. This is the default.
-Rise - An optional switch that specifies to reset only the slow-to-rise transition faults.
-Fall - An optional switch that specifies to reset only the slow-to-fall transition faults.
Examples
The following example resets all unprotected stuck-at-0 and stuck-at-1 DI faults (including
clock faults) to UC.
reset di faults

The next example resets all unprotected stuck-at-0 faults declared DI anywhere in the netlist.
reset di faults -stuck_at 0

The next example resets stuck-at-0 and stuck-at-1 DI faults at the output of the last cell of each
chain.
reset di faults -end_of_chain

The next example resets only the slow-to-rise transition fault at the output of the last cell of each
chain.
reset di faults -end_of_chain -rise

The next example resets any DI fault anywhere along chain1.

reset di faults -chain chain1

The next example resets both DI faults at pin /top/mid/bottom/Q if unprotected (any type fault).
reset di faults /top/mid/bottom/Q -stuck_at 01

658 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Reset Di Faults

The next example is equivalent to the preceding example, except that it applies to transition
faults only.
reset di faults /top/mid/bottom/Q -both

The next example uses the defaults to reset DI faults at the specified location (any fault type).
reset di faults /top/mid/bottom/Q

The next example resets only the slow-to-rise transition fault at the specified location.
reset di faults /top/mid/bottom/Q -rise

The next example resets only the stuck-at-1 fault (or slow-to-rise if transition fault) at the
specified location.
reset di faults /top/mid/bottom/Q -stuck_at 1

Related Commands
Load Faults

LBISTArchitect Reference Manual, v2017.3 659

September 2017
Fault Simulation Command Dictionary
Run

Run
Scope: Fault and Good modes
Usage
RUN [-RETain_abort] [-NOAnalyze]
Description
Runs a simulation.
The Run command performs a fault or good simulation using the current test pattern source. To
terminate the simulation, use Control-C. You can utilize multiple processors simultaneously on
specified host machines when executing distributed commands for fault simulation.
You can repeat the Run command as often as you want to further increase test coverage. If a run
analysis fails to satisfy all ATPG restrictions prior to test generation, you will be notified of the
existence of these test generation problems and the run will be terminated. At this point, you
may choose to either 1) continue the run analysis, but ignore the problems by re-issuing the Run
command with the -Noanalyze switch, or 2) use the Analyze Restrictions command to find the
source of the problems.
Arguments
• -RETain_abort
An optional switch that specifies to not target any aborted faults that were the result of
aborting the previous run.
• -NOAnalyze
An optional switch that specifies for the tool to skip the analysis of test generation problems.
Examples
The following example runs a good simulation after adding all faults to the circuit:
set system mode good
add faults -all
run

The following example runs an ATPG process after adding all faults to the circuit, terminates
the run with a Control-C, and re-runs the ATPG process while not targeting any aborted faults
from the previous run:
set system mode atpg
add faults -all
run
Control-C
run -retain_abort

Related Commands
Report Gates Set Pattern Source
Set System Mode Set Logfile Handling

660 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Save Flattened Model

Save Flattened Model

Note
This command is auto-generated by the BIST Controller Generation phase and is not
intended for interactive use; it is documented for reference purposes only.

Usage
SAVe FLattened Model filename [-Replace]
Description
Saves the flattened circuit model, the scan trace, and all DRC-related information to a binary
file.
When you issue the Save BIST command during the BIST Controller Generation phase,
LBISTArchitect automatically adds the Save Flattened Model command to the
enitity_core_faultsim.do file. This dofile is later executed upon invocation of the fault
simulation phase.
LBISTArchitect writes the enitity.flat circuit model for later use during diagnostics with Tessent
Diagnosis.
Arguments
• filename
A required string that specifies the name of the file to which you want to write the flattened
circuit model. By default, the file is named “enitity.flat”. If you need to change the default
file name, you must use the “Setup File Naming -FLat_model” command within the BIST
Controller Generation phase before you issue the Save Bist command.
• -Replace
An optional argument that lets you overwrite an existing circuit model file.
Related Commands

LBISTArchitect Reference Manual, v2017.3 661

September 2017
Fault Simulation Command Dictionary
Save History

Save History
Scope: All modes
Usage
SAVe HIstory filename [-Replace]
Description
Saves the command line history file to the specified file.
The Save History command saves the list of previously-executed commands in the file that you
specify. You can then execute the file using the Dofile command.
Arguments
• filename
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.
history -nonumbers
dof fault.do
set system mode fault
add faults -all
run
report statistics
history -nonumbers

save history my_history -replace

Related Commands
Dofile
History

662 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Save Patterns

Save Patterns
Scope: Fault and good modes
Prerequisites
You may use this command if you first use the Set Pattern Source command with the
-Store_patterns option, after simulating in Good mode.
Usage
SAVe PAtterns pattern_filename [-Replace] [format_switch]
[timing_filename [-TIMingfile] | {{proc_filename -PROcfile} [-NAme_match | -
POsition_match] [-PARAMeter param_filename]}] [-PARALlel | -Serial]
[-NOInitialization] [-BEgin {pattern_number | pattern_name}]
[-END {pattern_number | pattern_name}] [-TAg tag_name] [-CEll_placement {Bottom |
Top | None}] [-ENVironment] [-One_setup] [-ALl_test | -CHain_test | -SCan_test]
[-NOPadding | -PAD0 | -PAD1] [-Noz] [-MAP mapping_file] [-PATtern_size integer]
[-MAXloads load_number]
Description
Saves the current test pattern set to a file in the format that you specify.
You can save the patterns in several different formats. The format_switch argument supports an
extensive list of formats. When saving your patterns using the Save Patterns command, choose
the format_switch that best suits your needs.
The module name created for the Verilog test bench, using enhanced pattern outputs via the
-PROcfile switch, is determined by the pattern_filename specified on the Save Patterns
command line. The module name consists of the design name, followed by an underscore,
followed by the file name (minus any path names), followed by “_ctl”. Additionally, any
periods (“.”) in the pattern_filename are converted to underscores (“_”). This lets you change
the module name in the test bench by changing the name of the file on the Save Patterns
command line. See the Example 1 section of this command for an example of the module name
in the test bench that the tool creates.
By default, when you are not using the -Procfile switch, the module name created consists of the
design name followed by “_ctl”.
Note
You can cleanly stop the Save Patterns command by typing Ctrl-C from the command
line.

Arguments
• pattern_filename
A required string that specifies the name of the file to which you want to write the test
pattern set. If the filename ends with “.gz”, the tool automatically compresses the file using

LBISTArchitect Reference Manual, v2017.3 663

September 2017
Fault Simulation Command Dictionary
Save Patterns

the GNU gzip utility, as part of the save operation. If the filename ends with “.Z”, the tool
uses the UNIX compress utility to compress the file during the save operation.
Note
Normally, automatic file compression is enabled by default, and all you do to use the
compression capability is apply one of the two extensions to your filenames. You can
turn off the file compression functionality with the Set File Compression command. This
could be useful, for example, in the unlikely event that files had either of the compressed
file extensions, but were not actually compressed files.

• -Replace
An optional switch that specifies replacement of the contents of pattern_filename, if a file
by that name already exists.
• format_switch
An optional switch that specifies the format in which you want to save the test pattern set.
The formats divide into three groups. The first group lists the general purpose formats. The
second group lists the simulation and test formats. The third group lists the ASIC vendor
formats.
The general purpose format switch choices are as follows:
-Ascii — A switch that writes the patterns in the standard ASCII format. The ASCII
format includes the statistics report, environment settings, scan structure definition,
scan chain functional test, scan test patterns, and the scan cell information. This is the
command’s default. For more information on the ASCII BIST pattern format, see
“BIST Pattern File Format” in the Scan and ATPG User’s Manual.
The three types of ASCII BIST patterns are:
o BIST patterns in Tessent FastScan format with LFSM values which include both
LFSM values and pattern internal view — Default. This pattern type is generated
when you specify a format using the following command:
set pattern source BIST -store_patterns

o BIST patterns in Tessent FastScan-like format — These patterns are treated as

normal Tessent FastScan patterns. This pattern type is generated when you specify a
format using the following command:
set pattern source BIST -store_patterns -exclude_lfsm_value

o BIST patterns with LFSM values only — This pattern type is generated when you
specify a format using the following command:
set pattern source BIST -store_patterns -lfsm_value_only

If you use the -External or the -Begin and -End switches, thereby not saving all the
internal patterns, the tool does not include test coverage and fault information in the
ASCII pattern set.
-BInary — A switch that writes the patterns in binary format.

664 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Save Patterns

The simulation and test format switch choices are as follows:

-Wgl — A switch that writes the patterns in the WGL format. The WGL format contains
the waveform pattern information and any timing information from the timing file.
You can use the WGL format patterns to generate test patterns in a variety of tester
and simulator formats.
-Verilog — A switch that writes the patterns in the Verilog format. The Verilog format
contains pattern information and timing information from the timing file as a
sequence of events. You can use the Verilog format patterns to interface to the
Verilog-XL and Verifault simulators. Also, you can customize the output format
when you utilize the parameter file.
Note
Any time you save the pattern set in an ASIC vendor data format, you should also save
the patterns in the ASCII format as backup. This is in case you want to read in the
patterns from an external file using the Set Pattern Source External command. The tool
can only read in the ASCII pattern format or binary format.

Many ASIC vendors accept test pattern data in their own test data formats. ASIC vendor test
data formats usually support only a single timing file. You can specify the test timing that
each ASIC vendor requires by using different timing definition files for each format.
The ASIC vendor format switch choices are as follows:
-Fjtdl — A switch that writes the patterns in the Fujitsu FTDL-E format.
-MItdl — A switch that writes the patterns in the Mitsubishi MITDL format.
-Mode Lsi — A switch that changes the functionality of the Verilog and WGL output
formats so that the saved pattern files meet LSI Logic requirements. This switch is
valid only with the -Verilog and -wgl switches.
-STil — A switch that writes the patterns in the STIL format. Also, you can customize
the output format when you utilize the parameter file.
-TItdl — A switch that writes the patterns in the Texas Instruments TDL91 format.
Also, you can customize the output format when you utilize the parameter file.
Note
If the design uses a single timeplate, the tool changes the TDL version to the 4.3 format.
This removes the TIMING, END_TIMING, and SET_TIMING statements from the
pattern file. Also, the VERSION statement changes from 6.0 to 4.3. However, if the
design uses multiple timeplates, then the TDL version is set to 6.0.

-TSTl2 — A switch that writes the patterns in Toshiba Standard Tester Interface
Language 2.

LBISTArchitect Reference Manual, v2017.3 665

September 2017
Fault Simulation Command Dictionary
Save Patterns

• -NOInitialization
A switch that writes patterns without creating the initialization cycle in the pattern file. The
-Noinitialization switch is valid with the following output pattern formats:

Table 4-9. Supported -Noinitialization Output Pattern Formats

STil Verilog
WGl (Ascii and Binary)

The -Noinitialization switch is valid with all enhanced output pattern formats.
• timing_filename [-TIMingfile]
An optional string and optional switch that specifies the name of the timing plate file from
which you want to read the non-scan event timing information. This option causes the tool
to save patterns using the old output pattern, which gets its timing information from the
timing file specified on the command line. See the “Test Pattern Formatting and Timing”
section in the Scan and ATPG User’s Manual for the description of the timing file and how
to create it. You cannot use this argument with the -Ascii or -Binary formats.
• proc_filename -PROcfile
An optional string and switch that specifies the name of the enhanced procedure file from
which you want to read the non-scan event timing information. This option causes the tool
to save patterns using the output pattern, which retrieves its timing information from the
enhanced procedure file. You can specify the procedure filename with this argument or
specify it before using this command by issuing the Read Procfile command. You cannot
use this argument with the -Ascii or -B-inary formats. This is the default.
When an invalid output format is used with the -Procfile option, the tool displays the
following error message:
Procfile patterns cannot be saved in <format> form, use the -
Timingfile option.

Where <format> is the pattern format specified on the command line.

• -NAme_match
An optional switch that specifies for the tool to use the name matching method to instantiate
the device under test in the test bench. This is the default.
Note
The -Name_match switch is valid only when using -Verilog outputs in conjunction with
the -Procfile switch

If you start with a Verilog netlist and then do not restart with a flattened model, the pattern
Verilog output will automatically switch to using the position match method.

666 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Save Patterns

• -POsition_match
An optional switch that specifies for the tool to use the position matching method to
instantiate the device under test in the test bench.
Note
The -Position_match switch is valid only when using -Verilog outputs in conjunction
with the -Procfile switch

• -PATtern_size integer
A optional switch and integer pair which specifies the size of the memory buffer and pattern
file in which to save. Integer is given in kilobytes.
Note
The -Pattern_size switch is valid only when using -Verilog output in conjunction with the
-Procfile switch.

The default pattern size is 32MB. However, any size specified for a pattern size will be
adjusted to hold a multiple of the largest pattern. For example, if the largest pattern requires
3MB for one pattern, then the file size will be a multiple of 3MB, which would result in a
30MB pattern size.
• -PARAMeter param_filename
An optional switch and string pair that specifies field names and values for use in certain
output pattern formats.
• -PARALlel
An optional switch that saves all scan cells in parallel. This is the default.
In designs with scan cells, only scan pins are active during the scan shift cycles. If the tool
tries to represent the state of each pin during each shift cycle, it may produce very large
pattern files. Simulating the shift operations of these patterns might require a considerable
amount of time if you use a different simulator. You can avoid these problems by saving all
scan cells in parallel. You can use the -Parallel switch with all formats.
• -Serial
An optional switch that saves all scan cells in series. You can only use this switch with the -
STil, -TItdl (enhanced pattern output only), -wgl, or -Verilog format type switches.
• -BEgin {pattern_number | pattern_name}
An optional switch that specifies the pattern at which you want the command to begin
storing patterns.
pattern_number — An integer that specifies the number of the pattern at which you
want the command to begin storing patterns. The default pattern number is 0.

LBISTArchitect Reference Manual, v2017.3 667

September 2017
Fault Simulation Command Dictionary
Save Patterns

pattern_name — A string generated by using the -tag switch (which specifies a prefix
for all pattern names). For example, pattern_name = tag_name_1, tag_name_2, and
so on.
If you save only a portion of the internal patterns in the -Ascii format, the tool does not
include test coverage and fault information.
• -END {pattern_number | pattern_name}
An optional switch that specifies the number of the pattern at which you want the command
to stop storing patterns. This argument is inclusive; therefore, the tool stores the pattern
identified by the pattern_number | pattern_name you specify. The default pattern is the last
pattern of the pattern set.
pattern_number — An integer that specifies the number of the pattern at which you
want the command to stop storing patterns.
pattern_name — A string generated by using the -tag switch (which specifies a prefix
for all pattern names). For example, pattern_name = tag_name_1, tag_name_2, etc.
If you save only a portion of the internal patterns in the -Ascii format, the tool does not
include test coverage and fault information.
• -TAg tag_name
An optional switch that adds a unique user-specified label, tag_name, to each pattern. All
chain tests automatically have “chain” as the tag_name regardless of the tag_name given in
the -Tag switch. Since all tag names must be unique, “chain” is not a valid tag_name. If the
tag_name supplied is not unique, an error message is issued and the run aborts.
If the tool reads in patterns using the Set Pattern External command, the patterns must also
be unique. The run aborts if LBISTArchitect attempts to make two identically named
patterns co-resident by any method. This uniqueness extends across both the internal and
external pattern sets. It is not possible to have the same pattern_name in the internal and
external sets.
• -CEll_placement Bottom | Top | None
An optional switch and literal pair that controls the placement of the scan cell data in the
ASCII pattern file. The literal choices are as follows.
Bottom — A literal that places the scan data after the patterns, at the end of the file. This
is the default.
Top — A literal that places the scan data before the patterns, at the top of the file.
None — A literal that excludes the scan data from the file.
• -ENVironment
An optional switch that includes information about the current LBISTArchitect environment
into the pattern file as comments. The information includes the identification stamp number,
the environment settings, and the DRC rules. The information is the same as the Report
Environment and Report ID Stamp commands display.

668 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Save Patterns

• -One_setup
An optional switch that specifies for the tool to apply only one test setup procedure when
both chain and scan test patterns are saved in one pattern file. The tool applies the single test
setup procedure before the chain test patterns. The default behavior causes the tool to apply
one test setup procedure before the chain test patterns and another before the scan test
patterns.
• -ALl_test
An optional switch that specifies to save both the chain test and the scan test
• -CHain_test
An optional switch that specifies for the tool to save only the chain test in the pattern file.
• -SCan_test
An optional switch that specifies to save only the scan test in the pattern file.
• -Noz
An optional switch that changes all Z output values to the value specified by the last Set Z
Handling command.
• -NOPadding (ASCII patterns only)
An optional switch that saves the ASCII patterns with unpadded scan load and load data.
The tool eliminates the extra X values that are due to short scan chains. This is the default.
You can only use this switch with the -Ascii format type switch.
If you subsequently input unpadded ASCII patterns into the tool, you must use the Set
Pattern Source command with its -Nopadding switch.
• -PAD0 (ASCII patterns only)
An optional switch that saves the ASCII patterns with values of 0 for don’t care inputs and
scan chain inputs of short scan chains.
• -PAD1 (ASCII patterns only)
An optional switch that saves the ASCII patterns with values of 1 for don’t care inputs and
scan chain inputs of short scan chains.
• -MAxloads load_number
An optional switch and string pair that specifies the number of scan loads, load_number, to
include in a pattern file. Much like the -Begin and -End switches, the -Maxloads switch
automatically breaks up the pattern file into a series of pattern files with the specified
number of scan loads in each. This switch is equivalent to the following series of
commands:
Save Patterns filename_0 -begin 0 -end j
Save Patterns filename_1 -begin j+1 -end k
Save Patterns filename_2 -begin k+1 -end l
...

LBISTArchitect Reference Manual, v2017.3 669

September 2017
Fault Simulation Command Dictionary
Save Patterns

Where filename is the name of the file given in the Save Patterns command; and j, k, and l
are integers.
Note
This switch is only valid with ASCII, Binary, and enhanced output patterns, and cannot
be used with the -Pattern_size switch.

Example 1
The following example performs a Good simulation run on the BIST patterns, and then saves
the patterns to a file in the Verilog format:
set pattern source bist -store_patterns
set system mode good
add faults -all
run
save patterns file1 -verilog

Example 2
The following example illustrates the module name created in the enhanced Verilog output
when using the -Procfile switch. If the design name is “MAIN” and you issue the following
Save Patterns command, the module name in the test bench will be “MAIN_pattern1_pat_ctl”.:
save patterns pattern1.pat -procfile -verilog -replace

Related Commands
Add Scan Groups Set Pattern Source
Save Patterns

670 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set BIST Chain_test

Set BIST Chain_test

Scope: All modes
Usage
SET BIst Chain_test [None | number_of_patterns]
Description
Disables all capture clock activity for the specified number of patterns in the fault simulation
during execution of the chain test.
By default, the tool runs a 32 pattern chain test and disables all capture clock activity for those
32 patterns, which means that the unload values will exactly match the load values during those
patterns. You can change the default settings by using “Set Lbist Controller -Chain_test”
command during the BIST Controller Generation phase to specify a different number of
pseudo-random patterns for the chain test, turn off the chain test, or change to a flush test.
The “Set Lbist Controller -Chain_test” command causes the tool to modify the RTL so that no
capture clock signals are generated during the capture window while the tool executes the chain
test patterns. This test produces a different MISR signature than when using the “Set Lbist
Controller -Flush_test” command.
Arguments
• None
An optional literal that specifies that the tool should not disable the capture clock activity
since there is no chain test being ran.
• number_of_patterns
An optional integer that specifies for the tool to disable all capture clock activity for the
number of chain test patterns that are to be driven through the scan chains, which is 32 by
default.
Examples
The following example changes the length of the chain test from the default of 32 to 64. In the
BIST Controller phase, issue the following command.
set lbist controller -chain_test 64

Then, in the fault simulation phase, the configuration file will automatically contain the
following command:
set bist chain_test 64

This next example stops the chain test and replaces it with a 64 pattern flush test.
set lbist controller -flush_test 64

LBISTArchitect Reference Manual, v2017.3 671

September 2017
Fault Simulation Command Dictionary
Set BIST Chain_test

Then, in the fault simulation phase, the configuration file automatically contains a command
similar to the following, which removes the default capture clock disabling.
set bist chain_test none

Related Commands
Set Lbist Controller

672 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set BIST Debug

Set BIST Debug

Scope: All modes
Prerequisites
You must define LFSRs with the Add LFSRs command before you can use them in
LFSR_name.
Usage
SET BIst Debug -None | [LFSR_name… {pattern_number | All}]
Description
Sets up a trace of LFSR(s) value during a pattern’s shift cycles.
To facilitate signature mismatch debugging and other diagnostics, the Set BIST Debug
command enables the tracing of all specified MISR and PRPG values associated with a given
pattern, or all BIST patterns.
Arguments
• -None
A switch that clears the list of PRPGs and MISRs that the tool is currently monitoring.
• LFSR_name
A repeatable string that specifies the name of the MISRs and PRPGs whose values
LBISTArchitect will trace.
Of the next two arguments, you must choose one.
• pattern_number
An integer that specifies the number of the pattern during whose shift cycles the tracing
occurs.
• All
A literal that specifies to write out the value of the specified MISRs and PRPGs only at the
end of the pattern, for every pattern.
Examples
The following example initiates a trace on the values of both the MISR and the PRPG for the
pattern, 61, and shows the resulting transcript:
// command: set bist debug misr prpg 61

// command: run
// ---------------------------------------------------------------------
// Simulation performed for #gates = 5732 #faults = 418
// system mode = fault simulation pattern source = 63 BIST patterns
// ---------------------------------------------------------------------
// #patterns test #faults #faults # eff. # test process
// simulated coverage in list detected patterns patterns CPU time

LBISTArchitect Reference Manual, v2017.3 673

September 2017
Fault Simulation Command Dictionary
Set BIST Debug

// begin bist patterns: capture clock = /clk, observe point = MASTER

begin debug data for PRPGs pattern = 61
PRPG prpg 0 1000001111111010
PRPG prpg 1 0100000111111101
PRPG prpg 2 1001010011111110
PRPG prpg 3 0100101001111111
.
.
.
PRPG prpg 14 0101011110010010
PRPG prpg 15 0010101111001001
PRPG prpg 16 1010000111100100
// 63 88.68% 387 31 5 0 0.04 sec
begin debug data for MISRs pattern = 61
MISR misr 1 1110110100100111
MISR misr 2 0111011010111110
MISR misr 3 0011101100111111
MISR misr 4 0001110111111111
.
.
.
MISR misr 16 1100100000101111
MISR misr 17 1100100000101111

The next example initiates a trace on the values of the PRPG and MISR for all patterns:
// command: set bist debug misr prpg all

// command: run
// ---------------------------------------------------------------------
// Simulation performed for #gates = 5912 #faults = 513
// system mode = fault simulation pattern source = 63 BIST patterns
// ---------------------------------------------------------------------
// #patterns test #faults #faults # eff. # test process
// simulated coverage in list detected patterns patterns CPU time
// begin bist patterns: capture clock = /clk, observe point = MASTER
PRPG prpg 0 0001001000001001
PRPG prpg 1 0011001000011010
PRPG prpg 2 0010111111001111
PRPG prpg 3 0110011101111011
.
.
.
PRPG prpg 29 0001101111101000
PRPG prpg 30 0100010010110000
PRPG prpg 31 1110101100101111
MISR misr 0 0101010100001101
MISR misr 1 1101011101111111
MISR misr 2 1101010001101001
MISR misr 3 1110000010111001
.
.
.
MISR misr 29 0010001111001110
MISR misr 30 1111000010000110
MISR misr 31 1111001001110101
PRPG prpg 32 1000110000011000
PRPG prpg 33 0101010011111101

674 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set BIST Debug

PRPG prpg 34 0100001010111010

.
.
.
PRPG prpg 60 1000001111111010
PRPG prpg 61 1010000111100100
PRPG prpg 62 0000000110101110
// 63 86.05% 488 25 3 0 0.10 sec
MISR misr 32 1000101100100001
MISR misr 33 0010101011010011
MISR misr 34 1001100110111101
.
.
.
MISR misr 60 1011110010101001
MISR misr 61 0011100101011010
MISR misr 62 0001111111111100

Related Commands
Set BIST Trace Add LFSRs

Command Summary

LBISTArchitect Reference Manual, v2017.3 675

September 2017
Fault Simulation Command Dictionary
Set BIST Trace

Set BIST Trace

Scope: All modes
Usage
SET BIst Trace [-Nolfsr | {-Lfsr filename [-Replace] [-Interval interval] [-Offset offset]}]
Description
Turns on the ability to trace PRPG and MISR values after each BIST pattern.
To facilitate signature mismatch debugging and other diagnostics, the Set BIST Trace command
enables the tracing of PRPG and MISR values associated with each BIST pattern. The traced
values are logged in filename, using the following format:

0 PRPG prpg 1111111111111111

0 MISR misr 11111111111111111111
1 PRPG prpg 1001010001011000
2 PRPG prpg 0101111001100101
…
32 PRPG prpg 1100100000000110
1 MISR misr 11100111011000010110
2 MISR misr 11001110011100001110
3 MISR misr 01011001100111011001
…
32 MISR misr 01011001100111011001
32 PRPG prpg 1100100000000110
…

The first element on each line is the pattern number, followed by the simulated element type
(MISR or PRPG). The third element is the name of the simulated element. The names shown in
the example above are the default names assigned by the Add LFSR commands included in the
BIST-Controller-phase-generated fault simulation driver. You can edit the driver file to rename
the elements.

Note
Do not modify or delete any header information in filename. LBISTArchitect generates
the microcoded test bench instructions based on information in this header.

The sequence of activities that occur within the simulation of the BIST controller determines
the order of the lines in filename.

If you issue multiple Set BIST Trace commands before the Run command, LBISTArchitect
only executes the last one issued.

To reduce the volume of data written to filename, use the -Interval and -Offset switches. See the
Examples section for this command.

676 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set BIST Trace

Arguments
• -Nolfsr
An optional switch that specifies to not enable LFSR value tracing. This is the invocation
default.
• -Lfsr filename
An optional switch and string pair that specifies to enable tracing of PRPG and MISR values
during a BIST run and to write those values to the file, filename.
• -Replace
An optional switch that specifies to replace the contents of filename if that file already
exists.
• -Interval interval
An optional switch and integer pair that specifies to write the PRPG and MISR values to
filename for the patterns beginning at 0 and separated by the interval given by the integer,
interval. The values for the first and last patterns are always written.
• -Offset offset
An optional switch and integer pair that specifies to write the PRPG and MISR values to
filename beginning at the pattern number given by the integer, offset. The values for the first
and last patterns are always written.
Examples
The following example writes traced values to the file, lfsr.trace, but to conserve disk space,
only writes the values for every 256th pattern.
set bist trace -lfsr lfsr.trace -replace -interval 256

If, in the preceding example, you discover a problem begins after pattern 1530, you might
narrow the search with the following command:

set bist trace -lfsr lfsr.trace -replace -offset 1530 -interval 16

and then finish with:

set bist trace -lfsr lfsr.trace -replace -offset 1594

Related Commands
Set BIST Debug

Command Summary

LBISTArchitect Reference Manual, v2017.3 677

September 2017
Fault Simulation Command Dictionary
Set Capture Clock

Set Capture Clock

Scope: All modes
Usage
SET CApture Clock primary_input_pin [-Atpg]
Description
Specifies the capture clock name for pseudorandom pattern simulation.
You can use the Report Environment command to list the capture clock and the Report Clocks
command to identify the current list of clocks.
The Set Capture Clock command specifies the name of the capture clock that the tool uses
during pseudorandom pattern simulation. You can specify the name of a specific pin in a test
procedure file that identifies the pin. The pin must be a currently-defined clock pin. Also, the
capture clock that you specify cannot have a pin constraint.
If you do not specify a capture clock with this command, LBISTArchitect sets the capture clock
to none. If there is no capture clock and there is only one clock in the circuit that is not a set or
reset line, LBISTArchitect sets that clock as the capture clock during the rules checking and
displays a warning message that identifies the capture clock.
Arguments
• primary_input_pin
A string that specifies the name of the primary input pin that you want to assign as the
capture clock.
• -Atpg
An optional switch that specifies for the tool to use the capture clock at all times.
Examples
The following example specifies a capture clock:
add clocks 1 clock1
set capture clock clock1
set system mode fault
set random patterns 612
report statistics

Related Commands
Add Clocks Report Clocks
Delete Clocks Report Environment

678 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Contention Check

Set Contention Check

Scope: All modes
Usage
SET COntention CHeck OFf | {{ON | CAPture_clock} [-Warning | -Error] [-Bus | -Port |
-ALl]}
Description
Specifies the conditions of contention checking.
The Set Contention Check command specifies whether contention checking is on, and the
conditions under which the tool performs the checks. Contention checking is set to On upon
invocation of the tool.
When the tool encounters a bused output of a tri-state driver (or switch) that is driving an X
caused by an X on its enable, it does not report contention if the data input to the driver is at the
same level as other drivers on the bus. Also, the tool resolves the simulated value of the bus gate
to a binary value if it can do so without tracing through additional bus gates.
Arguments
• OFf
A literal that specifies for the tool not to perform contention checking during simulation.
• ON
A literal that specifies for the tool to perform contention checking during simulation,
without propagating captured data effects. This is the invocation default behavior.
• Capture_clock
A literal that specifies for the tool to perform contention checking both with and without
propagating captured data effects.
If a clock, read control, or write control line connects to a bus, the tool also performs bus
contention checking with all clocks off prior to the application of the capture clock.
• -Warning
An optional switch that specifies for the tool to display a warning message, but continue
simulation, if bus contention occurs during simulation. This is the default. The warning
message indicates the number of patterns the tool rejected in the current simulation pass of
32 patterns and also identifies the bus gate on which the bus contention occurred.
• -Error
An optional switch that specifies for the tool to display an error message and stop the
simulation if bus contention occurs.
You can debug contention errors by using the -Error switch to stop simulation at the point of
the first contention error.

LBISTArchitect Reference Manual, v2017.3 679

September 2017
Fault Simulation Command Dictionary
Set Contention Check

Using this option, you can then view the simulated values of all gates in the first bus
contention pattern by using the Report Gates command. The error message indicates the
number of patterns the tool rejected in the current simulation pass of 32 patterns and also
identifies the bus gate on which the bus contention occurred.
• -Bus
An optional switch that specifies for the tool to perform contention checking of tri-state
driver buses. This is the default.
Tri-state logic allows several bus drivers to time-share a bus. However, if the circuit enables
two bus drivers of opposite logic to drive the bus, physical damage can occur. This switch
allows the tool to identify these conditions and notify you of their existence.
• -Port
An optional switch that specifies for the tool to perform contention checking for multiple-
port flip-flops and latches. The tool identifies and rejects patterns during which any
multiple-port latch or flip-flop has more than one clock, set, or reset input active (or at X).
• -ALl
An optional switch that specifies for the tool to perform contention checking for both tri-
state driver buses and multiple-port flip-flops and latches.
Examples
The following example performs contention checking on multiple-port flip-flops and latches,
stops the simulation if any bus contention occurs, and displays an error message. The message
indicates the number of patterns rejected and the bus gate on which the bus contention occurred:
set contention check on -port -error
set system mode fault
add faults -all
run

Related Commands
Report Gates Set Gate Report

680 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Distributed

Set Distributed
Tools Supported: Tessent FastScan and Tessent TestKompress
Scope: All modes
Usage
SET DISTributed [variable [value]]
Description
Displays or sets the values of several variables when executing distributed commands for fault
simulation.
The Set Distributed command displays or sets the values of several distributed processing
variables that affect the behavior of the tool. Issuing the command without arguments displays
all variables and their current values. Issuing the command with a variable but no value displays
the current value of just that variable. Include a value with variable to change the variable’s
current setting to the new value.
Table 4-10 lists the distrubted variables and their purpose. Refer to the Examples section for
examples of the use of these variables.

Table 4-10. Distributed Variables

Variable Name Type Purpose
remote_shell string Specifies the shell command (rsh or ssh) the master host should
use to create processes on slave hosts. Applies only when you
specify hosts manually rather than using a job scheduler. For
example, the following specifies to use ssh:

set distributed remote_shell ssh

Default: rsh
generic_scheduler string Specifies the command script to use to request a slave process
from the job scheduler. Applies only to subsequent
Add Processors Generic commands, not currently running
processes. For example, the following specifies an alternative
interface to SGE:

set dist generic_scheduler \

’$SGE_ROOT/bin/lx24-x86/qsub %command’

The “%command” is a substring you must use inside the

generic_scheduler string to specify the location to substitute the
Mentor Graphics command script that launches a slave process.

LBISTArchitect Reference Manual, v2017.3 681

September 2017
Fault Simulation Command Dictionary
Set Distributed

Table 4-10. Distributed Variables

Variable Name Type Purpose
generic_delete string Specifies the command to delete a job previously submitted via
the generic_scheduler variable. The tool will use this command
to delete jobs when the scheduler exceeds its timeout setting or
is interrupted by Control-C. For example, the following
specifies an alternative interface to SGE for ending slave
processes:

set distributed generic_delete \

’$SGE_ROOT/bin/lx24-x86/qdel %job’

The “%job” defines where to insert the actual job number in the
qdel command syntax; and also defines the string “job” to
search for in the generic_scheduler’s output to determine the
job number.
lsf_options string Specifies command options for the tool to append to the job
submission command for the LSF or SGE job scheduler. Setting
sge_options string a correct value for the string requires a knowledge of the
scheduler configuration at your site and the job control
submission syntax. Applies only to subsequent Add Processors
commands, not currently running processes. An incorrect
specification can prevent the correct operation of the Add
Processors command.

A value you set for this variable is appended to the current

value unless you first clear the variable by setting it to an empty
string (two single quotes (’’) with no space between them).
scheduler_timeout integer Time limit in minutes for attempts to add processors using a job
scheduler. If the tool does not receive all the requested
processors within the specified time, it will proceed with the
processors it has received. Default: 10

Note
The use of job schedulers requires certain environment prerequisites to be satisfied before
you invoke the tool. See “Multiprocessing Requirements” in the Scan and ATPG User’s
Manual for more information.

Arguments
• variable
An optional string that specifies the name of a variable. Table 4-10 lists the variables, their
purpose and the type of value (integer or string) you can assign them. Variable names are
case-sensitive; enter them exactly as shown.

682 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Distributed

• value
An optional string or integer that specifies the value to which the tool should set the
specified variable.
Example 1
The following example displays the current settings of the variables:
set distributed
Distributed Processing Variables:
string generic_delete = // generic job scheduler delete
string generic_scheduler = // generic job scheduler
string lsf_options = // options for LSF job scheduler
string remote_shell = rsh // rsh,ssh remote_shell setting
int scheduler_timeout = 10 // # mins for job scheduler
string sge_options = // options for SGE job scheduler

The lsf_options variable supports the ability to explicitly control type and memory constraints
that would normally be supplied automatically. For example:
set distributed lsf_options -R "select[type==LINUX64 && mem> 200 && swp > 200 ]"
set distributed lsf_options
string lsf_options = -R select[type==LINUX64 && mem> 200 && swp > 200]
// options for LSF job scheduler

This setting would constrain LSF to select the specified hosts. The type specification also
inhibits the automatic learning that would normally take place to discover all the type/model
names in an LSF cluster. (This is useful if your site prevents the use of the lsrun command or if
the learning hits non-responsive hosts.) Any legal LSF constraints for the installation can be
specified and they will override any related specifications the tool would have provided
otherwise. It is up to you to supply syntactically and semantically correct LSF options.
To erase the value from the variable, set it to an empty string:
set distributed lsf_options ’’
set distributed lsf_options
string lsf_options = // options for LSF job scheduler

Example 2
The following example specifies that LSF use queue myqueue (the single quotes are optional):
set distributed lsf_options ’-q myqueue’

Example 3
The following example appends an additional option to the previous setting:
set distributed lsf_options -R "select[type==LINUX64]"
set distributed lsf_options
string lsf_options = -q myqueue -R select[type==LINUX64] // options…

LBISTArchitect Reference Manual, v2017.3 683

September 2017
Fault Simulation Command Dictionary
Set Distributed

Example 4
The following example specifies that SGE impose a 6 hour timeout on slave processes:
set distributed sge_options -l h_rt=6:00:00

As with the lsf_options variable, each successive value you specify for the sge_options variable
gets appended to the current value until you clear the variable by setting it to an empty string:
Example 5
The following example specifies an alternative interface to SGE for launching slave processes:
set distributed generic_scheduler ’$SGE_ROOT/bin/lx24-x86/qsub %command’’

The %command represents a substring you must use inside the generic_scheduler string to
specify the location to substitute the Mentor Graphics command script that launches a slave
process. Variables can be defined in the dofile to make this more convenient, as in the following
example dofile excerpt:
$SUBMIT="$SGE_ROOT/bin/lx24-x86/qsub"
set distributed generic_scheduler ’${SUBMIT} %command’

Example 6
The following example specifies an alternative interface to SGE for terminating slave
processes:
set distributed generic_delete ’$SGE_ROOT/bin/lx24-x86/qdel %job’

The %job defines where to insert the actual job number in the qdel command syntax and also
defines the string “job” to search for in the generic_scheduler’s output.
Example 7
The following example specifies that the master host should use the ssh shell command to
create processes on slave hosts (manual specification of hosts only):
set distributed remote_shell ssh

Tip: Refer to “SSH Environment and Passphrase Errors” in the Scan and ATPG User’s
Manual if you encounter errors trying to utilize SSH.

Related Commands
Add Processors Report Processors
Delete Processors

684 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Dofile Abort

Set Dofile Abort

Scope: All modes
Usage
SET DOfile Abort ON | OFf
Description
Lets you specify whether the tool aborts 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. The Set Dofile Abort command lets you to
turn this functionality off so that the tool continues to process all commands in the dofile.
Arguments
• ON
A required literal that halts the execution of a dofile upon the detection of an error. This is
the default upon invocation of the tool.
• OFF
A required switch that forces dofile processing to complete all commands in a dofile
regardless of error detection.
Examples
The following example sets the Set Dofile Abort command off to ensure that all commands in
test1.dofile are executed.
set system mode fault
set dofile abort off
dofile test1.dofile

Related Commands
Dofile

LBISTArchitect Reference Manual, v2017.3 685

September 2017
Fault Simulation Command Dictionary
Set Drc Handling

Set Drc Handling

Scope: All modes
Usage
SET DRc Handling drc_id [Error | Warning | NOTe | Ignore] [NOVerbose | Verbose]
[NOAtpg_analysis | Atpg_analysis] [-Mode A clk_name] [-Interval number] [ATPGC]
[-Mode {Sequential | Combinational}]
Description
Specifies how the tool globally handles design rule violations.
The Set Drc Handling command specifies the handling of the messages for the scan cell RAM
rules checking, Clock rules checking, Data rules checking, Extra rules checking, and Trace rules
checking. You can specify that the violation messages for these checks be either error, warning,
note, or ignore. If you do not specify error, warning, note, or ignore, then the tool uses either the
handling from the last Set Drc Handling command or, if you did not change the handling, the
Design Rules Checker‘s invocation default.
Each rules violation has an associated occurrence message and summary message. The tool
only displays the occurrence message for either error conditions or if you specify the Verbose
option for that rule. The tool also displays the rule identification number in all rules violation
messages.
The Atpg_analysis option provides test generation analysis when performing rules checking for
some clock (C) rules, for some data (D) rules, and for some extra (E) rules. For example, if you
specify Atpg_analysis for clock rule C1 and the tool simulates a clock input as X, the rule
violation occurs when it is possible for the test generator to create a test pattern while that clock
input is on, all defined clocks are off and all constrained pins are at their constrained state.
Note
When you specify Atpg_analysis, the tool requires some additional CPU time and
memory to perform the test generation analysis. (The Atpg_analysis option is enabled by
default for rules C1, E4, E10, E11 and E13; you can disable it for these rules by
specifying the Noatpg_analysis option.)

Arguments
• drc_id
A required non-repeatable literal that specifies the identification of the exact design rule
violations whose message handling you want to change.
The design rule violations and their identification literals are divided into the following five
groups: RAM, Clock, Data, Extra, and Trace rules violation IDs.
• Error
An optional literal that specifies for the tool to both display the error occurrence message
and immediately terminate the rules checking.

686 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Drc Handling

If you do not specify the Error, Warning, Note, or Ignore option, then the handling is either
set to the previous handling or set to the Design Rules Checker default.
• Warning
An optional literal that specifies for the tool to display the warning summary message
indicating the number of violations for that rule. If you also specify the Verbose option, the
tool displays the occurrence message for each occurrence of the rules violation.
If you do not specify the Error, Warning, Note, or Ignore option, then the handling is either
set to the previous handling or set to the Design Rules Checker default.
• NOTe
An optional literal that specifies for the tool to display the summary message indicating the
number of violations for that rule. If you also specify the Verbose option, the tool also
displays the occurrence message for each occurrence of the rules violation.
If you do not specify the Error, Warning, Note, or Ignore option, then the handling is either
set to the previous handling or set to the Design Rules Checker default.
• Ignore
An optional literal that specifies for the tool to perform rules checking, but to not display
any messages for rule violations.
If you do not specify the Error, Warning, Note, or Ignore option, then the handling is either
set to the previous handling or set to the Design Rules Checker default.
• NOVerbose
An optional literal that specifies for the tool to display the occurrence message only once for
the rules violation. This is the default.
• Verbose
An optional literal that specifies for the tool to display the occurrence message for each
occurrence of the rules violation.
• NOAtpg_analysis
An optional literal that specifies for the tool not to use test generation analysis when
performing rules checking. This is the default.
• Atpg_analysis
An optional literal that specifies for the tool to use test generation analysis when performing
rules checking for clock rules (such as, C1, C3, C4, C5 and C6), some D rules (such as D6
and D9), and some E rules (such as, E4, E5, E8, E10, E11, and E12).
For clock rules C3 and C4, the Atpg_analysis option generates a check of the clocks of the
source and sink to see if they are gated off. To see if a path exists from the Q output of the
source to the sink, use the Set Sensitization Checking command with checking turned on. It
is recommended that you use the Atpg_analysis option with the Set Sensitization Check On
analysis to remove the maximum number of false C3 and/or C4 violations.

LBISTArchitect Reference Manual, v2017.3 687

September 2017
Fault Simulation Command Dictionary
Set Drc Handling

Note
If you want the tool to use the constraint values during the D6 rule analysis, you must use
the Atpg_analysis option.

• -Mode A clk_name
A switch, a literal (A), and a string triplet that specifies the name of the clock on which the
tool performs further analysis to screen out false C3 and C4 clock rules violations.
• -Interval number
An optional switch and integer pair that you can only use with C3 and C4 clock violations to
specify how often you want the tool to display a message during the ATPG analysis of those
violations. The number argument indicates multiples of violation occurrences that cause the
tool to display a message. The default is 0.
The message includes the number of sequential elements that the tool checked, the number
of sequential elements remaining to check, the current number of ATPG passes during the
C3 or C4 clock rules checking, and the current CPU time used by the tool for clock rules
checking.
The value of the number parameter must be either zero or a positive integer. You can only
specify one number value that the tool uses for both the C3 and C4 violations. If you issue
multiple Set Drc Handling commands (one for C3 and one for C4) that specify different
values for the number argument, the tool uses the last interval value you specified.
• ATPGC
An optional literal that specifies for the design rules checker to use all the current ATPG
constraints when performing the analysis of the C1, C3, C4, C5, C6, E10, and E11 rule
violations. You can also use the Add Atpg Constraints -Static command to do the same
thing.
• -Mode {Combinational | Sequential}
An optional switch and literal for the tool to use with the E10 rule. The Combinational
option is the default. It performs bus contention, mutual-exclusivity checking and is limited
by the combinational logic boundary.
The Sequential option considers the inputs to a single level of sequential cells behaving as
“staging” latches in the enable lines of tri-state drivers. All of the latches found in a back
trace must share the same clock. There must also be only a single clocked data port on each
cell, and both set and reset inputs must be tied (not pin constrained) to the inactive state.
This check ensures that there is no connectivity from the cells in the input cone of the
sequential cells and enables of the tri-state devices except through the sequential cells.
Examples
The following example specifies rule checking E4 to be an error:

688 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Drc Handling

add scan groups group1 scanfile

add scan chains chain1 group1 indata2 outdata4
add clocks 1 clock1
add clocks 0 clock2
set drc handling e4 error
set system mode atpg

LBISTArchitect Reference Manual, v2017.3 689

September 2017
Fault Simulation Command Dictionary
Set Fault Mode

Set Fault Mode

Scope: All modes
Usage
SET FAult Mode Uncollapsed | Collapsed
Description
Specifies whether the fault mode is collapsed or uncollapsed.
The Set Fault Mode command specifies whether the tool uses collapsed or uncollapsed fault
lists for fault counts, test coverages, and fault reports. The default fault mode upon invocation of
the tool is Uncollapsed. When you display a report on uncollapsed faults, the tool lists the
representative fault first followed by its equivalent faults.
Arguments
• Uncollapsed
A literal specifying that the tool include equivalent faults in the fault lists. This is the default
mode upon invocation of the tool.
• Collapsed
A literal specifying that the tool not include equivalent faults in the fault lists.
Examples
The following example sets the fault mode to collapsed and then displays only the collapsed
faults:
set system mode fault
add faults -all
set fault mode collapsed
report faults -all

The following shows an example when reporting uncollapsed tied faults as compared to
reporting collapsed tied faults:
Uncollapsed: Collapsed:
0 TI /I_140/I 0 TI /I_140/I
1 TI /II_140/O 1 TI /II_140/O
1 EQ /II_140/I

Related Commands
Add Faults Report Faults
Delete Faults Write Faults
Load Faults

690 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Fault Type

Set Fault Type

Scope: All modes
Usage
SET FAult Type Stuck
SET FAult Type
Stuck |
Iddq |
TOggle |
{TRansition [-NO_Shift_launch] |
[-APPLY_HOLD_PI_attribute_to_shift_launch {ON | OFf}]} |
{Path_delay [-Mask_nonobservation_points]
[-ROBust_detection_only | -NO_Functional_detection]} |
Bridge
Description
Specifies the fault model for which the tool performs BIST pattern simulation.
The Set Fault Type command specifies the fault model type that you want the tool to use in
determining test coverage during BIST pattern simulation. The default upon invocation of the
tool is Stuck.
The stuck-at fault models the behavior occurring if the terminals of a gate are stuck at either a
high (stuck-at-1) or low (stuck-at-0) voltage. Transition faults model large delay defects at gate
terminals in the circuit under test. The slow-to-rise transition fault models a device pin that is
defective because its value is slow to change from a 0 to a 1. The slow-to-fall transition fault
models a device pin that is defective because its value is low to change from a 1 to a 0. The fault
sites for both fault models include the pins of primitive instances.
Note
This command only affects pattern simulation because pattern generation in
LBISTArchitect uses pseudo-random patterns that are dependent solely on the physical
structure of the LFSR that drives data into the scan chains.

The fault sites of all models are the input and output pins of the design cells in addition to
external pins. The tool uses the values 0 and 1 for all fault models to indicate the type of fault at
the fault site. Each fault model has its own separate fault collapsing according to the model’s
rules of equivalence.
When you change the fault type, the tool deletes both the current fault list and the internal
pattern set.

LBISTArchitect Reference Manual, v2017.3 691

September 2017
Fault Simulation Command Dictionary
Set Fault Type

Caution
In LBISTArchitect, changing to a different fault model type erases all fault information,
even the information about protected faults. If some faults are protected, be sure you no
longer need the protection before you issue this command.

Arguments
• Stuck
A literal that specifies for the tool to perform BIST pattern simulation for the single stuck-at
fault model. This is the default upon invocation of the tool.
• Iddq
A literal that specifies for the tool to perform BIST pattern simulation for the IDDQ fault
model.
• TOggle
A literal that specifies for the tool to to perform BIST pattern simulation for the toggle fault
model.
• TRansition
A literal that specifies for the tool to to perform BIST pattern simulation for the transition
fault model.
• -NO_Shift_launch
An optional switch that prevents the tool from creating transition tests that launch off of the
last shift. Normally, for at-speed (AC) tests using transition faults, the tool tries to generate
a clock sequential pattern that launches in some cycle after shift is completed (broadside). If
that fails, the tool next tries to generate a basic combinational pattern that uses the last shift
as the launch. You can use this switch to stop the tool from creating “launch off shift”
patterns when it is unable to generate clock sequential tests. This is useful if you utilize
internal PLLs and only support the first form of transition test.
Note
Pattern generation with this option requires a sequential depth of 2 if the design uses a
mux-DFF scan architecture, 4 if it uses an LSSD architecture. Use the Set Pattern Type
command’s -Sequential switch to set the sequential depth.

Note
This option does not prevent the tool from asserting the scan enable signal during at-
speed tests. You must use other means (scan_enable pin constraint or capture procedure,
for example) to prevent inappropriate assertion of the scan enable pin during the at-speed
part of a multiple cycle sequential transition fault test.

692 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Fault Type

When you use this switch, each transition fault for which the tool fails to create a clock
sequential pattern will have the status given to it by the sequential search, so you may get
slightly lower fault coverage.
• -APPLY_HOLD_PI_attribute_to_shift_launch ON | OFf
An optional switch and literal that specifies to enable (ON) or disable (OFf) apply hold
attribute defined at primary inputs to test generation for launch-off-shift patterns. The
default for this switch is ON.
During test generation for launch-off-shift patterns, the tool forces primary inputs with hold
attribute to have the same value as the value in the last shift cycle except for the following
conditions:
• The PI is a clock pin or a read/write control pin.
• The PI is explicitly forced in the last shift cycle by load/unload and/or shift
procedures and the forced value is not the same as the pin constraint value if there is
any.
• All scan input pins will be treated as TIE-X during test pattern generation.
For these exception pins, the tool ignores the hold attribute defined at these pins.
• Path_delay
A literal that specifies for the tool to to perform BIST pattern simulation for the path delay
fault model.
• -Mask_nonobservation_points
An optional switch that specifies to mask all non-observation points so path delay patterns
are generated with values only at observation points. If there is already an internal pattern
set in the tool and the fault type is already set to path delay, re-issuing the command with
this switch alters the internal pattern response values by masking the non-observation
points. If this switch was specified previously when setting the fault type to Path_delay, re-
issuing the command without the switch causes the tool to re-simulate the internal patterns
to restore the capture values at the non-observation points.
• -ROBust_detection_only
An optional switch that specifies to include test coverage only for robust tests for path delay
faults. For more information about robust, non-robust and functional detection, refer to
“Path Delay Fault Detection” in the Scan and ATPG User’s Manual.
Note
This switch is not cumulative; you must include it with each subsequent Set Fault Type
command or the tool returns to the default behavior.

LBISTArchitect Reference Manual, v2017.3 693

September 2017
Fault Simulation Command Dictionary
Set Fault Type

• -NO_Functional_detection
An optional switch that specifies not to include test coverage of functional tests for path
delay faults. For more information about robust, non-robust and functional detection, refer
to “Path Delay Fault Detection” in the Scan and ATPG User’s Manual.
Note
This switch is not cumulative; you must include it with each subsequent Set Fault Type
command or the tool returns to the default behavior.

• Bridge
A literal that specifies for the tool to perform BIST pattern simulation for the static bridge
fault model.
Note
For information about fault protection, see the command reference descriptions for
Load Faults -Protected.

Related Commands
Add Faults Set Fault Mode
Delete Faults Write Faults
Report Faults

694 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set File Compression

Set File Compression

Scope: All modes
Usage
SET FIle Compression [ON | OFf]
Description
Controls whether the tools read and write files with .Z or .gz extensions as compressed files (the
default).
Files that contain large pattern sets consume a very large amount of disk space. Fault lists and
the design data itself also take up a lot of disk space. To conserve this space, the tools normally
store files in one of two compressed formats when you provide a filename with the appropriate
extension, as follows:
• “.Z” specifies to compress the file using the UNIX compress command.
• “.gz” specifies to compress the file using the GNU gzip command. You can control the
type of GNU compression with the Set Gzip Options command.
When compressed file handling is enabled and you provide a filename with either of the above
extensions, a tool will automatically decompress (for reading) or compress (for writing) the
specified file.
The Set File Compression command allows you to turn off the tool’s normal compressed file
handling functionality. This is useful in rare cases where files have either of the compressed file
extensions, but should not be saved or read as compressed files.
Arguments
• ON
An optional literal that enables compressed file handling. This is the default.
• OFf
An optional literal that disables compressed file handling. When set to off, the tools process
.Z or .gz files without using compression.
Examples
Suppose the file testpat.ascii.gz is not a compressed file. The following example disables
compressed file handling so the tool will read testpat.ascii.gz as a normal file rather than as a
compressed file:
set file compression off

The next example re-enables compressed file handling, then saves the file fault.pat in GNU
format:
set file compression on
write netlist verilog.scan.gz -verilog

LBISTArchitect Reference Manual, v2017.3 695

September 2017
Fault Simulation Command Dictionary
Set File Compression

Related Commands
Set Gzip Options

696 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Gate Level

Set Gate Level

Scope: All modes
Usage
SET GAte Level Design | Primitive | Low_design
Description
Specifies the hierarchical level of gate reporting and displaying.
The Set Gate Level command specifies the hierarchical gate level at which the tool operates.
This includes the reporting and schematic display of gate information. Once you set the gate
level, the tool processes all subsequent commands using the new gate level.
Whenever you issue a command which invalidates the flattened model, the tool also invalidates
the hierarchical gate display structure. You can rebuild the hierarchical gate structure by
creating a new flattened model. To do so, either enter and exit the Setup mode, or use the Flatten
Model command.
Arguments
• Design
A literal that specifies to display gate information at the design library hierarchical gate
level. These are the top-level cells of the design library which are instantiated in your
design. This is the default upon invocation of the tool.
• Primitive
A literal that specifies to display gate information at the built-in primitive gate level.
• Low_design
A literal that specifies to display gate information at the pseudo-hierarchical gate level. A
pseudo-hierarchical gate is a cluster gate that contains primitive gates and is at the lowest
hierarchy level in the design library. These gates only differ from design level gates if the
library contains macro cells.
Examples
The following example sets the gate report level so that reporting and display show the
simulated values of the gate and its inputs (assuming a rules checking error occurred when
exiting the Setup system mode):
set system mode fault
set gate level primitive
set gate report error_pattern
report gates i_1006/o

Related Commands
Report Gates Set Gate Report

LBISTArchitect Reference Manual, v2017.3 697

September 2017
Fault Simulation Command Dictionary
Set Gate Report

Set Gate Report

Scope: All modes
Usage
SET GAte REport {Normal | Trace | Error_pattern | Fault_status | Bist_data | TIe_value |
Constrain_value | Seq_depth_data | Clock_cone pin_name |
{Drc_pattern procedure_name [-All | time]} | {Parallel_pattern pattern_number} |
{CApture_pattern [n | All]}} [-False_paths {ON | OFf}]
Description
Specifies additional display information for the Report Gates command.
The Set Gate Report command controls the type of additional information that the Report Gates
command displays. Each Set Gate Report option causes the Report Gates command to provide
different details regarding the gates on which it reports.
When you exit the Setup system mode, the trace and any rules-checking error pattern results
will not be available with the usage of this command.
For information on the format output by the different options in this command, refer to the
Report Gates reference page.
Arguments
• Normal
A literal that specifies for the Report Gates command to display only its standard
information. This is the default mode upon invocation of the tool.
• Trace
A literal that specifies for the Report Gates command to display the simulated values of the
gates during the scan chain tracing. The format of these values depends on the contents of
the shift procedure. If the shift procedure contains additional frames, the additional frames
will also be displayed in the gate report data. The trace data relates to the simulation
performed during the scan chain tracing. Use the Trace option to determine why a scan
chain was not properly sensitized during the shift procedure.
See the Example 1 section of this command for an example of the information displayed.
• Error_pattern
A literal that specifies for the Report Gates command to display the simulated value of the
gates and its inputs for the pattern at which an audit error occurred.
• Fault_status
A literal that specifies for fault detection status of both SA-0 and SA-1 of all gates to be
preserved. Subsequent commands which cause the gate to be displayed, will annotate the
pins with fault status data.
The format of the fault status data is as follows:

698 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Gate Report

<sa0-status:sa1-status>
where sa0-status and sa1-status are one of the following:
DS — Detected by simulation
DI — Detected by implication
PU — Possible detect untestable
PT — Possible detect testable
AU — Atpg untestable
UC — Undetected uncontrolled
UO — Undetected unobserved
UU — Untestable unused
BL — Untestable blocked
TI — Untestable tied
RE — Untestable redundant
• Bist_data
A literal that specifies for the Report Gates command to display previously- calculated
control and observe values. To set the Bist_data option, you must do so prior to rules
checking, and you must re-execute the design rules checking process; otherwise, no data (-)
from this option will be available for gate reporting.
• TIe_value
A literal that specifies for the Report Gates command to display the simulated values that
result from all natural tied gates and learned constant value non-scan cells.
Tie_value is available at any time the flattened model exists. The value displayed on the TIE
node is set by simulation. All internal nodes are initially set to X for simulation.
Subsequently, BIST simulation or various commands may put values on the nodes.
Occasionally, a set of circumstances may occur where an X shows up on a TIE node.
During operation, BIST simulation typically marks for simulation only those gates which
are of interest for sensitization and propagation of a particular fault. If a gate is not marked,
it will not be simulated, and any nodes associated with it may remain at an “X” value, even
though they are connected to a TIE gate.
While tie_value reports the status of node values once it comes out of the DRC checks, the
constrain_value tells you what the gate is suppose to act like for future consideration.
• Constrain_value
A literal that specifies for the Report Gates command to display the simulated values that
result from all natural tied gates, learned constant value non-scan cells, constrained pins,
and constrained cells.
The Report Gates command displays three values which are separated by a slash (/). These
values are the gate constrained value (0, 1, X, or Z), the gate forbidden values (-, 0, 1, Z, or

LBISTArchitect Reference Manual, v2017.3 699

September 2017
Fault Simulation Command Dictionary
Set Gate Report

any combination of 01Z), and the fault blockage status (- or B, where B indicates all fault
effects of this gate are blocked).
The displayed values are only available at the end of DRC once the tool successfully leaves
Setup Mode. While tie_value reports the status of node values once it comes out of the DRC
checks, the constrain_value tells you what the gate is suppose to act like for future
consideration.
• Seq_depth_data
A literal that specifies for the Report Gates command to display the calculated gate
sequential depths.
When you select a non-zero sequential depth, the tool performs a learning process to
identify the minimum depths necessary to satisfy controllability and observability
requirements for all gates using the current clock_sequential cells. The tool calculates both
the 0-state and 1-sate controllability depths. At the end of the analysis, the tool displays a
summary message that indicates the largest sequential test depth, along with the largest
control and observe depth. The test generator uses the sequential depth information in
making decisions and avoiding paths whose sequential depth exceeds the maximum allowed
sequential depth.
The Report Gates command includes three values separated by a comma and a dash. The
first value is the 0-state controllability depth, the second value is the 1-state controllability
depth, and the third value is the observability depth. The maximum reported depth is 255. If
controllability or observability is logically impossible or exceeds 255, the report displays an
asterisk (*) in the corresponding fields.
• Clock_cone pin_name
A literal and string pair that specifies the clock pin for which the Report Gates command
displays the clock cone data.
The clock cone data from the Report Gates command is the same data that is available as
error data for clock rules violations. You can only use this option after flattening the
simulation model.
The pin_name must be a valid clock pin or an error condition occurs. The tool considers the
pin equivalents when calculating the clock cones. State elements that the tool identifies as
capturing on the clock’s trailing edge, will not propagate the clock effect cone. During the
Setup system mode, this information is not available, and the tool assumes all state elements
capture with the leading edge of the selected clock.
• Drc_pattern procedure_name [-All | time]
Two literals and an optional, time triplet that specifies the name of the procedure and the
time in the test procedure file that the Report Gates command uses to display a gates
simulated value.
You must set the Drc_pattern prior to rules checking and you must re-execute the design
rules checking process; otherwise, no data (-) from this option will be available for gate
reporting.

700 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Gate Report

The valid choices for use with Drc_pattern are as follows:

procedure_name — A literal that specifies a procedure in the test procedure file that
you want the Report Gates command to use when displaying the value of a gate. The
literal choices for the procedure_name option are as follows:
Test_setup — A literal that specifies the use of the test_setup procedure. In the test
procedure file, this procedure sets non-scan elements to the state you desire for
the load_unload procedure.
Load_unload — A literal that specifies the use of the load_unload procedure. The
test procedure file must contain this procedure which describes how to load and
unload data in the scan chains.
SHIft — A literal that specifies the use of the shift procedure. The test procedure file
must contain this procedure which describes how to shift data one position down
the scan chain.
SKew_load — A literal that specifies the use of the skew_load procedure. In the test
procedure file, this procedure describes how to propagate the output value of the
preceding scan cell into the master memory element of the current cell (without
changing the slave), for all scan cells.
SHADOW_Control — A literal that specifies the use of the shadow_control
procedure. In the test procedure file, this procedure describes how to load the
contents of a scan cell into the associated shadow.
Master_observe — A literal that specifies the use of the master_observe procedure.
In the test procedure file, this procedure describes how to place the contents of a
master into the output of its scan cell.
SHADOW_Observe — A literal that specifies the use of the shadow_observe
procedure. In the test procedure file, this procedure describes how to place the
contents of a shadow into the output of its scan cell.
STate_stability — A literal that specifies the display of the simulation values for
the load_unload procedure and the capture clock cycle that the tool used to
determine the constant value state elements at the initial load time. The report
separates the shift procedure values, load_unload procedure values, and the
capture clock cycle with parentheses. This format provides information that is
helpful when you are trying to debug boundary scan.
The state_stability option is not a procedure.
-All — An optional switch that specifies use of all times in the test procedure file. This
is the default.
time — An optional positive integer, greater than 0, that specifies a time in the test
procedure file.
• Parallel_pattern pattern_number
A literal and integer pair that specifies the pattern number from the last simulation pass that
you want the Report Gates command to use when displaying the value of a gate. For 32-bit
invocations, the pattern_number must be an integer between 0 and 31. For 64-bit
invocations, the pattern_number must be an integer between 0 and 63.

LBISTArchitect Reference Manual, v2017.3 701

September 2017
Fault Simulation Command Dictionary
Set Gate Report

-All — An optional switch that specifies the use of all times in the test procedure file.
With Set Clock_off Simulation on, Set Split Capture_cycle on, and the Set Gate Report
command set with the Parallel_pattern option, the gate report displays three values. The first
is the result of the analysis for clock_off simulation. The second is the value at the leading
edge of the clock. Finally, the third is the trailing edge of the clock (for split capture_cycle
analysis).
• CApture_pattern [n | All]
A literal that specifies for the Report Gates command to display simulation values that result
after the final capture clock pulse has been added. For 32-bit invocations, the option n is an
integer in the range of 0 to 31 for all platforms. For 64-bit invocations, the option n is an
integer in the range of 0 to 63 for all platforms. This integer corresponds to the parallel
pattern number. The All option forces all values to be displayed in a single string separated
by the “/” character.
Note
You must first issue the command “Set Contention Check Capture_clock” in order for
this option to work properly.

If you cannot have contention check on, use the previously-described Parallel_pattern
option, rather than Capture_pattern. The difference between the two modes is that the
Parallel_pattern option shows the values right before the capture clock, whereas the
Capture_pattern option shows the values right after the capture clock.
• -False_paths [ON | Off]
An optional switch and literal pair that enables or disables the reporting of false path
information for the Report Gates command and the DFTVisualizer Debug window. The two
-False_paths options are as follows.
ON —False path information is reported by the Report Gates command and displayed in
the Debug window. This option is only effective during non-Setup mode. When you
enable this switch, any subsequent issuance of the Report Gates command can
include one or more of the following false path-related keywords:
Fr: Indicates the launch/start point of a false path.
To: Indicates the capture/end point of a false path.
Th: Indicates points along a false path.
In: Indicates points along the intersection of multiple false paths.
Ef: Indicates points in a false path effect cone.
— : Indicates points that are not part of any false path.
OFf — False path information is not reported by the Report Gates command.
Because the -false_paths argument does not reset the previously-specified gate report
option, you can use this argument in conjunction with other Set Gate Report settings.

702 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Gate Report

Example 1
The following example sets the gate report so that reporting and display show the simulated
values of the gate and its inputs (assuming a rules checking error occurred when exiting the
setup system mode):
set system mode fault
set gate report error_pattern
report gates i_1006/o

Example 2
The following example illustrates a shift procedure containing two clocks that are pulsed in
sequence and the corresponding gate report display when the gate report is set to trace. The data
displayed is with respect to the shift procedure.
procedure shift =
force_sci 0;
measure_sco 0; force clk 1 1;
force clk 0 2;
force tclk 1 3;
force tclk 0 4;
period 6;
end;

rep gate 32
// /I_15 (32) NOR
// i0 I (XXXXX) 16-/I_16/out
// i1 I (XXXXX) 17-/I_6/out
// out O (XXXXX) 43-/S2

rep gate tclk

// /TCLK (9) PI
// TCLK O (00010) 40-/I_13/clk

rep gate clk

// /CLK (4) PI
// CLK O (01000) 20-/I_20/I_225/i0
21-/I_23/I_225/i0

Example 3
The following example illustrates how to use the Report Gate command to trace the transition
of the pattern along the false paths. In this example, false path and an internal pattern simulation
values are reported.
ATPG> set gate report –false_paths on
ATPG> set gate report pattern_index 1
ATPG> report gates /ix21/UD1
ATPG> rep gat /ix21/UD1
// /ix21/UD1 (36) DFF
Functional Specification for New ATPG Kernel
Rev. 0.1 Page: 8
Date Modified: 1/20/09 9:49 PM

LBISTArchitect Reference Manual, v2017.3 703

September 2017
Fault Simulation Command Dictionary
Set Gate Report

// "S" I (0-0)(--) 6-
// "R" I (0-1)(--) 20-
// "C0" I (1-0)(--) 10-
// "D0" I (1-1)(To) 32-
// "OUT" O (1-1 [0])(In/Ef) 9-
// MASTER cell_id=2 chain=chain1 group=grp1 invert_data=FFFT
ATPG> f
// /ix21/UD1 (9) BUF
// "I0" I (1-1)(Fr/Ef) 36-
// "OUT" O (1-1)(In) 18- 19-
ATPG> f
// /ix21 (18) BUF
// "I0" I (1-1)(In) 9-
// Q O (1-1)(To) 28-/fdgd/A 29-/ix19/A
ATPG> f
// /fdgd (28) NAND
// A I (1-1)(To) 18-/ix21/Q
// B I (1-0)(--) 1-/s
// Z O (0-1)(Ef) 37-/y[2]
ATPG> f
// /y[2] (37) PO
// "I0" I (0-1)(Ef) 28-/fdgd/Z
// y[2] O (0-1)(Ef)

Related Commands
Report Gates

704 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Gzip Options

Set Gzip Options

Scope: All modes
Usage
SET GZip Options [-Path gzip_path] [-Fast | -Best | -integer]
Description
Specifies GNU gzip options to use with the GNU gzip command.
The Set Gzip Options command specifies GNU gzip options the tool will use when
compressing or decompressing files using the GNU gzip command. When file compression
handling is enabled (as described under the Set File Compression command), the tool uses GNU
gzip when processing files having a .gz extension.
Arguments
• -Path gzip_path
An optional literal that specifies the full path gzip_path to a gzip executable file. You need
to provide this pathname only if gzip is not in your normal UNIX search path. If you have
specified a pathname with this option, you can restore the default behavior of using your
UNIX path to find gzip by issuing the command with the -Path gzip option.
The following switches all control the speed of compression:
• -Fast
An optional switch that specifies to use the fastest compression method, which yields the
least compression and corresponds to the gzip -1 option. This is the default.
• -Best
An optional switch that specifies to use the slowest compression method, which yields the
most compression. This corresponds to the gzip -9 option.
The default compression is -6.
• -digit
An optional switch that specifies an integer from 1 to 9 that the tool passes to gzip to control
the rate of compression. You obtain the least amount of compression with -1, the greatest
amount of compression with -9.
Examples
The following example ensures file compression is enabled, sets gzip compression to the fastest
method, then saves a file using the .gz file naming extension in order to activate gzip file
compression handling:
set file compression on
set gzip options -fast
write netlist verilog.scan.gz -verilog

LBISTArchitect Reference Manual, v2017.3 705

September 2017
Fault Simulation Command Dictionary
Set Gzip Options

Related Commands
Set File Compression

706 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Internal Fault

Set Internal Fault

Scope: Setup mode
Usage
SET INternal Fault ON | OFf
Description
Specifies whether the tool allows faults within or only on the boundary of library models.
The Set Internal Fault command specifies whether the tool allows faults on internal nodes of
library models or only on the library model boundary. The default upon invocation of the tool is
to allow faults only on the library model boundary.
Arguments
• ON
A literal that allows faults on the internal nodes of library models.
• OFf
A literal that allows faults only on the boundary of the library models. This is the default
upon invocation of the tool.
Examples
The following example performs BIST simulation and reports faults on the internal nodes of the
library models:
set internal fault on
set system mode fault
add faults -all
run
report faults -all

LBISTArchitect Reference Manual, v2017.3 707

September 2017
Fault Simulation Command Dictionary
Set Logfile Handling

Set Logfile Handling

Scope: All modes
Usage
SET LOgfile Handling [-RESume | {filename [-Replace | -Append]}
Description
Specifies for the tool to direct the transcript information to a file.
The Set Logfile Handling command causes the tool to write the transcript information, which
includes the commands and the corresponding output (if any), into the file you specify. You can
execute the Set Logfile Handling command at any time, as many times as you need.
In the logfile, the command keyword precedes all commands that the tool executes. You can
easily search for the executed commands, generate a separate dofile containing those
commands, and then execute the dofile, thereby rerunning those commands within the tool.
When you set the logfile handling, the tool still writes the same information to the session
transcript window in addition to the logfile. However, you can disable the writing of the
information to the transcript window with the Set Screen Display command.
If you want to stop writing to a logfile, issue the Set Logfile Handling command with no
options, which closes the appropriate files.
Arguments
• -Resume
An optional switch that specifies for the tool to resume writing transcript output to the
logfile specified at invocation with the -Logfile invocation switch. You do not need to
include the name of the invocation logfile with this switch; the tool will remember the name.
• filename
A string that specifies the name of the file to which you want the tool to write the transcript
output. This string can be a full pathname or a leafname. If you only specify a leafname, the
tool creates the file in the directory from which you invoked the tool.
If you do not specify a filename, the tool discontinues writing logfiles and closes the
appropriate files.
• -Replace
An optional switch that forces the tool to overwrite the file if a file by that name already
exists.
• -Append
An optional switch that causes the tool to begin writing the transcript at the end of the
specified file.

708 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Logfile Handling

Examples
The following example specifies for the tool to write a logfile and to disable the writing of the
transcript:
set logfile handling /user/designs/setup_logfile
set screen display off
add clocks 0 clk
add clocks 1 pre clr
report clocks

The following information shows what the logfile contains after running the preceding set of
commands:
// command: set scr d off
// command: add clocks 0 clk
// command: add clocks 1 pre clr
// command: report clocks
PRE, off_state 1
CLR, off_state 1
CLK, off_state 0

Related Commands
Report Environment

LBISTArchitect Reference Manual, v2017.3 709

September 2017
Fault Simulation Command Dictionary
Set LFSR Seed

Set LFSR Seed

Scope: All modes
Usage
SET LFsr Seed name seed [ -Binary | -Hexadecimal ]
Description
Sets the initial value of a PRPG or a MISR.
The Set Lfsr Seed command initializes the value of a PRPG or MISR with a seed value. The
seed value must be specified as a hexadecimal or binary number greater than zero.
Note, the output generated by the Report LFSRs command can be used as the input for this
command in cases such as simulation mode experiments exploring different initial seeds.
Arguments
• name
A required string that specifies the name tof the PRPG or MISR.
• seed
A required number, greater than zero, that specifies the initial state of the LFSR. This
number must be either a hexadecimal (default) or a binary number if the -Binary switch is
specified.
• -Binary
An optional switch that specifies the value of the seed argument is to be interpreted as a
binary number. By default, the seed is interpreted as a hexadecimal number.
• -Hexadecimal
An optional switch that specifies the value of the seed argument is to be interpreted as a
hexidecimal number. This is the default.
Example
SET LFsr Seed prpg 5

Related Topics
Add LFSR Taps Delete LFSRs
Add LFSRs Report LFSRs

Command Summary

710 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Number Shifts

Set Number Shifts

Scope: Setup mode
Usage
SET NUmber Shifts shift_number
Description
Sets the number of shifts for loading or unloading the scan chains.
The number of shifts used for loading or unloading the scan chains in a scan group is the same
as the largest number of scan cells in any scan chain in that scan group. The tool determines this
number once it traces all scan chains. This is the default.
You can use the Set Number Shifts command to increase this number.
Note
The Set Number Shifts command does not apply to WGL patterns.

Arguments
• shift_number
Specifies the number of shifts. If the number specified is smaller than the default number
determined by the tool, the tool issues an error message.
Example
The following example sets the number of shifts for loading or unloading the scan chains to 2.
set number shifts 2

LBISTArchitect Reference Manual, v2017.3 711

September 2017
Fault Simulation Command Dictionary
Set Pattern Buffer

Set Pattern Buffer

Scope: All modes, as long as no pattern data currently exists.
Usage
SET PAttern Buffer {directory_name...} | -Off
Description
Stores run-time pattern data in temporary files in the directory specified.
The Set Pattern Buffer command allows you to specify a directory where the tool can store
temporary run-time pattern data. When the tool accesses a pattern, it is then automatically
retrieved from the specified directory, as opposed to virtual memory, conserving the memory
for other tool processing tasks. This provides a run-time processing advantage if you are using
the tool on a 32-bit platform, unless the design is tiny and memory usage is well below the 32-
bit process limit. It also provides a processing advantage on 64-bit platforms when there is not
ample swap space.
You can specify multiple directories. As individual buffer files approach their file size limit or
volume space runs out, the tool searches the specified directory list for available space. The tool
deletes these buffer files when you exit the application.
Note
Buffer files may be multiple gigabytes large. Choose directories on volumes that have
enough disk space to handle expected amount of pattern data.

Arguments
• directory_name
A required repeatable string that specifies the full path directory names in which the tool
saves buffer files, thus enabling the usage of temporary buffer files for pattern data. Re-
issuing this command with additional directories causes the tool to add the directories to the
current list of directories available for buffer files.
• -Off
A required switch that disables the use of temporary buffer files, causing the tool to save
run-time data in virtual memory. This is the default upon invocation. Disabling the usage of
pattern buffers can only be done when there is no pattern data, such as after issuing the
Reset State or Set System Mode Setup commands.
Example
The following example places buffer files in the specified directories.
set pattern buffer /usr/jdoe/buffers /usr2/jdoe/morebuffers

712 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Pattern Classification

Set Pattern Classification

Scope: All modes
Usage
SET PAttern Classification ON | OFf
Description
Specifies the order in which to store test patterns. When set to “on”, each pattern is stored by its
classification, according to the following ordered list:
basic
read only (a type of basic pattern)
ram sequential
clock sequential and multi-load
When set to “off”, test patterns are stored in the order in which they were generated.
Arguments
• ON
A literal that enables pattern classification. If the current internal pattern set is not classified,
the pattern is automatically classified after the command is executed.
• OFf
A literal that turns off pattern classification. When pattern classification is disabled, patterns
are stored in the same order in which they were generated.
Example
The following example stores patterns in the order in which the tool generates them:
set pattern classification off

LBISTArchitect Reference Manual, v2017.3 713

September 2017
Fault Simulation Command Dictionary
Set Pattern Source

Set Pattern Source

Scope: Fault and Good modes
Usage
SET PAttern Source Bist [-Store_patterns [-Lfsm_value_only | -Exclude_lfsm_value]]
Description
Specifies the source of the patterns for future Run commands.
The Set Pattern Source command specifies the source of the pattern set that you want the tool to
use for future Run commands.
Arguments
• Bist
A required literal that specifies for the tool to use the BIST patterns when performing a
simulation run.
Before executing the run, LBISTArchitect checks to ensure that there is at least one defined
LFSR. The existence of such an LFSR means that the design successfully passed the BIST
rules checking when leaving Setup. If this check fails, LBISTArchitect displays an error
condition.
When you specify BIST patterns, you can use the Store_patterns option to store the BIST
patterns when simulating in Good system mode. These patterns are different from normal
patterns in that they specify the excess values that occur on short scan chains during the load
and unload process. Also, the last pattern will not contain an unload of the scan chains.
• -Store_patterns
An optional switch that directs LBISTArchitect to place patterns that it simulates during the
Good system mode into the internal pattern set. You can then use the Save Patterns
command to save these patterns to an external file.
• -Lfsm_value_only
An optional switch that directs LBISTArchitect to only store the lfsm_value (such as PRPG
and MISR) in the pattern set; the lfsm_value can only be saved in ASCII patterns. This
switch must be used in conjunction with the -Store_patterns switch and cannot be used with
the -Exclude_lfsm_value switch. This switch is only valid for BIST pattern simulation.
• -Exclude_lfsm_value
An optional switch that directs LBISTArchitect to not store lfsm_value in the pattern set.
This switch must be used in conjunction with the -Store_patterns switch and cannot be used
with the -Lfsm_value_only switch. This switch is only valid for BIST pattern simulation.

714 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Pattern Source

Example 1
The following example performs fault simulation with the BIST patterns and the patterns are
then saved with both the LFSM value and the pattern internal view (Tessent FastScan file
format):
set system mode good
set pattern source bist -store_patterns
add faults -all
run
save patterns bist.pat -rep

Example 2
The following example only stores the LFSM values to save memory during BIST pattern
simulation:
set pattern source bist -store_patterns -lfsm_value_only
run
save patterns bist_lfsm_only.pat -rep

Example 3
The following example saves the patterns in the FastScan pattern format:
set pattern source bist -store_patterns -exclude_lfsm_value
save patterns bist_exclude_lfsm.pat -rep

Related Commands
Save Patterns

LBISTArchitect Reference Manual, v2017.3 715

September 2017
Fault Simulation Command Dictionary
Set Pattern Type

Set Pattern Type

Scope: All modes
Usage
SET PAttern Type [-SEQuential depth]
Description
Specifies the type of pattern(s) used by simulation.
Note
Switch settings for this command are cumulative; that is, switches retain their settings
over multiple Set Pattern Type commands until you specify a different setting.

The Set Pattern Type command determines the type of patterns the tool uses during simulation.
The -Sequential switch provides the ability to use clock sequential cells. For example,
“-sequential 2” enables the tool to simulate clock sequential patterns with up to two clock pulses
between scan loads. Try to use the smallest possible depth, as it affects both memory
requirements and performance. You can use the Run command to obtain estimates of the
maximum test coverage possible with different sequential depth settings.
LBIST pattern simulation depends on named capture procedures that describe the clock
waveforms that are applied to the core for each pattern. Each named capture procedure may
require a different number of simulation cycles depending on the number of clock pulses that it
generates. The Set Pattern Type command is used to specify the number of sequential cycles
that the fault simulation kernel will simulate for any pattern. This value must be large enough to
properly simulate all of the named capture procedures.
Arguments
• -SEQuential depth
An optional switch and integer pair that specifies the depth of the design’s non-scan
sequential elements (its sequential depth). The integer can be a value between 0 and 255, but
the best practice is to set the depth as low as possible because it affects both memory
requirements and performance. The default sequential depth upon invocation is 0.
Note
Clock sequential patterns must be avoided if a clock procedure contains a restore_bidis
statement.

716 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Possible Credit

Set Possible Credit

Scope: All modes
Usage
SET POssible Credit percentage
Description
Specifies the percentage of credit that the tool assigns possible-detected faults.
The Set Possible Credit command specifies the percentage of possible-detected faults that the
tool considers as detected when calculating the test coverage, fault coverage, and ATPG
effectiveness. For the equations that the tool uses in these calculations, refer to “Testability
Calculations” in the Scan and ATPG User’s Manual.
When you invoke the tool, the default credit value for possible-detected faults is 50 percent.
Arguments
• percentage
A required integer, from 0 to 100, that specifies the percentage of possible-detected faults
that you want the tool to consider as detected when calculating the test coverage, fault
coverage, and ATPG effectiveness. The default value upon invocation of the tool is 50
percent.
Examples
The following example sets the credit for possible detected faults as 25 percent for determining
the fault coverage, test coverage, and ATPG effectiveness:
set system mode fault
add faults -all
set possible credit 25
run
report statistics

LBISTArchitect Reference Manual, v2017.3 717

September 2017
Fault Simulation Command Dictionary
Set Random Patterns

Set Random Patterns

Scope: All modes
Usage
SET RAndom Patterns integer
Description
Specifies the number of pseudorandom patterns LBISTArchitect simulates.
The Set Random Patterns command specifies how large a set of pseudorandom patterns you
want LBISTArchitect to simulate.
Arguments
• integer
A required integer, greater than or equal to 0, that specifies the number of pseudorandom
patterns that you want LBISTArchitect to simulate. The default value upon invocation of
LBISTArchitect is 1024.
Examples
The following example sets the number of pseudorandom patterns, then analyzes that pattern
set’s controllability effects on all gates in the design:
set system mode fault
set random patterns 612

Related Commands
Set Pattern Source

718 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set Screen Display

Set Screen Display

Scope: All modes
Usage
SET SCreen Display ON | OFf
Description
Specifies whether the tool writes the transcript to the session window.
If you create a logfile with the Set Logfile Handling command, you may want to disable the tool
from writing the same information to the session transcript window.
Arguments
• ON
A literal that enables the tool to write the session information to the transcript window. This
is the default behavior upon invocation of the tool.
• OFf
A literal that disables the tool from writing any of the session information to the transcript
window, including error messages.
Examples
The following example shows how to use the logfile functionality to capture the transcript in a
file and then disable the tool from writing the transcript to the display.
set logfile handling /user/design/setup_file
set screen display off

Related Commands
Report Environment Set Logfile Handling

LBISTArchitect Reference Manual, v2017.3 719

September 2017
Fault Simulation Command Dictionary
Set Split Capture_cycle

Set Split Capture_cycle

Scope: All modes
Usage
SET SPlit Capture_cycle OFf | ON
Description
Controls whether the tool updates simulation data between clock edges.
The Set Split Capture_cycle command enables or disables the simulation of level-sensitive and
leading edge state elements updating as a result of applied clocks. When set to ON, the tool
updates simulation data between clock edges. This “split capture cycling” of data allows the
tool to determine correct capture values for trailing edge and level-sensitive state elements, even
in the presence of C3 and C4 violations. When set to OFF, simulation data is updated once each
clock cycle.
Arguments
• OFf
A literal that specifies not to update simulation data between clock edges. This is the default
behavior upon invocation of the tool.
• ON
A literal that specifies to update simulation data between clock edges. This is referred to as
split-capture cycling.
Examples
The following example enables split capture cycling:
set split capture_cycle on

720 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Set System Mode

Set System Mode

Scope: All modes
Usage
SET SYstem Mode {Setup [-Force]} | Fault | Good
Description
Specifies the system mode you want the tool to enter.
The Set System Mode command directs the tool to a specific system mode. The system mode
that you specify may be any of the modes that your tool supports. The default mode upon
invocation of the tool is Setup.
When you switch from the Setup mode to any other mode, the tool builds a flat, gate-level
simulation model. Also, when switching from any other mode to the Setup mode, the tool
discards all of the results generated in that mode unless you first save them.
Arguments
• Setup
A literal that specifies for the tool to enter the Setup system mode.
Within this mode, you build the simulation model and identify and audit the scan structure.
Unless the circuit passes rules checking, you cannot exit this mode except by specifying the
-Force switch with one of the other mode names. When you re-enter the Setup mode, the
tool discards the current fault list, internal pattern set, observe points, and control points.
• Fault
A literal that specifies for the tool to enter the Fault Simulation system mode.
In this mode, the Run command performs fault simulation on the selected pattern source.
The tool calculates the test coverage, but does not store into the internal test pattern set the
patterns that it used to achieve the test coverage.
• Good
A literal that specifies for the tool to enter the Good Simulation system mode.
In this mode, the Run command performs good machine simulation on the selected pattern
source. You would normally use this mode for debugging.
• -Force
An optional switch that forces an exit of the Setup mode in the presence of non-fatal rules
checking errors. This option has no effect except when exiting the Setup system mode.

LBISTArchitect Reference Manual, v2017.3 721

September 2017
Fault Simulation Command Dictionary
Set System Mode

Examples
The following example changes the system mode so you can perform a fault simulation run:
add scan groups group1 scanfile
add scan chains chain1 indata2 outdata4
set system mode fault
add faults -all
run

722 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Setup LFSRs

Setup LFSRs
Scope: All modes
Usage
SETup LFsrs {-Both | -Serial | -Parallel} {-Out | -In}
Description
Changes the shift_type and tap_type default setting for the Add LFSRs and Add LFSR Taps
commands.
The Setup LFSRs command controls the default setting for the shift_type and tap_type switches.
You specify the LFSR’s shift technique by using one of the following shift_type switches: -
Both, -Serial, or -Parallel. You specify the placement of the exclusive-OR taps by using one of
the following tap_type switches: -Out or -In. When you change one or both of the default
settings, all future Add LFSRs and Add LFSR Taps commands use the new default.
Arguments
The following lists the three shift_type switches of which you can choose only one:

• -Both
A switch specifying that the LFSR shifts both serially and in parallel. This is the default
behavior upon invocation of LBISTArchitect.
• -Serial
A switch specifying that a serial shift LFSR shifts a number of times equal to the length of
the longest scan chain for each scan pattern.
• -Parallel
A switch specifying that a parallel shift LFSR shifts once for each scan pattern.
The following lists the two tap_type switches of which you can only choose one:

• -Out
A switch that places the exclusive-or taps outside the register path. This is the default upon
invocation of LBISTArchitect.
• -In
A switch that places the exclusive-or taps in the register path.
Examples
The following example changes the default shift_type setting to Serial and the default tap_type
switch to In:
setup lfsrs -serial -in
add lfsrs lfsr1 prpg 5 13
add lfsrs lfsr2 prpg 5 11
add lfsr taps lfsr1 2 3

LBISTArchitect Reference Manual, v2017.3 723

September 2017
Fault Simulation Command Dictionary
Setup LFSRs

add lfsr taps lfsr2 3 4

set system mode fault

Related Commands
Add LFSRs Delete LFSR Taps
Add LFSR Taps Report LFSRs
Delete LFSRs

724 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Setup Pin Constraints

Setup Pin Constraints

Scope: Setup mode
Prerequisites
You must execute the Set Test Cycle command before adding pin constraints.
Usage
SETUp PIn Constraints constraint_format
Description
Changes the default cycle behavior for non-constrained primary inputs.
The Setup Pin Constraints command changes the default cycle behavior for all primary inputs
not specified with the Add Pin Constraints command. You must first specify the test cycle width
with the Set Test Cycle command.
Arguments
• constraint_format
A required argument that specifies the new constraint_format default for all primary inputs
not specified with the Add Pin Constraints command. The constraint_format argument
choices are as follows:
NR period offset — A literal and two-integer triplet that specifies application of the
non-return waveform value to the primary input pins. The test pattern set you provide
determines the actual value FlexTest assigns to the pins.
C0 — A literal that specifies application of the constant 0 to the chosen primary input
pin. If the value of the pin changes during the scan operation, the tool uses the non-
return waveform.
C1 — A literal that specifies application of the constant 1 to the chosen primary input
pins. If the value of the pin changes during the scan operation, the tool uses the non-
return waveform.
CZ — A literal that specifies application of the constant Z (high impedance) to the
chosen primary input pins. If the value of the pin changes during the scan operation,
FlexTest uses the non-return waveform.
CX — A literal that specifies application of the constant X (unknown) to the chosen
primary input pins. If the value of the pin changes during the scan operation, the tool
uses the non-return waveform.
R0 period offset width — A literal and three integer quadruplet that specifies
application of one positive pulse per period.
SR0 period offset width — A literal and three integer quadruplet that specifies
application of one suppressible positive pulse during non-scan operation.
CR0 period offset width — A literal and three integer quadruplet that specifies no
positive pulse during non-scan operation.

LBISTArchitect Reference Manual, v2017.3 725

September 2017
Fault Simulation Command Dictionary
Setup Pin Constraints

R1 period offset width — A literal and three integer quadruplet that specifies
application of one negative pulse per specified period during non-scan operation.
SR1 period offset width — A literal and three integer quadruplet that specifies
application of one suppressible negative pulse.
CR1 period offset width — A literal and three integer quadruplet that specifies no
negative pulse during non-scan operation.
Where:
period — An integer that specifies the total number of test cycles. The Set Test Cycle
command defines the number of timeframes per test cycle.
offset — An integer that specifies the timeframe in which values start to change in each
period.
width — An integer that specifies the pulse width of the pulse type waveform.
Examples
The following example sets one primary input to behave as a clock and the rest of the primary
inputs to behave as a constant high signal:
set test cycle 2
add pin constraints ph1 r1 1 0 1
setup pin constraints c1

Related Commands
Add Pin Constraints Report Pin Constraints
Delete Pin Constraints

726 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Setup Tied Signals

Setup Tied Signals

Scope: Setup mode
Usage
SETup TIed Signals X | 1 | 0 | Z
Description
Changes the default value for floating pins and floating nets which do not have assigned values.
The Setup Tied Signals command specifies the default value that the tool ties to all floating nets
and floating pins that you do not specify with the Add Tied Signals command. Upon invocation
of the tool, if you do not assign a specific value, the tool assumes the default value is unknown
(X).
If the model is already flattened and then you use this command, you must delete and recreate
the flattened model.
Arguments
• X
A literal that ties the floating nets or pins to unknown. This is the default upon invocation of
the tool.
• 0
A literal that ties the floating nets or pins to logic 0 (low to ground).
• 1
A literal that ties the floating nets or pins to logic 1 (high to voltage source).
• Z
A literal that ties the floating nets or pins to high-impedance.
Examples
The following example ties floating net vcc to logic 1, ties the remaining unspecified floating
nets and pins to logic 0, then performs BIST simulation:
setup tied signals 0
add tied signals 1 vcc
set system mode fault
add faults -all
run

Related Commands
Add Tied Signals Report Tied Signals
Delete Tied Signals

LBISTArchitect Reference Manual, v2017.3 727

September 2017
Fault Simulation Command Dictionary
System

System
Scope: All modes
Usage
SYStem os_command
Description
Passes the specified command to the operating system for execution.
The System command executes one operating system command without exiting the currently
running application.
Arguments
• os_command
A required string that specifies any legal operating system command.
Examples
The following example performs a simulation run, then displays the current working directory
without exiting the tool:
set system mode fault
add faults -all
run
system pwd

728 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Update Implication Detections

Update Implication Detections

Scope: Fault mode
Usage
UPDate IMplication Detections
Description
Performs an analysis on the undetected and possibly-detected faults to see if the tool can
classify any of those faults as detected-by-implication.
By invocation default, the tool only analyzes scan-path-associated faults for the detected-by-
implication classification. The tool classifies the following faults as detected-by-implication
when you issue the Update Implication Detections command:
• A stuck-at-1 fault on the set input line of a transparent latch, scan latch, scan D flip-flop,
shadow, copy, or sequential cell when the tool detects the stuck-at-1 fault on the output.
• A stuck-at-1 fault on the reset input line of a transparent latch, scan latch, scan D flip-
flop, shadow, copy, or sequential cell when the tool detects the stuck-at-0 fault on the
output.
• A stuck-at-0 fault on a clock input line of a transparent latch, scan latch, scan flip-flop,
shadow, copy, or sequential cell when the tool detects both the stuck-at-0 and stuck-at-1
faults for the associated data line.
• A stuck-at-0 fault on a data input line of a transparent latch, scan latch, scan D flip-flop,
shadow, copy or sequential cell when the tool detects the stuck-at-0 fault and no other
ports can capture a 1.
• A stuck-at-1 fault on a data input line of a transparent latch, scan latch, scan D flip-flop,
shadow, copy, or sequential cell when the tool detects the stuck-at-1 fault on the data
output and no other port can capture a 0.
Examples
The following example causes the tool to perform an expanded analysis on faults that the tool
can detect by implication:
set system mode fault
...
add faults -all
run
update implication detections
// 12 faults were identified as detected by implication.

Related Commands
Report Faults

LBISTArchitect Reference Manual, v2017.3 729

September 2017
Fault Simulation Command Dictionary
Write Faults

Write Faults
Scope: Fault and Good modes
Usage
Stuck/Toggle Faults Usage:
WRIte FAults filename [-Replace] [-Class class_type] [-Stuck_at {01 | 0 | 1}] [-All |
object_pathname…] [-Hierarchy integer] [-Min_count integer]
[-Noeq] [-Cell_name] {[-CLOCK_Domains {ALL | clock_pathname…}
[-NO_EQUivalent_clocks]] | [-CAPture_procedures {ALL | capture_procedure_name…}]}
| {[-SCAN_Enable] [-CLOCK_Cones] [-IO] [-ASYnchronous_controls]}
Description
Writes fault information from the current fault list to a file.
The Write Faults command is identical to the Report Faults command, except that the data is
written into a file. You can review or modify the file and later load the information into the fault
list with the Load Faults command. You can use the optional arguments to narrow the focus of
the report to only specific stuck-at faults that occur on a specific object in a specific class. If you
do not specify any of the optional arguments, Write Faults writes information on all the known
faults to the file.
The file contains the following columns of information for each fault:
• fault value - The fault value may be either 0 (for stuck-at-0) or 1 (for stuck-at-1).
• fault code - A code name that indicates the lowest-level fault class assigned to the fault.
• fault site - The pin pathname of the fault site.
• cell name (optional) - The name of the cell corresponding to the fault (included only if
you used the -Cell_name argument).
You can use the -Hierarchy option to write a hierarchical summary of the selected faults. The
summary identifies the number of faults in each level of hierarchy whose level does not exceed
the specified level number. You can further specify the hierarchical summary by using the
-Min_count option which specifies the minimum number of faults that must be in a hierarchical
level before writing.
You may select to display either collapsed or uncollapsed faults by using the Set Fault Mode
command.
Arguments
• filename
A required string that specifies the name of the file where LBISTArchitect is to write the
fault information.
• -Replace
An optional switch that replaces the contents of the file if the filename already exists.

730 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Write Faults

• -Class class_type
An optional switch and literal pair that specifies the class of faults that you want to write.
The class_type argument can be either a fault class code or a fault class name. If you do not
specify a class_type, the default is to write all fault classes.
Table 4-4 on page 608 lists the valid fault class codes and their associated fault class names;
use either the code or the name when specifying the class_type argument.
• -Stuck_at 01 | 0 | 1
An optional switch and literal pair that specifies the stuck-at faults that you want to write.
The stuck-at literal choices are as follows:
01 — A literal that writes both the “stuck-at-0” and “stuck-at-1” faults. This is the
default.
0 — A literal that writes the “stuck-at-0” faults.
1 — A literal that writes the “stuck-at-1” faults.
• -All
An optional switch that writes all faults on all model, netlist primitive, and top module pins
to the file. This is the default.
• object_pathname
An optional repeatable string that specifies the list of pins or instances whose faults you
want to write.
• -Hierarchy integer
An optional switch and integer pair that specifies the maximum fault class hierarchy level
for which you want to write a hierarchical summary of the faults.
• -Min_count integer
An optional switch and integer pair that you can use with the -Hierarchy option and that
specifies the minimum number of faults that must be in a hierarchical level to write a
hierarchical summary of the faults. The default is 1.
• -Noeq
An optional switch that specifies for the tool to write the fault class of equivalent faults.
When you do not specify this switch, the tool writes an “EQ” as the fault class for any
equivalent faults. This switch is meaningful only when the Set Fault Mode command is set
to Uncollapsed.
• -CEll_name
An optional switch that specifies to list, for each reported fault, the corresponding circuit
element (ATPG library cell, Verilog primitive, primary input or primary output) as
summarized in Table 4-11. Cell names displayed for equivalent faults are based on the cells

LBISTArchitect Reference Manual, v2017.3 731

September 2017
Fault Simulation Command Dictionary
Write Faults

associated with the equivalent faults, not the cells associated with the representative faults.
This switch is valid for the stuck-at, transition, toggle and IDDQ fault models only.

Table 4-11. Name Conventions Used by Write Faults -Cell_name

Corresponding Circuit Element Listed Cell Name
ATPG library cell Name of the ATPG library cell
Supported Verilog primitive—see Name of the Verilog primitive
“Verilog Primitives” in the Tessent Cell
Library Manual
Primary input or output “primary_input” or “primary_output”

• -CLOCK_Domains {ALL | clock_pathname…}

An optional switch and literal or repeatable string pair that specifies a list of clocks and
directs the tool to write only faults that are potentially detectable using any of the specified
clocks (or equivalent clocks). For a transition fault to be potentially detectable, it must be
detectable when the same clock (one of the specified clocks or an equivalent) is used for
launch and capture. Any other type of fault must be detectable when one of the specified
clocks or equivalents is used as the capture clock. The argument choices are as follows:
ALL — A literal that specifies all the clocks in the design.
clock_pathname — A repeatable string that specifies a particular clock.
Be aware that a fault written using this switch might also be detectable by an unspecified
clock.
• -NO_EQUivalent_clocks
An optional switch that prevents the -Clock_domains switch from writing faults in
equivalent clock domains.
• -CAPture_procedures {ALL | capture_procedure_name…}
An optional switch and literal or repeatable string pair that specifies a list of enabled named
capture procedures and directs the tool to write faults that are potentially detectable by any
of the specified procedures. The argument choices are as follows:
ALL — A literal that specifies all enabled named capture procedures.
capture_procedure_name — A repeatable string that specifies a particular enabled
named capture procedure.
• -SCAN_Enable
An optional switch that specifies to only write faults that fan out to the select lines of
multiplexers in the scan path. For this switch, a multiplexer is either a MUX simulation
primitive or a nonprimitive type multiplexer composed of AND and OR gates. Basically,
this switch writes all faults that are in the fanin cone of local scan enable signals and are
dominated by them.

732 LBISTArchitect Reference Manual, v2017.3

September 2017
 Fault Simulation Command Dictionary
Write Faults

• -CLOCK_Cones
An optional switch that specifies to only write faults that fan out to clock ports, Set/Reset
ports or Read/Write control ports of memory elements, including RAM and ROM. Notice
that this applies to any memory elements, not just scan cells.
• -IO
An optional switch that specifies to write faults that are:
• Only controlled by PIs — To be acted on by the -IO switch, a PI either must not be
defined as a clock or, if defined as clock (or read/write control), must be constrained
off during capture.
• Only observed by POs
• -ASYnchronous_controls
An optional switch that specifies to only write faults that fan out to Set/Reset ports of state
elements and RAMs. This switch applies to a subset of the faults the -CLOCK_Cones
switch writes.
Examples
The following example performs a simulation run, then writes all the untestable faults to a file
for review:
set system mode fault
add faults -all
run
write faults faultlist -class ut

Related Commands
Add Faults Report Faults
Delete Faults Set Fault Mode
Load Faults

LBISTArchitect Reference Manual, v2017.3 733

September 2017
Fault Simulation Command Dictionary
Write Faults

734 LBISTArchitect Reference Manual, v2017.3

September 2017
 Chapter 5
Shell Commands

Shell Command Descriptions

The remaining pages in this chapter describe the shell commands that you use to invoke
LBISTArchitect and the Logic BIST Task Flow Manager. The notational conventions are the
same as those used in other parts of the manual. Do not enter any of the special notational
characters (such as, {}, [], or |) when typing a command.

Command Line Syntax Conventions

This manual uses the following command usage line syntax conventions.

Table 5-1. Conventions for Command Line Syntax

Convention Example Usage
UPPercase REPort ENvironment Required command letters are in uppercase; in
(substitute product-specific most cases, you may omit lowercase letters when
examples throughout) 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 FAults -All A boldface font indicates a required argument.
[ ] EXIt [-Force] Square brackets enclose optional arguments. Do
not enter the brackets.
Italic DOFile filename An italic font indicates a user-supplied argument.
{ } ADD CEll Library library Braces enclose arguments to show grouping. Do
{{-Model name} | -All} not enter the braces.
| ADD CEll Library library The vertical bar indicates an either/or choice
{{-Model 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.

LBISTArchitect Reference Manual, v2017.3 735

September 2017
Shell Commands
Command Line Syntax Conventions

Table 5-1. Conventions for Command Line Syntax

Convention Example Usage
… ADD CLocks off_state An ellipsis follows an argument that may appear
primary_input_pin… more than once. Do not include the ellipsis when
[-Internal] entering commands.

736 LBISTArchitect Reference Manual, v2017.3

September 2017
 Shell Commands
lbistarchitect

lbistarchitect
Usage
lbistarchitect {{-bist_ready bist_ready_arguments} | {-bist_controller
bist_controller_arguments} | {-fault_simulation fault_simulation_arguments} | {-tbgen
tbgen_arguments} | {-tvgen tvgen_arguments} | {-FAILuremap failuremap_arguments}
| {[-help] [-versions]} [-LIBRARY_ARRAY_DELIMITER {square | angle}]
Note
Shell commands do not follow the minimum typing rule.

Description
This command is a unified, process-phase invocation for LBISTArchitect. Choosing one of the
phase arguments initiates a phase in the logic BIST implementation—BIST-Ready phase, BIST
Controller Generation phase, Fault Simulation phase, Test Bench Generation phase, Test Vector
Generation phase, and the Failuremap Diagnostics phase.
Arguments
• -bist_ready bist_ready_arguments
This switch and set of arguments invokes the BIST-Ready phase. The BIST-Ready phase
performs DFT rule checks, scan insertion, X bounding, and MTPI test point analysis and
insertion. You must also supply any other required BIST-Ready design information, as well
as any desired options, with the bist_ready_arguments:
design_name [-VERilog] [-32 | -64] [-LIBrary filename] [-INCDIR include_directory]
[-LICense_wait {minutes | NONE | UNLimited}] [-SEnsitive | -INsensitive] [-LOG
filename [-Replace]] [-TOP module_name] [-DOfile dofile_name] [-HIStory] | [-Help |
-Version] [-DISABLE_Version_match]
Example
lbistarchitect -bist_ready big_alu_scan.v -library dft_lib -log brlog.log -replace

For descriptions of the switches common between multiple phases, refer to the first item
“design_name” beginning on page 747. The following switches are specific to the
-bist_ready phase, and therefore are described here.
-32 | -64
An optional switch that invokes the 32-bit or 64-bit version of the software. The
default is 64-bit. If the platform does not support the specified version, the tool gives
a warning message and ignores the switch.

LBISTArchitect Reference Manual, v2017.3 737

September 2017
Shell Commands
lbistarchitect

-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.
• -bist_controller bist_controller_arguments
This switch and set of arguments invokes the BIST Controller Synthesis phase. This phase
synthesizes and generates the RTL description of the logic BIST controller. You must also
supply any other required BIST Controller design information, as well as any desired
options, with the bist_controller_arguments:
design_name [-VErilog] [-LOGfile filename [-Replace]] [-DOfile filename [-HIStory]]
[-Help | -Usage | -MANual | -Version] [-DISABLE_Version_match]
Example
lbistarchitect -bist_controller big_alu_top_lbist.v -verilog -logfile balog_top.log \\
-replace

• -fault_simulation fault_simulation_arguments
This switch and set of arguments invokes the logic BIST Fault Simulation phase. This phase
fault simulates the design using bit-accurate logic BIST patterns and generates the good-
circuit signature. You must also add any other required Fault Simulation arguments, as well
as any desired options, with the fault_simulation_arguments:
{design_name [-VERilog] [-LIBrary filename]
[-INCDIR include_directory] [-SEnsitive | -INsensitive] [-LOGfile filename [-REPlace]]
[-TOP model_name] [-DOfile dofile_name [-HIStory]]} | [-Help | -Usage | -Version]
Example
lbistarchitect -fault_simulation big_alu_bs.v -verilog -library dft_lib -logfile \\
balog_fsim.log -replace

• -tvgen tvgen_argments
This switch and set of arguments invokes the Test Vector Generator, a command-line-only
phase for generating test vectors and diagnostics.
This phase uses the Fault Simulation phase LFSR trace file as input and generates a WGL
output file. You can run this phase in either the default mode where the -Start, -Stop, or
-Check switches signify that the test vectors the tool generates will be performing a regular
BIST pattern run, across a pattern range. Or, you can run this phase in diagnostics mode by
either specifying a single step action with the -Check 1, or the -Funload option.

738 LBISTArchitect Reference Manual, v2017.3

September 2017
 Shell Commands
lbistarchitect

The design_name is the pathname of the file that contains the RTL description of the Logic
BIST Controller, and the interconnects between the controller and the core. The default file
name is design_bist.v. This file is written out during the BIST Controller synthesis phase.
{design_name output_filename [-FOrmat Wgl | Stil] [-BSDArchitect [-BSDL_file
filename]] [-TRace lfsr_trace_file] [[-STArt pattern_number] [-STOp pattern_number]]
{[[[-CHeck interval] | [SAmple sample_size]] | [[-Runload] | [-Unload pattern_number] |
[-FUnload unload_filename] [-PAttern_source filename] [-SIngle_scan_chain]]}
[-Interface_period period_in_ns] [-PEriod period_in_ns] [-Replace] {[-shift_rate rate
{-delay_cycles cycles | -se_on_cycles on_cycles -se_off_cycles off_cycles}]} [-HELP | -
VERSION]
output_filename — An optional string when you are in diagnostics mode that specifies
the name of the file where TVGen writes the diagnostic output results. You are in
diagnostics mode when you either issue the -Check switch with an interval of 1, or
when you issue the -FUnload switch.
By default, if you do not specify the value of the output_filename, the tool writes the
WGL information to the same filename that LBISTArchitect used for writing the
WGL information during the BIST Controller phase. This phase only overwrites an
existing output file if you used the -Replace switch.
-FOrmat [Wgl | Stil] — An optional switch and literal pair specifying which output
format the tool will write the test vectors. The default format is WGL.
-BSDArchitect [-BSDL_file filename] — An optional switch with a corresponding
optional switch and string pair. This option requires a valid BSDArchitect license.
Before using this switch, you must first run BSDArchitect to generate the TAP
controller and interconnects. BSDArchitect generates the BSDL file when it
generates the boundary scan controller and the interconnects.
This switch initiates the generation of TAP centric test vectors. This switch forces the
single scan chain behavior. The default name of the BSDL file is
design_name_bscan.bsd. You can override the default filename with the -BSDL_file
switch.
The default names for the generated files are enitity_lbist_bscan.test_seq (test
sequence file) and entity_lbist_bscan.wgl (test vector file). You can override these
default filenames using the Setup File Naming command.
-TRace lfsr_trace_file — An optional switch and string pair that specifies the name of
the LFSR trace file you created during the Fault Simulation phase of LBISTArchitect.
By default, the tool extracts the pathname of the trace file from the configuration data
for the BISTed core design.
If you are running diagnostics from a different location than where you performed the
BIST controller synthesis phase, the design’s configuration data may point to an
incorrect location for the lfsr_trace_file. Therefore, you can explicitly specify the
location to the correct lfsr_trace_file with the -Trace switch.
-STArt pattern_number — An optional switch and integer pair that specifies the number
of the first pattern to be run. The default start value of pattern_number is 0.

LBISTArchitect Reference Manual, v2017.3 739

September 2017
Shell Commands
lbistarchitect

-STOp pattern_number — An optional switch and integer pair that specifies the number
of the last pattern of the run. The default stop value of pattern_number is the end of
the pattern space, pattern N-1.
-CHeck interval — An optional switch and integer pair that specifies to start running
patterns at the specified start pattern number (or pattern 0), run the number of patterns
specified by interval, check the MISR value, and continue checking at every interval,
through to the stop pattern number (or N-1). The default is to check only at the end of
the run.
If the check interval is 1, then the tool uses the BIST controller’s MISR reload
diagnostic mode. Otherwise, if the check interval is not 1, the checking will be
performed using a sequence of run interval sub ranges with full BIST controller
reinitializations.
-SAmple sample_size — An optional switch and string pair that controls the selection of
sub ranges of BIST patterns to execute. The argument is either an absolute pattern
count or a percentage value. This switch causes the tool to split the pattern region
from start to stop into a number of sub regions of the sample_size. These pattern
regions come from the flush test patterns and the MTPI phases within the overall
pattern region.
You can use this switch as a way of running through a sample of important patterns in
the BIST controller.
The -Sample and -Check switches are mutually exclusive. If you also specify the -
Funload, or -Unload switch, then the test vectors will perform only the specified
unloads, not a pattern region of the BIST controller run.
-Runload — An optional switch that specifies for the output file (set of test vectors) to
run the range of patterns (as specified by -Start and -Stop switches) with the BIST
controller in diagnostics mode.
After each BIST pattern completes the capture phase, the BIST controller waits, and
the test vectors unload the captured data (using the bist_diag_clk clock control input
signal). The tool then compares the unloaded scan chain contents to the expected
values for the pattern. Once these series of steps are done, the BIST controller
advances to the next pattern.
This switch can be useful to cause a range of BIST patterns to be unloaded from the
running BIST controller.
-Unload pattern_number — An optional switch and string pair that specifies that the test
vectors will be performing scan chain unloads rather than the default conventional
BIST pattern run. This mode of operation is mutually exclusive to the conventional
BIST pattern run. You can specify any number of unload patterns by repeating the
switch and string pair.
The tool will serially unload the scan chain contents for the pattern_number you
specify, which is what the tool would normally observe in the MISR.
-FUnload unload_filename — An optional switch and string pair that specifies that the
test vectors will be performing scan chain unloads rather than the default
conventional BIST pattern run. This mode of operation is mutually exclusive to the

740 LBISTArchitect Reference Manual, v2017.3

September 2017
 Shell Commands
lbistarchitect

conventional BIST pattern run. This switch specifies the pathname of an unload file
in a specified format.
The tool will serially unload the scan chain contents for the pattern_number you
specify, which is what the tool would normally observe in the MISR.
-PAttern_source pattern_filename — An optional switch that specifies an explicit
pathname to the pattern file. When TVGen generates the scan chain unload vectors,
the tool needs to read in the BIST pattern file to be able to specify the expected chain
content values for the unload.
By default, the tool reads in the patterns from the file location that is specified in the
metadata for the BISTed core design. However, if you are running diagnostics from a
different location than where you performed the BIST controller synthesis phase, the
pattern source file in the metadata may not contain the correct information for the
diagnostic process. Therefore, you can explicitly specify the location to the correct
pattern_filename with the -Pattern switch.
-SIngle_scan_chain — An optional switch specifying that any unloading of the core
scan chains the tool performs using the concatenated single scan chain, rather than the
top-level scan chains.
-Interface_period period_in_ns — An optional switch that allows you to overload the
default period value that the tool reads from metadata.
-PEriod period_in_ns — An optional switch that allows you to overload the default fast
clock period value that the tool reads from metadata.
-Replace — An optional switch that specifies that TVGen overwrites the existing output
file.
-shift_rate rate — An optional switch and integer pair specifying that the generated test
bench and vectors explicitly load the shift_rate register in the controller with a value
of (rate - 1). You use this switch in conjunction with either of the following switches:
o -delay_cycles cycles
o -se_on_cycles on_cycles -se_off_cycles off_cycles
You must specify rate with an integer between 1 and 8 meaning the following:
1 — Selects full speed shifting.
2 — Selects a shift speed of 1/2 bist_clk.
3 — Selects a shift speed of 1/3rd bist_clk.
4 — Selects a shift speed of 1/4th bist_clk.
5 — Selects a shift speed of 1/5th bist_clk.
6 — Selects a shift speed of1/6th bist_clk.
7 — Selects a shift speed of 1/7th bist_clk.
8 — Selects a shift speed of 1/8th bist_clk.

LBISTArchitect Reference Manual, v2017.3 741

September 2017
Shell Commands
lbistarchitect

Note
The -delay_cycles cycles and {-se_on_cycles on_cycles -se_off_cycles off_cycles} are
mutually exclusive.

-delay_cycles cycles — An optional switch and integer pair specifying that the
generated test bench and vectors explicitly load the scan enable control register with
the value of in cycles bits 0 to 3 and 4 to 7. This configures the hardware to generate
the specified number of delay cycles for both scan enable transitions. You must
specify cycle using an integer between 0 (zero) and 15.
See “Using Delay Cycles for Scan Enable Transition” in the LBISTArchitect Process
Guide for additional information on delay cycles.
-se_on_cycles on_cycles -se_off_cycles off_cycles — An optional switch and integer
quadruplet specifying that the generated test bench and vectors explicitly load the
scan enable control register with the value of on_cycles in bits 0 to 3 and the value of
off_cycles in bits 4 to 7. This configures the hardware to generate on_cycles delay
cycles during the scan enable on transition, and off_cycles delay cycles during the
scan enable off transition. You must specify both on_cycles and off_cycles, and you
must these values using integers between 0 (zero) and 15.
See “Using Delay Cycles for Scan Enable Transition” in the LBISTArchitect Process
Guide for additional information on delay cycles.
• -tbgen tbgen_argments
This switch and set of arguments invokes the Test Bench Generator, a command-line-only
phase useful for signature mismatch debugging.
This phase uses the Fault Simulation phase LFSR trace file as input and generates a Verilog
or VHDL test bench. You can run this phase in either the default mode where the -Start,
-Stop, or -Check switches signifies that the test bench the tool generates will be performing
a regular BIST pattern run, across a pattern range. Or, you can run this phase in diagnostics
mode by specifying a single step action with the -Check 1 option with an output_filename.
The design_name is the pathname of the file that contains the RTL description of the Logic
BIST Controller, and the interconnects between the controller and the core. The default file
name is design_bist.v. This file is written out during the BIST Controller synthesis phase.
Note
If a trace file is not available because fault simulation has not been run, the -tbgen step
gives a warning but creates the default test bench.

{design_name output_filename [-BSDArchitect [-BSDL_file filename]] [-TRace

lfsr_trace_file] [[-STArt pattern_number] [-STOp pattern_number]] {[[[-CHeck interval] |
[-SAmple sample_size]] | [[-Runload | [-Unload pattern_number] | -FUnload
unload_filename [-PAttern_source filename]]} [-Replace] {[-shift_rate rate {-delay_cycles
cycles | -se_on_cycles on_cycles -se_off_cycles off_cycles}]} [-HELP | -VERSION]

742 LBISTArchitect Reference Manual, v2017.3

September 2017
 Shell Commands
lbistarchitect

output_filename — An optional string when you are in diagnostics mode that specifies
the name of the file where TBGen writes the diagnostic output results. You are in
diagnostics mode when you either issue the -Check switch with an interval of 1, or
when you issue the -FUnload switch. The HDL language of the generated test bench
will be the same as that of the BISTed core.
By default, if you do not specify the output_filename, the tool writes the test bench to
the same filename as you used for writing the test bench during the BIST Controller
Synthesis phase. This phase only overwrites an existing output file if you used the -
Replace switch.
-BSDArchitect [-BSDL_file filename] — An optional switch with a corresponding
optional switch and string pair. This option requires a valid BSDArchitect license.
Before using this switch, you must first run BSDArchitect to generate the TAP
controller and interconnects. BSDArchitect generates the BSDL file when it
generates the boundary scan controller and the interconnects.
This switch initiates the generation of the TAP centric test bench. This option forces
single scan chain behavior. The default name of the BSDL file is
design_name_bscan.bsd. You can override the default filename with the -BSDL_file
switch.
The default names for the generated files are enitity_lbist_bscan.test_seq (test
sequence file) and enitity_lbist_bscan_tb.suffix (test bench file). You can override
these default filenames using the Setup File Naming command.
-TRace lfsr_trace_file — An optional switch and string pair that specifies the name of
the LFSR trace file you created during the Fault Simulation phase of LBISTArchitect.
By default, the tool extracts the pathname of the trace file from the metadata for the
BISTed core design.
The lfsr_trace_file may not contain the correct information for the diagnostic process
if you are running diagnostics from a different location than where you performed the
BIST controller synthesis phase. Therefore, you can explicitly specify the location to
the correct lfsr_trace_file with the -Trace switch.
-STArt pattern_number — An optional switch and integer pair that specifies the number
of the first full pattern to be run. The default start value of pattern_number is 0.
-STOp pattern_number — An optional switch and integer pair that specifies the number
of the last pattern of the run. The default stop value of pattern_number is the end of
the pattern space, pattern N-1.
-CHeck interval — An optional switch and integer pair that specifies to start running
patterns at the specified start pattern number (or pattern 0), run the number of patterns
specified by interval, check the MISR value, and continue checking at every interval,
through to the stop pattern number (or N-1). The default is to check only at the end of
the run.
If the check interval is 1, then the tool uses the BIST controller’s MISR reload
diagnostic mode. Otherwise, if the check interval is not 1, the checking will be
performed using a sequence of run interval sub ranges with full BIST controller
reinitializations.

LBISTArchitect Reference Manual, v2017.3 743

September 2017
Shell Commands
lbistarchitect

-SAmple sample_size — An optional switch and string pair that controls the selection of
sub ranges of BIST patterns to execute. The argument is either an absolute pattern
count or a percentage value. This switch causes the tool to split the pattern region
from start to stop into a number of sub regions of the sample_size. These pattern
regions come from the flush test patterns and the MTPI phases within the overall
pattern region.
You can use this switch as a way of running through a sample of important patterns in
the BIST controller.
The -Sample and -Check switches are mutually exclusive. If you also specify the
-Funload, or -Unload switch, then the test vectors will perform only the specified
unloads, not a pattern region of the BIST controller run.
-Runload — An optional switch that specifies for the output file (test bench) to run the
range of patterns (as specified by -Start and -Stop switches) with the BIST controller
in diagnostics mode.
After each BIST pattern completes the capture phase, the BIST controller waits, and
the test bench unloads the captured data (using the bist_diag_clk clock control input
signal). The tool then compares the unloaded scan chain contents to the expected
values for the pattern. Once these series of steps are done, the BIST controller
advances to the next pattern.
This switch can be useful to cause a range of BIST patterns to be unloaded from the
running BIST controller.
-Unload pattern_number — An optional switch and string pair that specifies that the test
bench will be performing scan chain unloads rather than the default conventional
BIST pattern run. This mode of operation is mutually exclusive to the conventional
BIST pattern run. You can specify any number of unload patterns by repeating the
switch and string pair.
The tool will serially unload the scan chain contents for the pattern_number you
specify, which is what the tool would normally observe in the MISR.
-FUnload unload_filename — An optional switch and string pair that specifies that the
test bench will be performing scan chain unloads rather than the default conventional
BIST pattern run. This mode of operation is mutually exclusive to the conventional
BIST pattern run. This switch specifies the pathname of an unload file in a specified
format.
The tool will serially unload the scan chain contents for the pattern_number you
specify, which is what the tool would normally observe in the MISR.
-PAttern_source pattern_filename — An optional switch that specifies an explicit
pathname to the pattern file. When TBGen generates the scan chain unload test
bench, the tool needs to read in the BIST pattern file to be able to specify the expected
chain content values for the unload.
By default, the tool reads in the patterns from the file location that is specified in the
metadata for the BISTed core design. However, if you are running diagnostics from a
different location than where you performed the BIST controller synthesize phase, the
pattern source file in the metadata may not contain the correct information for the

744 LBISTArchitect Reference Manual, v2017.3

September 2017
 Shell Commands
lbistarchitect

diagnostic process. Therefore, you can explicitly specify the location to the correct
pattern_filename with the -Pattern switch.
-Replace — An optional switch that specifies that TBGen overwrites the existing output
file.
-shift_rate rate — An optional switch and integer pair specifying that the generated test
bench and vectors explicitly load the shift_rate register in the controller with a value
of (rate - 1). You use this switch in conjunction with either of the following switches:
o -delay_cycles cycles
o -se_on_cycles on_cycles -se_off_cycles off_cycles
You must specify rate with an integer between 1 and 8 meaning the following:
1 — Selects full speed shifting.
2 — Selects a shift speed of 1/2 bist_clk.
3 — Selects a shift speed of 1/3rd bist_clk.
4 — Selects a shift speed of 1/4th bist_clk.
5 — Selects a shift speed of 1/5th bist_clk.
6 — Selects a shift speed of1/6th bist_clk.
7 — Selects a shift speed of 1/7th bist_clk.
8 — Selects a shift speed of 1/8th bist_clk.
Note
The -delay_cycles cycles and {-se_on_cycles on_cycles -se_off_cycles off_cycles} are
mutually exclusive.

-delay_cycles cycles — An optional switch and integer pair specifying that the
generated test bench and vectors explicitly load the scan enable control register with
the value of in cycles bits 0 to 3 and 4 to 7. This configures the hardware to generate
the specified number of delay cycles for both scan enable transitions. You must
specify cycle using an integer between 0 (zero) and 15.
See “Using Delay Cycles for Scan Enable Transition” in the LBISTArchitect Process
Guide for additional information on delay cycles.
-se_on_cycles on_cycles -se_off_cycles off_cycles — An optional switch and integer
quadruplet specifying that the generated test bench and vectors explicitly load the
scan enable control register with the value of on_cycles in bits 0 to 3 and the value of
off_cycles in bits 4 to 7. This configures the hardware to generate on_cycles delay
cycles during the scan enable on transition, and off_cycles delay cycles during the
scan enable off transition. You must specify both on_cycles and off_cycles, and you
must these values using integers between 0 (zero) and 15.
See “Using Delay Cycles for Scan Enable Transition” in the LBISTArchitect Process
Guide for additional information on delay cycles.

LBISTArchitect Reference Manual, v2017.3 745

September 2017
Shell Commands
lbistarchitect

• -FAILuremap failuremap_arguments
This switch and set of arguments invokes the command-line only diagnostic phase. This
phase takes as input both the source reference (WGL, Verilog, or VHDL test bench), and the
reformatted logfile (from either the ATE or the event-based simulator). Your first pass
through this phase generates information on the failing patterns, and your second pass
through this phase generates the corresponding failing bits within the scan cells.
The design_name is the pathname of the file that contains the RTL description of the Logic
BIST Controller, and the interconnects between the controller and the core. The default file
name is design_bist.v. This file is written out during the BIST Controller Generation phase.
{design_name
[source_reference] [reformatted_logfile] [output_file]
source_reference — The pathname to the WGL, Verilog, or VHDL test bench
(source_reference) file that you used to perform the event-based simulation run. The
tool processes this specially annotated source_reference file, along with the logfile
that you reformatted. Both TVGen and TBGen place annotations in the WGL or test
bench file to tie the time and cycle values to the BIST patterns. The information in
this specially annotated source_reference file is what allows the tool to derive the
relationship between the vector run time and the associated pattern number.
reformatted_logfile — The pathname to the MISR fail logfile (first cycle through
-failuremap), or the pathname to the pattern fail logfile (the second cycle through
-failuremap). The following example shows the format of the failing BIST pattern file
(time-based):
%MISR_FAIL
# this is a comment list
# <time> <output>
1020ns bist_data_sout
2001ns bist_data_sout
2020010ps bist_data_sount

The time can be in ps, ns, us, or ms.

The following example shows the format of the failing BIST pattern file (cycle-
based):
%MISR_FAIL
# this is a comment list
# <time> <output>
cycle 100 sout_1
cycle 150 sout_2
cycle 300 shared_pin[0]

The following example shows the format of the failing BIST pattern unload file
(time-based):
%PATTERN_FAIL
# this is a comment list
# <time> <output> <expected_value> <actual_value>
1020ns sout_1 H L
2001ns sout_2 L H
2020010ps shared_pin[0] L H

746 LBISTArchitect Reference Manual, v2017.3

September 2017
 Shell Commands
lbistarchitect

The following example shows the format of the failing BIST pattern unload file
(cycle-based):
%PATTERN_FAIL
# this is a comment list
# <time> <output> <expected_value> <actual_value>
cycle_102 sout_1 H L
cycle_200 sout_2 L H
cycle_202 shared_pin[0] L H

The following example shows three failing patterns, four passing patterns, one flush
test pattern, and three non flush test patterns in the different MTPI phases:
%PATTERN_UNLOAD
# this is a comment list
# <pattern> <intent>
2 pass flush
33 pass MTPI phase 0
1024 fail
2043 fail
4096 pass MTPI phase 1
8109 fail
8192 pass MTPI phase 2

output_file — The pathname to where the tool writes the results of the prediagnostic
failuremap phase.
• design_name
A required string that specifies the pathname of the design on which to invoke. The design
format is derived either from a supplied format switch (-VERilog) or from the design_name
suffix.
• -VErilog
An optional switch specifying that design_name is a netlist in Verilog format.
• -VHdl (Core Fault Simulation Only)
An optional switch specifying that design_name is a netlist in VHDL format as supported by
LBISTArchitect.
• -LIBrary library_name
An optional switch and repeatable string pair that specifies the names of the files containing
the ATPG library descriptions for all cell models in design_name. You can use wildcarding
as supported by the invocation shell to specify multiple library files.
This argument is not required if the specified netlist fully defines all the primitives in the
design (which can occur in Verilog format). If the library does not contain scan models for
any of the sequential element your design uses, LBISTArchitect issues a warning message
stating this when you switch from Setup mode to Dft mode during the session.

LBISTArchitect Reference Manual, v2017.3 747

September 2017
Shell Commands
lbistarchitect

• -INCDIR include_directory
An optional switch and repeatable string that lists directories relative to which the tool
should search for files included in a Verilog design with the ‘include compiler directive.
This enables you to use simple filenames in ‘include directives and, when invoking
LBISTArchitect, use the -Incdir switch to specify the pathnames of the directories
containing the files. Each include_directory in the list should be either a relative directory
pathname, relative to the current (tool invocation) directory, or an absolute directory
pathname.
The tool searches for include files relative to the following locations in the following order
of precedence:
1. Absolute pathnames specified by ‘include directives in the Verilog design
2. Directories specified with the -Incdir invocation switch, if used
When locating ‘include file targets that are a relative paths, the tool appends the target
path to each specified include_directory to obtain the pathname of the include file. The
tool searches these directories in the same order they are listed, left to right, in the
command. If identically named files exist in multiple directories, the tool reads in the
first file it finds and ignores others with the same name.
A search path may contain the asterisk (*) and other wildcard characters supported by
the invocation shell. For example, if you specify “-incdir sp*”, the tool recognizes every
directory within the current directory that starts with “sp” as a search path.
3. Directory where the calling file is located
4. Directory from which the tool was invoked (current directory)
• -INSENsitive | -SENsitive
Optional switches that specify for the tool to consider pin, instance, and net pathnames case-
insensitive or case-sensitive. The default is case-insensitive for all netlist formats except
Verilog, which the tool treats as case-sensitive.
Regardless of the use of this switch, command names are always case-insensitive.
• -LOGfile filename [-Replace]
An optional switch and string pair that specifies the name of the file to which you want
LBISTArchitect to write all session information. The default is to display session
information to the standard output.
-Replace — An optional switch that specifies to overwrite the -LOGfile filename if one
by the same name already exists.
• -TOP model_name
An optional switch and string pair that specifies the name of the top-level model in the
netlist. If the netlist describes multiple top modules and you do not use this argument,
LBISTArchitect assumes the first top to be the top module.

748 LBISTArchitect Reference Manual, v2017.3

September 2017
 Shell Commands
lbistarchitect

• -DOfile dofile_name [-HIStory]

An optional switch and string pair that specifies the name of the dofile that you want the tool
to execute upon invocation.
-HIStory — An optional switch that specifies for the tool to add the commands from a
dofile to the command line history list. By default, the commands in a dofile are not
inserted into the history list, but the dofile command itself is added to the list. The
tool ignores this switch if you issue it without the -DOfile switch.
• -Help
An optional switch that displays a message that contains all the LBISTArchitect invocation
switches and a brief description of each. It then causes the tool to exit.
• -Usage
An optional switch that displays a message that contains just the LBISTArchitect invocation
switches, with no descriptions. It then causes the tool to exit.
• -Version
An optional switch that causes display of the versions of all the tools that interface with
LBISTArchitect. It then causes the tool to exit.
• -DISABLE_Version_match
An optional switch only available in the -bist_ready and -bist_controller phases that allows
you to run mismatched version numbers of the tool. At times you may want to use a newer
version of LBISTArchitect to run portions of the LBISTArchitect flow (such as BIST
controller generation) without having to re-run the earlier steps. The version number of the
software is embedded in the configuration file, and this switch allows the tool to accept a
configuration file with a different version of the software than you are currently using. If
you are using different versions, the logfile will contain a warning message listing both
version numbers.
• -LIBRARY_ARRAY_DELIMITER {square | angle}
An optional switch that sets the default array delimiter for library parsing to either square
brackets “[]” or angle brackets “<>”. The default is “[]”.
Note
If the format of the configuration file has changed between the different releases, there is
a good chance that the tool will not understand those differences, and will exit with an
error message.

LBISTArchitect Reference Manual, v2017.3 749

September 2017
Shell Commands
lbistarchitect

750 LBISTArchitect Reference Manual, v2017.3

September 2017
 Appendix A
Getting Help

There are several ways to get help when setting up and using Tessent software tools. Depending
on your need, help is available from documentation, online command help, and Mentor
Graphics Support.
The Tessent Documentation System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Mentor Support Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752

The Tessent Documentation System

At the center of the documentation system is the InfoHub that supports both PDF and HTML
content. From the InfoHub, you can access all locally installed product documentation, system
administration documentation, videos, and tutorials. For users who want to use PDF, you have a
PDF bookcase file that provides access to all the installed PDF files.
For information on defining default HTML browsers, setting up browser options, and setting the
default PDF viewer, refer to the Mentor Documentation System manual.
You can access the documentation in the following ways:

• Shell Command — On Linux platforms, enter mgcdocs at the shell prompt or invoke a
Tessent tool with the -Manual invocation switch.
• File System — Access the Tessent InfoHub or PDF bookcase directly from your file
system, without invoking a Tessent tool. For example:
HTML:
firefox $MGC_DFT/docs/infohubs/index.html

PDF:
acroread $MGC_DFT/docs/pdfdocs/_bk_tessent.pdf

• Application Online Help — You can get contextual online help within most Tessent
tools by using the “help -manual” tool command:
> help dofile -manual

This command opens the appropriate reference manual at the “dofile” command
description.

LBISTArchitect Reference Manual, v2017.3 751

September 2017
Getting Help
Mentor Support Services

Mentor Support Services

Mentor provides a range of industry-leading support services that keep design teams productive
and up-to-date with Mentor products. A Mentor support contract includes the following:

• Software Updates — Get the latest releases and product enhancements to keep your
environment current.
• Mentor Graphics Support Center — Access our online knowledge base, personalized
to your Mentor products.
• Support Forums — Learn, share, and connect with other Mentor users.
• Technical Support — Collaborate with Mentor support engineers to solve complex
design challenges.
• Regular Communications — Receive the latest knowledge base articles and
announcements for your Mentor products.
• Mentor Ideas — Share ideas and vote for your favorites to shape future products.
More information is available here:

https://support.mentor.com/

If your site is under a current support contract, but you do not have a Support Center login,
register today:

https://support.mentor.com/register

752 LBISTArchitect Reference Manual, v2017.3

September 2017
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Index

reset state, 445

Index

—B— run, 446

BIST controller commands save BIST, 447
add capture window, 368 save history, 449
add cell models, 369 set bist clock, 451
add clocks, 371, 373 set BIST enables, 452
add lfsr connections, 375 set capture waveform, 453
add lfsr taps, 378 set clock buffer, 459
add lfsrs, 380 set clock period, 461, 463
add pin constraints, 383 set dofile abort, 465
add scan pins, 387 set dynamic x_bounding, 466
add set_reset clocks, 389 set iscan interface, 468
b, 196 set lbist controller, 469
connect iscan chains, 394 set logfile handling, 474
delete capture window, 398 set output format, 476
delete cell models, 399 set retiming logic, 477
delete clocks, 400 set rtl hierarchy, 480
delete lfsr connections, 401 set rtl prefix, 481
delete lfsr taps, 402 set scan enables, 482
delete lfsrs, 403 set scan_enable switching, 483
delete pin constraints, 404 set shift_rate divisor, 485
delete scan pins, 407 set testpoint parameters, 486
delete set_reset clocks, 408 setup file naming, 488
disconnect iscan chains, 411 setup pin constraints, 493
dofile, 413 setup scan pins, 495
exit, 414 setup synthesis script, 499
help, 415 system, 500
history, 416 BIST-Ready commands
report capture window, 426 add black box, 28
report cell models, 427 add buffer insertion, 30
report clocks, 428 add cell models, 32
report configuration_data commands, 429 add clock groups, 35
report environment, 430 add clocks, 37
report lfsr connections, 432 add mapping definition, 40
report pin constraints, 434 add multi_cycle path, 43
report primary inputs, 437 add nofaults, 44
report primary outputs, 438 add nonscan instances, 47
report primitive polynomials, 439 add nonscan models, 49
report scan pins, 441 add notest points, 50
report set_reset clocks, 442 add output masks, 52

LBISTArchitect Reference Manual, v2017.3 753

September 2017
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

add pin constraints, 54 dofile, 139

add pin equivalences, 56 echo, 140
add primary inputs, 57 exit, 142
add primary outputs, 58 f, 196
add read controls, 59 find design names, 143
add scan chains, 60 help, 148
add scan group, 62 history, 149
add scan instances, 64 insert test logic, 151
add scan models, 66 load static_timing report, 158
add scan pins, 68 printenv, 161
add test points, 78 read procfile, 162
add tied signals, 82 report BIST bounding, 165
add write controls, 84 report black box, 166
alias, 85, 545 report buffer insertion, 168
analyze control signals, 87 report cell models, 169
analyze input control, 89 report circuit components, 171
analyze output observe, 90 report clock groups, 174
analyze testability, 91 report clocks, 175
archive test_points, 94 report configuration_data commands, 176
delete black box, 96 report control signals, 178
delete buffer insertion, 97 report dft check, 180
delete cell models, 99 report drc rules, 183
delete clock groups, 101 report environment, 188
delete clocks, 102 report faults, 190
delete mapping definition, 103 report feedback paths, 193
delete MTPI control_point, 106 report gates, 195
delete MTPI observe_point, 108 report instance, 200
delete nofaults, 110 report loops, 203
delete nonscan instances, 113 report mapping definition, 205
delete nonscan models, 115 report nofaults, 208
delete notest points, 117 report nonscan models, 209
delete output masks, 119 report notest points, 210
delete pin constraints, 120 report output masks, 211
delete pin equivalences, 121 report pin constraints, 212
delete primary inputs, 122 report pin equivalences, 214
delete primary outputs, 124 report primary inputs, 215
delete read controls, 126 report primary outputs, 216
delete scan chains, 127 report read controls, 217
delete scan groups, 128 report scan cells, 218
delete scan instances, 129 report scan chains, 220
delete scan models, 131 report scan groups, 222
delete scan pins, 132 report scan models, 223
delete test points, 134 report scan pins, 224
delete tied signals, 136 report sequential instances, 225
delete write controls, 138 report statistics, 230

754 LBISTArchitect Reference Manual, v2017.3

September 2017
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

report test logic, 233 verify scan, 341

report test points, 235 write BIST setup, 343
report testability analysis, 237 write formal_verification setup, 345
report tied signals, 240 write loops, 347
report timeplate, 241 write netlist, 348
Report Variables, 242 write primary inputs, 349
report write controls, 244 write primary outputs, 350
reset state, 245 write procfile, 351
restore test_points, 246 write scan identification, 352
ripup scan chains, 248 write scan order, 354
run, 250 write scan setup, 356
save history, 251 write static_timing setup, 358
set BIST enables, 255 write subchain setup, 360
set clock period, 256
set dofile abort, 258 —E—
set drc handling, 259 Environment variables
set file compression, 262 EDITOR, 149
set gzip options, 267 HISTFILE, 149
set identification model, 269 HISTSIZE, 149
set internal fault, 271 MGCDFT_STARTUP, 85
set io insertion, 272 VISUAL, 149
set latch handling, 274 —F—
set lockup latch, 275 Fault simulation commands
set logfile handling, 278 add bist capture, 509
set loop duplication, 280 add chain masks, 510
set net resolution, 282 add clocks, 512
set nonscan handling, 283 add faults, 514
set screen display, 293 add LFSR connections, 517
set sensitization checking, 294 add LFSR taps, 519
set system mode, 295 add LFSRs, 520
set test logic, 296 add MTPI controller, 522
setup naming, 301 add MTPI output, 523
setup output masks, 303 add nofaults, 525
setup partition scan, 305 add notest points, 528
setup pin constraints, 306 add output masks, 529
setup registered io, 308 add pin constraints, 530
setup scan identification, 311 add pin equivalences, 532
setup scan insertion, 313 add primary inputs, 533
setup scan pins, 317 add primary outputs, 535
setup test_point identification, 319 add processors, 536
setup test_point insertion, 323 add scan chains, 540
setup tied signals, 329 add scan groups, 542
setup x_bounding, 335 add tied signals, 543
synthesize, 339 analyze control signals, 547
system, 340 b, 616

LBISTArchitect Reference Manual, v2017.3 755

September 2017
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

delete clocks, 551 report primary outputs, 641

delete faults, 552 report scan cells, 645
delete LFSR connections, 556 report scan chains, 648
delete LFSR taps, 557 report scan groups, 649
delete LFSRs, 558 report statistics, 650
delete MTPI controller, 559 report tied signals, 653
delete MTPI output, 560 report variables, 654
delete nofaults, 561 report version data, 656
delete notest points, 564 reset di faults, 657
delete output masks, 565 run, 660
delete pin constraints, 566 save flattened model, 661
delete pin equivalences, 567 save history, 662
delete primary inputs, 568 save patterns, 663
delete primary outputs, 570 set bist chain_test, 671
delete processors, 572 set BIST debug, 673
delete scan chains, 574 set BIST trace, 676
delete scan groups, 575 set capture clock, 678
delete tied signals, 576 set contention check, 679
dofile, 578 set dofile abort, 685
exit, 579 set drc handling, 686
f, 617 set fault mode, 690
find design names, 580 set file compression, 695
flatten model, 585 set gate level, 697
help, 586 set gate report, 698
history, 587 set gzip options, 705
identify redundant faults, 589 set internal fault, 707
load faults, 590 set logfile handling, 708
report bist capture, 594 set pattern source, 714
report clocks, 596 set possible credit, 717
report drc rules, 597 set random patterns, 718
report environment, 602 set screen display, 719
report failures, 604 set split capture_cycle, 720
report faults, 607 set system mode, 721
report feedback paths, 612 setup LFSRs, 723
report gates, 614 setup pin constraints, 725
report LFSR connections, 628 setup tied signals, 727
report LFSRs, 433, 629 system, 728
report loops, 630 update implication detections, 729
report MTPI controller, 632 write faults, 730
report nofaults, 633
report notest points, 635 —I—
report output masks, 636 Invocation, 737
report pin constraints, 637 —R—
report pin equivalences, 638 Report gates format, 195
report primary inputs, 639

756 LBISTArchitect Reference Manual, v2017.3

September 2017
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

—T—
TIE0, scannable, 47
TIE1, scannable, 47

LBISTArchitect Reference Manual, v2017.3 757

September 2017
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

758 LBISTArchitect Reference Manual, v2017.3

September 2017
 Third-Party Information
For information about third-party software included with this release of Tessent products, refer to the Third-Party Software for
Tessent Products.
 End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula

IMPORTANT INFORMATION

USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.

END-USER LICENSE AGREEMENT (“Agreement”)

This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties’ entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.

1. ORDERS, FEES AND PAYMENT.

1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any
additional or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order
management system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and
physically signed by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month
or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes
or other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a
valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all
applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all
payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by
Customer hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or
make payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event
of default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision
of both a primary and an alternate e-mail address.

2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation, setup files and design data (“Software”) are copyrighted, trade secret and
confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not
expressly granted by this Agreement. Except for Software that is embeddable (“Embedded Software”), which is licensed pursuant to
separate embedded software terms or an embedded software supplement, Mentor Graphics grants to Customer, subject to payment of
applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form
(except as provided in Subsection 4.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer
may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as
the employee’s residence, an airport or hotel, provided that such employee’s primary place of employment is the site where the
Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid
or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to
execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be
technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including
eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer provides any
feedback or requests any change or enhancement to Products, whether in the course of receiving support or consulting services,
evaluating Products, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made
by Mentor Graphics (at Mentor Graphics’ sole discretion) will be the exclusive property of Mentor Graphics.
3. BETA CODE.
3.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to
test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.
3.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
3.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 3.3 shall survive termination of this Agreement.

4. RESTRICTIONS ON USE.
4.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices
and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall
remain the property of Mentor Graphics or its licensors. Except for Embedded Software that has been embedded in executable
code form in Customer’s product(s), Customer shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Customer acknowledges that Software provided hereunder may contain source code which is proprietary and
its confidentiality is of the highest importance and value to Mentor Graphics. Customer acknowledges that Mentor Graphics
may be seriously harmed if such source code is disclosed in violation of this Agreement. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
disassemble, reverse-compile, or reverse-engineer any Product, or in any way derive any source code from Software that is not
provided to Customer in source code form. Log files, data files, rule files and script files generated by or for the Software
(collectively “Files”), including without limitation files containing Standard Verification Rule Format (“SVRF”) and Tcl
Verification Format (“TVF”) which are Mentor Graphics’ trade secret and proprietary syntaxes for expressing process rules,
constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding
Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as
Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer
may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use
Products or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way
competitive with Products, or disclose to any third party the results of, or information pertaining to, any benchmark.
4.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use, or as permitted for Embedded Software under separate
embedded software terms or an embedded software supplement. Customer shall not disclose or permit disclosure of source
code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or on-site
contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in
any manner except to support this authorized use.
4.3. Customer agrees that it will not subject any Product to any open source software (“OSS”) license that conflicts with this
Agreement or that does not otherwise apply to such Product.
4.4. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written consent and
payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in
interest and assigns.
4.5. The provisions of this Section 4 shall survive the termination of this Agreement.

5. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics’ then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.

6. OPEN SOURCE SOFTWARE. Products may contain OSS or code distributed under a proprietary third party license agreement, to
which additional rights or obligations (“Third Party Terms”) may apply. Please see the applicable Product documentation (including
license files, header files, read-me files or source code) for details. In the event of conflict between the terms of this Agreement
 (including any addenda) and the Third Party Terms, the Third Party Terms will control solely with respect to the OSS or third party
code. The provisions of this Section 6 shall survive the termination of this Agreement.

7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed,
will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not
warrant that Products will meet Customer’s requirements or that operation of Products will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must
notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty
applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a)
Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty
shall not be valid if Products have been subject to misuse, unauthorized modification, improper installation or Customer is not
in compliance with this Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE
REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON
RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE
PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF
WHICH ARE PROVIDED “AS IS.”
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.

8. LIMITATION OF LIABILITY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS
AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS
LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8
SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.

9. THIRD PARTY CLAIMS.

9.1. Customer acknowledges that Mentor Graphics has no control over the testing of Customer’s products, or the specific
applications and use of Products. Mentor Graphics and its licensors shall not be liable for any claim or demand made against
Customer by any third party, except to the extent such claim is covered under Section 10.
9.2. In the event that a third party makes a claim against Mentor Graphics arising out of the use of Customer’s products, Mentor
Graphics will give Customer prompt notice of such claim. At Customer’s option and expense, Customer may take sole control
of the defense and any settlement of such claim. Customer WILL reimburse and hold harmless Mentor Graphics for any
LIABILITY, damages, settlement amounts, costs and expenses, including reasonable attorney’s fees, incurred by or awarded
against Mentor Graphics or its licensors in connection with such claims.
9.3. The provisions of this Section 9 shall survive any expiration or termination of this Agreement.

10. INFRINGEMENT.
10.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired
by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics
will pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and
agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics
promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the
action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.
10.2. If a claim is made under Subsection 10.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
10.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of
other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that
Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; (h) OSS, except to the extent that
the infringement is directly caused by Mentor Graphics’ modifications to such OSS; or (i) infringement by Customer that is
deemed willful. In the case of (i), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.
10.4. THIS SECTION 10 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
11. TERMINATION AND EFFECT OF TERMINATION.
11.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon
written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement
or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped or licenses granted prior to
the termination, which amounts shall be payable immediately upon the date of termination.
11.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination of this Agreement and/or any license granted under this Agreement, Customer shall ensure that
all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in
Customer’s possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business
days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form.

12. EXPORT. The Products provided hereunder are subject to regulation by local laws and European Union (“E.U.”) and United States
(“U.S.”) government agencies, which prohibit export, re-export or diversion of certain products, information about the products, and
direct or indirect products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products
in any manner without first obtaining all necessary approval from appropriate local, E.U. and U.S. government agencies. If Customer
wishes to disclose any information to Mentor Graphics that is subject to any E.U., U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export Administration
Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure, that such information
is subject to such export restrictions.

13. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.

14. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.

15. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 15 shall survive the termination of this Agreement.

16. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America or Japan, and the laws of Japan if Customer is located in Japan. All disputes arising out of or in relation to this
Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin,
Ireland when the laws of Ireland apply, or the Tokyo District Court when the laws of Japan apply. Notwithstanding the foregoing, all
disputes in Asia (excluding Japan) arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a
single arbitrator to be appointed by the chairman of the Singapore International Arbitration Centre (“SIAC”) to be conducted in the
English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to
be incorporated by reference in this section. Nothing in this section shall restrict Mentor Graphics’ right to bring an action (including
for example a motion for injunctive relief) against Customer in the jurisdiction where Customer’s place of business is located. The
United Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.

17. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.

18. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Any translation of this Agreement is provided to comply with local legal requirements only. In the
event of a dispute between the English and any non-English versions, the English version of this Agreement shall govern to the extent
not prohibited by local law in the applicable jurisdiction. This Agreement may only be modified in writing, signed by an authorized
representative of each party. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver
or excuse.
Rev. 170330, Part No. 270941