ETVerifyReference PDF

ETVerify Tool Reference
Software Version 2017.3

September 2017
© 2009-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
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Manual Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Character Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Command Line and Property Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
BitsValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Bus Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Special Characters in File Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 2
Summary of ETVerify Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ETVerify Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
.etv_startup File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ETVerify Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Tessent MemoryBIST Algorithm File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
.controller StepAlgo Selection File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
LV_WORKDIR Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
.gtool_info Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
.tcm File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Optional Physical Constraints File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BSDL/HSDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BSDL-Only Flow Third-Party Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 3
ETVerify Startup File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ETVerify Startup File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ClockPeriods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapter 4
ETVerify Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ETVerify Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Description of Configuration File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Global Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Tester-Related Data Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
User-Defined Sequence Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Specific Verification Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Sample Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
ETVerify Tool Reference, v2017.3 3

September 2017
Table of Contents
Global Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Tester-Related Data Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
User-Defined Sequence Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Summary of Specific Verification Sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Custom Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Logic BIST Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Memory BIST Verification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Scan Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
TAP Verification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
WTAP Verification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
SerdesTest Verification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
CPU Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
FastScan Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 5
Physical Constraints File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Optional Input for TAP Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
PhysicalConstraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
EnableGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
EnableCell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
PortPolarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 6
Tessent MemoryBIST Algorithm File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Tessent MemoryBIST Algorithm File Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
MemBistAlgorithmList. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Chapter 7
.controllerStepAlgoSelection File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
.controllerStepAlgoSelection File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
ControllerStepAlgoSelection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ETMemoryController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Chapter 8
Loadboard Information File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
.loadboardInfo File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
ACLoopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
ContactedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
DCLoopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Dot6TTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
LoadBoardInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4 ETVerify Tool Reference, v2017.3

September 2017
Table of Contents
Chapter 9
svf2cpu Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
The svf2cpu Translator Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Files’ Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Chapter 10
ETVerify Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
ETVerify Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
-allowSOEDiagWithDifferentDefaultAlgos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
-cdp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
-configFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
-controlInputOnlyPins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
-controllerStepAlgoSelectionFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
-createLVDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
-etaInfoFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
-etPlannerInfoDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
-exclude. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
-extractLVDBSubset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
-faultSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
-faultSimTrialNumber. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
-finalLvdbDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
-genConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
-genETAConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
-genManufacturingConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
-genParallelLoadConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
-genPinMapFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
-genUserDefinedSequenceInfoFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
-inputLVDBName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
-lbistVectorDump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
-membistAlgoFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
-outDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
-outputLVDBName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
-packageDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
-patternType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
-preLayoutFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
-reportSimProgress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
-select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
-serverExtraArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
-startupFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
-stil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
-svf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
-svfDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
-testLowerLevelControllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
-tcmFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
-topHDLConfig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
-tstl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
-userDefinedSequenceDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

September 2017
Table of Contents
-userScanModelDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
-useSVInterfacePortsFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
-verificationFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
-verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
-vif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
-wgl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Chapter 11
ETVerify Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
ETVerify Output Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Appendix A
Reference ETVerify Configuration File Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Reference for ETVerify Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
ActiveControlCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
AddressGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
AddressRegister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
AlgorithmPhase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
AlgorithmSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ApplyTCKClockCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
AsyncSetResetTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
AutonomousOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
BasePeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
BisrChainRotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
BisrChainSelect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
BisrFlushTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
BisrLoadAndRotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
BistEn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
BondingOption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
BsdlFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
BurstClockController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
BurstCyclesWithShiftClock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
BypassOpCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
CaptureBisrChain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
CaptureMeasurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
CellCompares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
CellSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
ChainBypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
ChannelSelect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
CheckRepairNeeded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
CheckRepairStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
ClockInput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
ClockPeriod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
ClockPeriods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
ClockPeriodsDividers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
ClockSourceOverride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Collar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
CompareCmpStat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

September 2017
Table of Contents
CompareDiagDataToZero. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
CompareGo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
CompareGoID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
CompareHardCodedSignature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
CompareMISR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
ComparisonToLimits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CompareStrobeCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
CompStatIDSelect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
ContactedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
CPUActionsFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
CPUReadWriteSetupTasksFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
CPUVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
CustomVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
DataBitNo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
DataCompareTimeSlots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
DataGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
DebugMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
DefineClock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
DesignPin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
DeviceId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
DisableCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
DisableClocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
DisableMemoryList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
DRStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
DUTLoopBacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
EffectiveSlowedDownFrequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
EnableBiraCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
EndVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
ETACompareCmpStat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
ETATestGroupName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
ExpectedROMSignature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
ExpectedStrobeCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
ExternalPullUps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
ExtractRepairFuseMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
FailureLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
FastScanVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
FlattenLoops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
FlushTest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
ForceBidir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
ForceDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
ForceVoltage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
FreezeStep. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
FreezeStepNumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
FreezeTestPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
FreezeTestPortNumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
FreqRatioRelToSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

September 2017
Table of Contents
FuseBoxAccessOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
FuseBoxReadAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
FuseBoxReadAddressMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
FuseBoxReadAddressMin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
FuseBoxWriteAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
FuseBoxWriteDuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
GlobalPadDecayTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
HardCodedAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
IgnoredVectorNum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
IncludeAllNonPowerPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
IncludeAllPowerPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
IncludeTapInit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
IncrementFailureLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
InhibitFuseBoxProgramming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
InitialWaitCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
InhibitTapAsyncReset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
InjectErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
InternalCellSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
InvertDataWithColumnBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
InvertDataWithRowBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
IRStatus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
JtagVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
JTAPAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
LeakageNCOptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
LeakageNumberOfCycles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
LeakageLogicLevel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
LoadBankAddress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
LoadBoardInfoFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
LoadBoardInfoFileForPinMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
LoadColumnAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
LoadCounterA_EndCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
LoadCounterA_StartCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
LoadExpectData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
LoadRowAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
LoadWriteData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
LockTimePause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
LogicbistVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
LogicLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
LoopbackDurationInWordClockCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
LowerELTIscanInitCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
LowerLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
LVBScanFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
MaskedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
MaxLoopCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
MaxRepairCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
MeasurementEdge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
MeasurementLimits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
MemBistController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
MembistPVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

September 2017
Table of Contents
MembistVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
MemoryReset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
MISRCompares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
MonitorClocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
NoCheckerBoard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
NumberOfCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
OperationSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
PadDecayTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
ParallelLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
ParallelRetentionGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
ParallelRetentionTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
ParallelRetentionTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
PatternDBFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
PatternName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
PatternSetID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Pause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
PersistentBISTInputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
PhysicalConstraintFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
PhysicalRegion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
PinComments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
PinCompares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
PinInv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
PinSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
PostAmble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
PostTAPUserDefinedSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
PostTestUserDefinedSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
PowerDomainGroupLabels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
PowerLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
PreserveFuseRegisterValues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
PreAmble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
PreTAPUserDefinedSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
PullResistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
ReducedAddressCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
RetentionTime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
RPAChannelEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
RunLength. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
RunMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
RunTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
RunTimeRefreshEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
RunTimeRefreshInterval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
SanityCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
ScanVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
SdfAnnotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
SdfFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
SelectLibraryAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505

September 2017
Table of Contents
SerdesVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
SerdesTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
SetBisrChain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
SetBisrChainExpected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
SetupChainRegister. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
SetupRate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
ShiftClkSelect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
ShiftClockController. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
ShiftClockSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
SignalToMeasure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
SimulationModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
SimulationScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
SimulationTimePrecision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
SimulationTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
SpareElementPriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
SlowedDownBurstCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
StartVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
LogicbistVerify Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
ScanVerify Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
SplitPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
StilVectorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
SurfaceProportion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
SVFFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
SVFName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
TCKPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
TCKRatio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
TestBenchModuleName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
TestClockSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
TestDurationInBeatCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
TestEndRefreshEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
TestEndRefreshInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
TestPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
TestStep. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
TestTimeMultiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
TogglePattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
TPGChannelEnable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
TriStateEnableNCOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
UnderSamplingClkRatio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
UpperLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
UseAsyncClocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
UseChildBisrEmulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
UseDUTLoopBacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
UserBitAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
UserDefinedSequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
UserDRBit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
UserIRBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602

September 2017
Table of Contents
Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
WGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
WTAPSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
WTAPVerify. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Appendix B
User-Defined Sequences and Custom Verification Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Creating User-Defined Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
UserDefinedSequence Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
UDS Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Sequence of Operations Within UDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Testing and Using User-Defined Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
CustomVerify Wrapper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Referencing User-Defined Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Appendix C
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Mentor Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Third-Party Information
End-User License Agreement

September 2017
List of Figures
Figure 3-1. The ETVerify Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 4-1. Structure of the ETVerify Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 4-2. Sample ETVerify Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 4-3. Global Section of the ETVerify Configuration File . . . . . . . . . . . . . . . . . . . . . . 35
Figure 4-4. Tester-Related Data Section of the ETVerify Configuration File . . . . . . . . . . . 35
Figure 4-5. User-Defined Sequence Section within ETVerify Configuration File Structure 37
Figure 4-6. Custom Verification in ETVerify Configuration File Structure . . . . . . . . . . . . . 39
Figure 4-7. Logic BIST Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 4-8. Memory BIST Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 4-9. Scan Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 4-10. TAP Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 4-11. Complete Syntax for the WTAPVerify Wrapper . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 4-12. UserDefinedSequence Wrapper for WTAP Verification . . . . . . . . . . . . . . . . . 53
Figure 4-13. Complete Syntax for the Tessent SerdesTest Verify Wrapper . . . . . . . . . . . . . 54
Figure 4-14. Complete Syntax for the CPUVerify Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 4-15. Complete Syntax for the FastScanVerify Wrapper. . . . . . . . . . . . . . . . . . . . . . 57
Figure 5-1. Syntax for the .jtag_phy File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 6-1. Complete Syntax for Tessent MemoryBIST Algorithm File . . . . . . . . . . . . . . . 69
Figure 7-1. Complete Syntax for the .controllerStepAlgoSelection File. . . . . . . . . . . . . . . . 73
Figure 8-1. Complete Syntax of the .loadboardInfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 9-1. Example Input SVF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 9-2. Example Output CPUActionsFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure A-1. AddressGenerator Wrapper Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Figure A-2. AddressRegister Wrapper Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Figure A-3. UserDefinedSequence Wrapper for WTAP Verification. . . . . . . . . . . . . . . . . . 189
Figure A-4. Example CHIP with DFT Clocking Documented in TCM file . . . . . . . . . . . . . 223
Figure A-5. UserDefinedSequence Used to Reprogram the PLL Multiplication Factor. . . . 225
Figure A-6. Lost Information by designExtract Prior to Dragonfly Version 7.0 . . . . . . . . . 226
Figure A-7. Collar Wrapper in the MembistVerify: TestStep: Controller Wrapper . . . . . . . 228
Figure A-8. Controller Wrapper in the JtagVerify: TestStep Wrapper . . . . . . . . . . . . . . . . . 251
Figure A-9. Controller Wrapper in the LogicbistVerify: TestStep Wrapper. . . . . . . . . . . . . 252
Figure A-10. Controller Wrapper in the MembistVerify: TestStep and
MembistVerify: TestStep Wrappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Figure A-11. Controller Wrapper in the ScanVerify: TestStep Wrapper . . . . . . . . . . . . . . . 253
Figure A-12. Example CPU Actions File Created by ETAssemble . . . . . . . . . . . . . . . . . . . 257
Figure A-13. Content of Example CPUReadWriteTasksFile Created by ETAssemble . . . . 265
Figure A-14. Content of Example CPUReadWriteTasksFile Created by a User . . . . . . . . . 266
Figure A-15. Example CPUVerify Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Figure A-16. Multi-Chip-Module Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Figure A-17. Contents of TOP.sdf_annotate File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

September 2017
List of Figures
Figure A-18. Example etVerify Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

Figure A-19. Sample SerdesVerify Wrapper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Figure A-20. TestStep Wrapper in the UserDefinedSequence Wrapper . . . . . . . . . . . . . . . . 565
Figure A-21. Sample ETVerify Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Figure A-22. Behavioral Code with Hierarchical forces/compares for Child BISR Emulation
582
Figure A-23. UserDefinedSequence Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Figure A-24. Module to Cyclize IO Values during Verilog Simulation . . . . . . . . . . . . . . . . 594
Figure A-25. Data.Stobe File Created by the SignalStrobe Module . . . . . . . . . . . . . . . . . . . 594
Figure A-28. UserDefinedSequence Wrapper (WTAP Verification) . . . . . . . . . . . . . . . . . . 610
Figure B-1. UserDefinedSequence Wrapper within ETVerify Configuration File . . . . . . . . 614
Figure B-2. A Sample TOP.etEarlyVer Configuration File for Creating UDS . . . . . . . . . . . 617
Figure B-3. Custom Verification in the ETVerify Configuration File Structure. . . . . . . . . . 620
Figure B-4. Complete Syntax of the CustomVerify Wrapper . . . . . . . . . . . . . . . . . . . . . . . . 621
Figure B-5. Sample Configuration File (TOP.etEarlyVer) for Verifying UDS . . . . . . . . . . 623
Figure B-6. Sample Configuration File (TOP.etEarlyVer) for Referencing UDS . . . . . . . . 624
Figure B-7. Sample Sign-Off Configuration File (TOP.etSignOff) for Using UDS . . . . . . . 626
Figure B-8. Sample Manufacturing Configuration File (TOP.etManufacturing) Using UDS 627

September 2017
List of Tables
Table 11-1. ETVerify Output Files in Step 3: ETAssemble/Early Verification . . . . . . . . . . 153

Table A-1. ClockPeriods Wrapper Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Table A-2. DR Status Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Table A-3. ForceDisable Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Table A-4. InitialWaitCycle Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Table A-5. IRStatus Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Table A-6. Patterns Generated by the TPG for the 4-, 8-, and 16-bit Serializer Word Size . 427
Table A-7. Patterns Generated by the TPG for the 10- and 20-bit Serializer Word Size . . . 428
Table A-8. The Pause Property Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Table A-9. PinCompares Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Table A-10. PinSettings Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Table A-11. SetupRate Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Table A-12. TCKPeriod Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Table A-13. TCKRatio Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Table A-14. TestClockSource Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Table A-15. TestClockSource Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Table A-16. UserBitAlias Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Table A-17. UserDRBit Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Table A-18. UserIRBit Usage Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Table A-19. Waveform Type vs. Edge1 and Edge2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Table A-20. Waveform Name vs. Waveform Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606

September 2017
Chapter 1
About This Manual
The Mentor Graphics LV Flow provides a complete, automated embedded test solution for
at-speed testing of logic, embedded memories, mixed-signal blocks, and legacy cores at the chip
level.
This manual describes the input files, runtime options, and output files for the ETVerify tool that
you use in the LV Flow.
For the complete list of Mentor Graphics Tessent-specific terms, refer to the Tessent Glossary.
Refer to “Getting Help” for information on support options and related documentation.
This preface covers the following topics:
Manual Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Character Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Command Line and Property Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
BitsValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Bus Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Special Characters in File Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Manual Contents
The ETVerify tool enables you to create test benches to verify the proper operation of the
embedded testers and test the design infrastructure, and then generate and format all
manufacturing test patterns.
The test benches initialize and operate the various test modes of the embedded test structures,
then return test completion values (DONE flags, pass/fail signals) for observation. They are
used as input to simulation tools. The test benches also provide diagnostic information that is
useful for debugging.

September 2017
About This Manual
Syntax Conventions
The ETVerify tool also creates test vectors, logic BIST signatures, and outputs test patterns for
using the embedded test on the manufacturing ATE. Patterns can be output in WGL for chip
testing and SVF for board-level testing.
The manual contents comprise the following chapters and appendices:
• Summary of ETVerify Input Files summarizes the required and optional input files for
the ETVerify tool.
• ETVerify Startup File describes the contents of the ETVerify startup input file.
• ETVerify Configuration File provides the complete syntax of all sections of the
ETVerify configuration file.
• Physical Constraints File describes the Physical Constraints file that is an optional file
for TAP verification.
• Tessent MemoryBIST Algorithm File describes in detail Tessent MemoryBIST
Algorithm file used for soft-coded algorithms.
• .controllerStepAlgoSelection File describes in detail the .controllerStepAlgoSelection
file used for soft-coded algorithms.
• Loadboard Information File provides the complete syntax of the ETVerify loadboard
information file.
• svf2cpu Utility describes the svf2cpu translator—a utility used to translate a pattern
described in SVF format into a CPUActionsFile that can be then referenced within the
CPUVerify wrapper in the ETVerify configuration file
• ETVerify Runtime Options describes the runtime options for the ETVerify tools
including the complete syntax and an alphabetical list of the options.
• ETVerify Output File describes the output files from the ETVerify tool.
• Reference ETVerify Configuration File Syntax describes in detail the wrappers and
properties available for the ETVerify input files in alphabetic order.
Syntax Conventions
Before you begin creating input files or specifying runtime options, familiarize yourself with
the syntax conventions used throughout this manual and the general syntax rules that you must
follow.
This manual uses the following conventions when describing the syntax for input files and for
runtime options.

September 2017
About This Manual
Syntax Conventions
Symbols
Symbols used throughout this manual include the following.
• Angle brackets, < >

Angle brackets denote user-defined identifiers which must follow the syntax rules listed
for identifiers.
• Colons, :
Colons separate properties from their values, and associate right and left indexes. You
must include them in your input files as shown.
• Curly braces, { }
Curly braces identify the start and finish of a wrapper. You must include them in your
input files as shown.
• Parentheses, ( )
Parentheses identify the default value for either a command line option or for an input
file property.
• Bold Parentheses, ( )
Bold parentheses identify literal parentheses. You must include parentheses when
specifying an input file property.
• Semicolons, ;
Semicolons identify the end of an input file property. You must include them in your
input files as shown.
• Square brackets, [ ]
Square brackets denote a 1-of-n choice among values for properties, runtime options,
and wrappers.
• Vertical bars, |
Vertical bars separate a list of valid values, valid options, or arguments from which you
must choose one.
Character Formatting
Character formatting throughout this manual includes the following.
• Bold
In syntax summaries, bold identifies elements of the user interface (menus, buttons, and
field labels). In syntax descriptions, bold identifies syntax that you must type as shown.

September 2017
About This Manual
Syntax Rules
• Bold-Italics
In syntax summaries, bold-italics identify literal valid values for executables, properties,
runtime options, and wrappers. In syntax descriptions, bold-italics identify syntax that
you must type as shown.
• Italics
Italics identify runtime option or input file property values, filenames, and directory
names.
• Overlining
Overlining identifies inverted bits.
• Underlining
Underlining identifies default valid values or default valid options in syntax
descriptions.
Command Line and Property Options

Generally, the documentation uses the following conventions for binary choice options:
• Command-Line Options — On / Off. For example:
-genPinTemplate On / (Off)
• Properties — Yes / No. For example:

GateDedicatedIsolationClockInFuncMode: (Yes) | No;
These value pairs are synonymous, regardless of whether the pair is used with a command-line
option or a property. In other words, the tool accepts either.
Syntax Rules
When creating input files and/or specifying runtime options, adhere to the following syntax
rules.
BitsValue
When specifying BitsValue, you need to use one of the following formats:
x’bvalue | x’hvalue
Format
where

September 2017
About This Manual
Syntax Rules
• x — is an integer that identifies the number of bits in value.

• ‘b, ‘h — are literals that identify whether value is in binary or in hex format,
respectively.
• value — is a string of literal bit values.
If there are fewer bits in value than specified by x, Mentor Graphics tools pad the left bits with
logic 0s.
Caution
Do not specify a value of 1 outside the range specified by x. If you do, Mentor Graphics
tools generate an error.
Examples
The examples below show sample syntax.
• This first sample syntax corresponds to 1.

1’b1
• The syntax below corresponds to 1010 or hex A.

4’b1010
• Finally, the following syntax corresponds to 0101111.

7’h2F
Bus Ranges
When specifying closed bus ranges, use the following format:
[LeftIndex:RightIndex]
where the preceding variables represent the following:
• LeftIndex must be an integer that corresponds to the most significant bit (MSB).
• RightIndex must be an integer that corresponds to the least significant bit (LSB).
The values for LeftIndex and RightIndex must match the HDL for the specified boundary scan
cell or pad.
Comments
When specifying input files, you can include descriptive comments.

September 2017
About This Manual
Syntax Rules
• For all files except those with VHDL code, use the prefix // to append comments to the
end of a line; for example,
//This is a comment.
• For comments that span multiple lines, begin the comment block with the prefix /* and
end the comment block with the suffix */. An example using both the prefix and suffix
symbols appears below.
/*The arrangement of Steps, Comparators, and MISRs depends upon the
memories in your design. This arrangement illustrates a possible
configuration of three SRAMs. Unless stated otherwise, the argument
RAMInstName identifies the different SRAMs.*/
All input files support this syntax.

• For files with VHDL code, use the prefix -- to append comments to the end of a line; for
example,
--This is a comment.
Identifiers
When specifying identifiers, adhere to the following general rules unless stated otherwise:
• All identifiers must begin with a letter.

• Identifiers can include letters, digits, underscores (_), pound signs (#), percent signs (%),
and periods (.).
For specifying the names of ports in the port sections of library files, the following rules also
apply:
• Identifiers must be valid in the target language, either Verilog or VHDL, as specified by
the runtime option -language.
Note
You must terminate escaped port names with a space before the closing parenthesis of the
port name.
• Identifiers can be escaped names when the target language is Verilog (-language is set
to Verilog). An escaped name starts with a backslash and contains all characters of any
type up to the first white space. For example, \$%%^@ddf_)=+|~[] is an escaped name.
The following sample text illustrates the use of identifiers:
Port (\lalala) {...

/*NOT ACCEPTABLE. The closing parenthesis is part of the escaped name.*/
Port (\lalala) {... //ACCEPTABLE.
Port (\lalala[4:0])

September 2017
About This Manual
Syntax Rules
/*NOT ACCEPTABLE. The bus range is part of the escaped name. The tool
interprets this as a single bit port. Also, this is not a valid VHDL or
Verilog identifier.*/
Special Characters in File Names

If a property specifies a file name that includes special characters (anything that is not
alphanumeric, “.” or “/”), you must enclose the file name with double quotation marks. For
example:
• GlobalDefinitionFile: abc;
• GlobalDefinitionFile: ./abc;
• GlobalDefinitionFile: ../abc/123;
• GlobalDefinitionFile: “abc 123”;
• GlobalDefinitionFile: “abc@123”;

September 2017
About This Manual
Syntax Rules

September 2017
Chapter 2
Summary of ETVerify Input Files
This chapter summarizes the required and optional input files for the ETVerify tool. The chapter
topics are as follows:
ETVerify Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

.etv_startup File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ETVerify Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Tessent MemoryBIST Algorithm File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
.controller StepAlgo Selection File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
LV_WORKDIR Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
.gtool_info Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
.tcm File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Optional Physical Constraints File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BSDL/HSDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BSDL-Only Flow Third-Party Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ETVerify Input Files

Multiple files serve as input to the ETVerify tool:
• .etv_startup File
• ETVerify Configuration Files
• Tessent MemoryBIST Algorithm File
• .controller StepAlgo Selection File
• LV_WORKDIR Files
• .gtool_info Files
• .tcm File
• Optional Physical Constraints File
The following sections describe these files in more detail.

September 2017
.etv_startup File
The .etv _startup file is used to create a customized set of configuration files. This file is
optional and contains information about all clock pins with their frequencies. This information
can be used to determine the preferred speed for each controller.
For detailed information about .etv _startup file, refer to ETVerify Startup File.
ETVerify Configuration Files

This configuration file is a required input for ETVerify and enables you to customize the
generated test bench and test vectors to run the auxiliary controllers under various test
scenarios.
For detailed information about ETVerify configuration file, refer to ETVerify Configuration
File.
Tessent MemoryBIST Algorithm File

The Tessent MemoryBIST Algorithm file is used for soft-coded algorithms.
For detailed information about ETVerify configuration file, refer to Tessent MemoryBIST
Algorithm File.
For detailed usage information, refer to Using Tessent MemoryBIST Soft-Coded Algorithms in
the Tessent MBIST User’s and Reference Manual.
.controller StepAlgo Selection File

The .controllerStepAlgoSelection file is used for soft-coded algorithms. For detailed
information on the complete syntax of this file, refer to .controllerStepAlgoSelection File.
the Tessent MBIST User’s and Reference Manual.
LV_WORKDIR Files
The ETVerify tool reads intermediate files generated by ruleAnalyze and places these files in
the LV_WORKDIR directory. You should not modify these files.

September 2017
.gtool_info Files
The .gtool _info files describe the design objects created by the Generate tools. If you have used
any of the Mentor Graphics Generate tools to create design hardware for your design, the
Generate tools would have automatically created appropriate .gtool_info files.
.tcm File
The designExtract tool outputs the test connection map (.tcm) file that is used as input to the
ETVerify tool.
The test connection map file provides extracted connectivity information for your block, core,
or chip and its interconnections to the controllers.
Optional Physical Constraints File

For TAP Verification, the optional physical constraints file is used if the PhysicalConstraintFile
property in the JtagVerify wrapper in the configuration file is specified.
For detailed information about the physical constraints file, refer to Physical Constraints File.
BSDL/HSDL Files
The BSDL/HSDL files are generated by ETVerify and describe the boundary and hierarchical
scan structure of Block/ELTCores and CHIPS. ETVerify also process these files to generate test
benches and patterns.
BSDL-Only Flow Third-Party Files

Using the BsdlFile property, you can specify a third-party BSDL file to be handed off to
ETVerify to create a simulation test bench and/or a test pattern based on the information
contained in a specified third-party BSDL file.

September 2017

September 2017
Chapter 3
ETVerify Startup File
This chapter describes the contents of the etVerify startup input file.
Chapter topics follow this sequence:
ETVerify Startup File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ClockPeriods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ETVerify Startup File Syntax

The .etv _startup file is used to create a customized set of configuration files. This file is
optional and contains information about all clock pins with their frequencies. This information
can be used to determine the preferred speed for each controller. Running the ETVerify tool
with -genStartupFile On creates the .etv_startup file template that must be edited before being
used.
Note
The names of the clock ports listed in the .etv_startup file are always case-sensitive.
Figure 3-1 illustrates the complete syntax for the ETVerify startup file.
Figure 3-1. The ETVerify Startup File
etv_startup (<designName>) {
ClockPeriods {
.
. //Repeat for each clock pin
.
}
The next section provides detailed description of the ClockPeriodswrapper.

September 2017
ETVerify Startup File
ClockPeriods
ClockPeriods
The ClockPeriods wrapper includes all default values of one or more system clock pins and
their associated clock periods. It is assumed that each clock pin listed in this wrapper drives at
least one BIST controller.
Syntax
The following syntax specifies this wrapper:
ClockPeriods {
<pinName>: period s | ms | us | (ns) | ps;
.
.
}
where each pinName is a valid name for a system clock pin, and period is a real number.
Note that there is no space between the period and unit. Valid values for specifying the units for
period are as follows:
• s — specifies the clock period time in seconds.
• ms — specifies the clock period time in milliseconds.
• us — specifies the clock period time in microseconds.
• ns — specifies the clock period time in nanoseconds.
• ps — specifies the clock period time in picoseconds.
Default Value
The default unit is ns for nanoseconds.
Usage Conditions
None
Example
This example specifies that a chip uses the clock on pin CKa with period of 10 nanoseconds:
etv_startup (MyDesignA) {
ClockPeriods {
CKa: 10ns;
}
}

September 2017
Chapter 4
ETVerify Configuration File
The ETVerify tool automatically creates configuration files required for verification of your
embedded test. You specify the appropriate input files and runtime options on the command
line. The details of the wrappers and properties are available in alphabetic order in Reference
ETVerify Configuration File Syntax.
ETVerify Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Description of Configuration File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Sample Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Global Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Tester-Related Data Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
User-Defined Sequence Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Summary of Specific Verification Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Custom Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Logic BIST Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Memory BIST Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Scan Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
TAP Verification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
WTAP Verification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
SerdesTest Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
CPU Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
FastScan Verification Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Based on the contents of the configuration files, ETVerify generates a significantly more
comprehensive set of test vectors and test steps needed to verify the proper operation of each
embedded test controller. Additionally, you can instruct the tool to generate test patterns in
WGL, and SVF formats. You also instruct ETVerify to create a design database in Mentor
Graphics proprietary format (LVDB), which can be used to hand off the design to the next level
in the flow or to manufacturing.
Multiple files can serve as input to the ETVerify tool:
• .etv_startup file

September 2017
• .etEarlyVer configuration file

• .etSignOff configuration file
• .etManufacturing file
• .gtool_info files created by the Generate tools
• .tcm file created by designExtract
• Physical constraints file (optional) for TAP and boundary-scan verification
• Tessent MemoryBIST Algorithm file (optional)
• Controller step algorithm selection file (optional) for programmable memory BIST
verification
Figure 4-1 displays the file structure of the ETVerify configuration files. Note that the structure
of the files is divided into several sections.

September 2017
Figure 4-1. Structure of the ETVerify Configuration File
etv (<designName>) {
//Global Section
<Properties and wrappers>
//Tester-Related Data Section
<Properties>
//User-Defined Sequence Section
UserDefinedSequence {
}
//Summary of Specific Verification Sections

CustomVerify {//Custom Verification Section
<Properties>
}
JtagVerify {//TAP Verification Section
<Properties>
}
MembistPVerify {//Memory BIST Verification Section
/(One for each memory controller)
<Properties>
}
MembistVerify {//Memory BIST Verification Section
/(One for each memory controller)
<Properties>
}
ScanVerify {//Scan Verification Section
<Properties>
}
SerdesVerify {//SerdesTest Verification Section (SerdesTest)
<Properties>
}
WTAPVerify {//WTAP Verification Section (One for each WTAP controller)
<Properties>
}
CPUVerify {//CPU Verification Section (One for each CPU)
<Properties>
}
FastScanVerify {//FastScan Verification Section
<Properties>
}
}//End of etv wrapper

September 2017
Description of Configuration File Contents

As mentioned earlier, the ETVerify configuration file is divided into the several sections
defined below.
Global Section
The Global Section contains properties that specify whether power or non-power pins are
included in the generated test benches and test patterns, as well as the JTAPAccess wrapper and
its contents used for multi-chip modules that consist of two or more dies packages as a single
chip.
Tester-Related Data Section

The Tester-Related Data Section explains how ETVerify formats the generated test patterns.
User-Defined Sequence Section

The fourth section, User-Defined Sequence Section, contains syntax which enables you to
customize user-defined sequences.
Specific Verification Sections

The Summary of Specific Verification Sections is the last section in the configuration file and
comprises a subsection for each embedded test capability included in your design. For example,
ETVerify inserts a specific controller wrapper for the following verification sections:
• Custom Verification Section
• Memory BIST Verification Section
• Scan Verification Section
• TAP Verification Section
• WTAP Verification Section
• SerdesTest Verification Section
• CPU Verification Section
• FastScan Verification Section
for each embedded test controller the tool detects in your design, or/and CustomVerify (s) for
stand-alone pattern that can be run on a tester with a pgsl_uds or .svf file.

September 2017
In addition, this section can contain several wrappers for the same controller type. However,
you must assign a unique name to each wrapper because ETVerify creates a test bench or test
vector file for individual wrappers.
Sample Configuration File

Figure 4-2 provides a sample ETVerify configuration file.
Figure 4-2. Sample ETVerify Configuration File
etv (SOC) {
IncludeAllNonPowerPins : Off;
IncludeAllPowerPins: No;
FlattenLoops : None; //All, MultiVector, (None)

MaxLoopCount : 5000;
WGL {
Type : Generic; // (Generic), LSI
}
JtagVerify (1) {
PatternName: tapbistv_1;
TCKPeriod: 100;
PhysicalConstraintFile : SOC.tapbistv_phy;
ActiveControlCells : 100;
ExternalPullUps : Off;
TestStep (Default) {
ETATestGroupName : jtagVerify;
RunTest : TestLogicReset;
RunTest : InstReg;
RunTest : IDReg;
RunTest : BypassReg;
RunTest : BscanReg;
RunTest : Input;
RunTest : Sample;
RunTest : HighZ;
RunTest : Clamp;
RunTest : Output;
}
}
MembistVerify(1) {
PatternName : membistv_1;
TestClockSource : Functional;
ClockPeriod : 20.2;
TckRatio : 16;
ETATestGroupName : membistVerify;
RunMode : HWDefault;
Controller (BP1) { //ETC_CLKA_cntrl
CompareGoID : On;
}

September 2017
Global Section
}
}
LogicbistVerify(1) {
PatternName : logicbistv_1;
ClockPeriod : 20.2ns;
TCKRatio : 16;
UseAyncClocks : Off;
BurstCyclesWithShiftClock : On;
TestStep (SerialLoad_G1) {
ETATestGroupName : logicbistVerify;
RunMode : RunTimeProg;
PowerLevel : FULL;
Controller (BP0) { //ETC_LVISION_LOGICTEST
StartVector : 1;
EndVector : LastDefaultVector;
IgnoredVectorNum : 16;
ShiftClkSelect : SHIFTCLKSRC1/2;
BurstClockController (0) { // Driven by pin CLK1
BurstCyclesWithShiftClock : Off;
}
}
}
}
}
Global Section
This section contains global syntax for ETVerify configuration file that the tool uses when
generating test benches and test patterns. The values of the properties and wrappers in this
section affect all xxxVerify wrappers in the configuration file.
Figure 4-4 illustrates the Global Section of the ETVerify configuration file.

September 2017
Figure 4-3. Global Section of the ETVerify Configuration File
//Global Section
IncludeAllNonPowerPins: On | (Off);
IncludeAllPowerPins: On | (Off);
SimulationTimePrecision: 1s | 10s | 100s | 1ms | 10ms | 100ms
| 1us | 10us | 100us | 1ns | 10ns | 100ns
| 1ps | (10ps) | 100ps | 1fs | 10fs
| 100fs;
SimulationTimeUnit: 1s | 10s | 100s | 1ms | 10ms | 100ms
| 1us | 10us | 100us | 1ns | 10ns | 100ns
| 1ps | 10ps | (100ps) | 1fs | 10fs | 100fs;
JTAPAccess {
PreAmble {
Tap { //Repeatable; one per TAP
BypassOpCode: <binary>;
DeviceId: 32’b<deviceID> | 32’h<deviceID>;
}
}
PostAmble {
}
}
}
SdfFiles {
<sdfFileName>;// Repeatable
}
Waveform (<waveformName>) {
Type: <waveformType>;
Edge1: <0-99>;
Edge2: <1-100>;
}
//End of Global Section
//Specific Verification Sections

The first section of the configuration file contains tester-related data used to control test pattern
formatting. This is typically included only in the .etManufacturing file.
Figure 4-4 illustrates the Tester-Related Data Section of the ETVerify configuration file.
Figure 4-4. Tester-Related Data Section of the ETVerify Configuration File

September 2017
//Global Section
<Properties and wrapper>

FlattenLoops : All | MultiVector | (None);
MaxLoopCount : <int>;
WGL {
Type : (Generic) | LSI;
ForceBidir : “0”, “1”, “X”, “Z”, “-”,
“00”, “10”, “X0”, “Z0”, “-0”,
“01”, “11”, “X1”, “Z1”, “-X”,
“0Z”, “1Z“, “XZ“, “ZZ“, “-Z”,
“0-”, “1-”, “X-”, “Z-”, “--”;
//The default is “OX” when Type is Generic and “OZ” when Type is LSI.
}

The User-Defined Sequence Section of the ETVerify configuration file is used to define custom
initialization sequences.
The User-Defined Sequence Section consists of one or more UserDefinedSequence wrappers
that are used to define custom initialization sequence or stand-alone user-defined sequences for
a third-party test access.
The user-defined sequences are stored in the following files:
• <outDir>/UserDefinedSequences/<UDSID>.pgsl_uds when the ETVerify -
inputLVDBName runtime option is not specified.
• <inputLVDBName>/UserDefinedSequences/<UDSID>.pgsl_uds when the ETVerify -
inputLVDBName runtime option is specified.
The .pgsl_uds files are created during early verification.
Use CustomVerify to test and debug your initialization sequence in a stand-alone manner
defined by the UserDefinedSequence.
Once you have debugged and tested user-defined sequences, then you can either use them as a
self-contained pattern for using third-party test resources or be referenced as an initialization
routine in other xxxVerify wrappers.
See “User-Defined Sequences and Custom Verification Steps” for complete information.
Figure 4-5 illustrates the User-Defined Sequence Section within the structure of the ETVerify
configuration file.

September 2017
Figure 4-5. User-Defined Sequence Section within ETVerify Configuration File

Structure
//Global Section
.
.//Set of properties and wrapper
.
//Tester Related Data Section
.
.//Set of properties
.
UserDefinedSequence{//Repeatable
SVFFile: <svfName>;
TestStep(<testStepID>) {//Repeatable
PinSettings{
<pinName>: 0 | 1| Z;
}//End of PinSettings wrapper
PinCompares{
<pinName>: 0 | 1 | x;
}//End of PinCompares wrapper
WTAPSettings(<moduleName>| DP# | BP#){//Repeatable
BistEn(#): On | Off;
IRStatus (<index>): 1 | 0 | X;
UserIRBit(<n>): On | Off;
UserBitAlias(<aliasName>): <binaryNumber>;
}//End of WTAPSettings wrapper
ApplyTCKClockCycles: <cycles>;
InitialWaitCycles: <wCycles>;
Pause: <pTime> s | (ms) | us | ns | ps;
UserDRBit(<n>): On | (Off);
UserIRBit(<n>): On | (Off);
UserBitAlias(<n>): <binaryNumber>;
DRStatus(<index>): 0 | 1 | x;
}//End of TestStep wrapper
ClockSourceOverride{
PhysicalRegion(<RE>) {//Repeatable
MemBistController(<RE>) {//Repeatable
TestClockSource(<RE>) {//Repeatable
ClockInput: <string>;
Pin: <string>;
PinInv: <string>;
FreqRatioRelToSource: <real>;
}//End of TestClockSource wrapper
}//End of MembBistController wrapper
ClockInput(<RE> | new<portName>) {//Repeatable

Pin: <string>;
PinInv: <string>;
}//End of ClockInput wrapper

September 2017
Summary of Specific Verification Sections
BurstClockController(<pinName>) {//Repeatable
Pin: <string>;
PinInv: <string>;
}//End of BurstClockController wrapper
ShiftClockController {//Repeatable
ShiftClockSource(1 | 2) {//Repeatable
Pin: <string>;
PinInv: <string>;
}//End of ShiftClockSource wrapper
}//End of ShiftClockController wrapper
}//End of PhysicalRegion wrapper

}//End of ClockSourceOverride wrapper
}//End of UserDefinedSequence wrapper

.
.//xxxVerify wrappers
.
} // End of etv wrapper
Summary of Specific Verification Sections

The Specific Verification Section of the ETVerify configuration files is divided into several
controller and test structure specific wrappers, such as:
• Logic BIST Verification Section
• CPU Verification Section
• FastScan Verification Section
There can be more than one wrapper for the same controller type; however, each wrapper must
have a unique name—because each wrapper generates a test bench or test pattern of its own.
The generated configuration file includes wrappers for all types of embedded test controllers
integrated into the design. The syntax used in the configuration file specifies requirements for
go/nogo test.

September 2017
Custom Verification Section

The Custom Verification Section of the ETVerify configuration file is used for the following
purposes:
• To test and debug your initialization sequence defined by the UserDefinedSequence
wrapper
• To create a standalone pattern that can be run on a tester with a .pgsl_uds or .svf file
The Custom Verification Section consists of one or more CustomVerify wrappers.
Figure 4-6 illustrates the Custom Verification Section within the structure of the ETVerify
configuration file.
Figure 4-6. Custom Verification in ETVerify Configuration File Structure
//Global Section
.
. //Set of properties and wrapper
.
.
. //Set of properties
.
}
UserDefinedSequence (<sequenceName>) {//Repeatable
.
. //Set of wrappers and properties
.
}
//Specific Verification Section(s)
//Custom Verification Section

CustomVerify(<name>) {//Repeatable
ClockPeriod: <time>;
DefineClock (P|N): <pinName>;
TCKPeriod: <time>;
ClockPeriods{
.
.
}
MonitorClocks{
<moduleName1>: <instanceName1>;
<hierarchicalPort1>: <period>;
}//End of MonitorClocks wrapper

September 2017
PinSettings{
PinCompares{
<pinName>: 0 | 1 | x;
ETATestGroupName: <testGroupName>;
PatternName: <patternName>;
TestBenchModuleName: <name>;
TCKRatio: 1 | 4 | 8 | 16 | 32 | 64 | 128;
PreTAPUserDefinedSequence: <sequenceName>;
PostTAPUserDefinedSequence: <sequenceName>;
PostTestUserDefinedSequence: <sequenceName>;
IncludeTapInit: (Yes)| No;
UseAsyncClocks: On | (Off);
SimulationScript: <string>;
BisrFlushTest: On | (Off);
FlattenLoops: All | MuliVector | (None);
SdfAnnotate: On | (Off);
UseDUTLoopBacks: On | (Off);
DUTLoopBacks{
<inputPinName> <= <outputPinName>;
.
. //Repeat for each loopback signal
.
}
ForceDisable: (On) | Off;
TestClockSource: (TCK) | System | System_2 | System_4 | SystemPLL |
SystemPLL_2 | SystemPLL_4;
SVFName: <svfName>;
UseChildBisrEmulation: On | (Off);
WTAPSettings (<moduleName>| DP# | BP#) {// Repeatable
UserIRBit (<n>): On | Off;
UserBitAlias (<AliasName>): <binaryNumber>;
}
Edge1: <0-99>;
Edge2: <1-100>;
}
}//End of CustomVerify wrapper
.
. //Other xxxVerify wrappers
.
} // End of xxxVerify wrapper(s)

September 2017
Logic BIST Verification Section

The Logic BIST Verification Section is used for verification of the logic BIST controllers in
your design. This section consists of LogicbistVerify wrapper and properties and wrappers
within this wrapper. The ETVerify tool creates a separate LogicbistVerify wrapper for each
logicBIST controller.
The LogicbistVerify wrapper is one of the wrappers of the Specific Verification Section in the
configuration file. This wrapper enables you to tailor the generated test bench to run either the
chip-level logic BIST controller or an auxiliary logic BIST controller within an ELTCore. For
each controller you can specify a separate wrapper.
This section describes the syntax and available wrappers and properties for LogicbistVerify.
This wrapper introduces wrappers and properties for setting pin values, DUT loopbacks, pauses,
userDR and userIR bits, and test steps, to name a few.
Figure 4-7 presents the complete syntax for the Logic BIST Verification Section.
Figure 4-7. Logic BIST Verification Section
LogicbistVerify (<designName>) {
BurstCyclesWithShiftClock: Yes | (No);
EffectiveSlowedDownFrequency: 1/2 | 1/3 | 1/4 | 1/8;
SlowedDownBurstCycles: (0) | 1 | 2 | 3;
TCKPeriod: <time>;
ShiftClkSelect: (TCK) | shiftClkSrc1 |
shiftClkSrc1/2 | shiftClkSrc1/4 | shiftClkSrc1/8 |
shiftClkSrc1/16 | shiftClkSrc2 |shiftClkSrc2/2 |
shiftClkSrc2/4 | shiftClkSrc2/8 |shiftClkSrc2/16;
FlattenLoops: All | MultiVector | (None);
SimulationScript: <string>;
CompareHardCodedSignature: (On) | Off;
LowerELTIscanInitCycles: x;
ParallelLoad: On | (Off);
TCKRatio: 1 | 4 | 8 | 16 | 32 | 64 | 128;
ClockPeriods{
.
.
}
PinSettings{

September 2017
.
. //Repeat for each signal
.
}
DUTLoopBacks{
.
.
}
Pause: pTime s | (ms) | us | ns | ps;
SetupRate: SysClock | (TCK);
UserDRBit(<n>): On | (Off) | X;
UserIRBit(<n>): On | (Off) | X;
TestClockSource: TCK | (System) | System_2 | System_4 | SystemPLL |
SystemPLL_2 | SystemPLL_4 | Test; // Used only for pre-existing
//cores created prior to Version 5.0
UserBitAlias (<aliasName>): <binaryNumber>;
DisableClocks: On | (Off);
}
Edge1: <0-99>;
Edge2: <1-100>;
}
TestStep(<testStepId>) {
PinSettings {
}
MISRCompares: <int>; //default = 1
RunMode: HWDefault | (RunTimeProg) | HWDefaultInitTest |
HWDefaultTest | SingleCompressedATPG;
DRStatus (<index>): 0 | 1 | X;
PowerLevel: (Full) | P7_8 | P3_4 | P5_8 | P1_2 | P3_8 |
P1_4 | P1_8;
Diagnostic: On | (Off);

September 2017
Memory BIST Verification Section
CompareHardCodedSignature:(On) | Off;
LowerELTIscanInitCycles: x;

}
Controller (<ctrlName> | BPx | DPx | BPx.WBPy | DPx.WBPy) {
StartVector:<int>; // default = 1
EndVector:<int>; // default = all
IgnoredVectorNum: <x>;
SetupChainRegister: <registerName>;
shiftClkSrc1/16 | shiftClkSrc2 | shiftClkSrc2/2 |
shiftClkSrc2/4 | shiftClkSrc2/8 | shiftClkSrc2/16;
DisableCapture: On | (Off);
PatternSetID: <string>;
ChainBypass: <chainList>;
BurstClockController{
}
. // Repeat for N burst clock controllers
.
.
}
. /*Repeat for all controllers to be run in the same test step
. Normally, only one logic BIST controller is run but multiple
. embedded controllers could be run at the same time.*/
}
.
. //Repeat for all TestSteps.
.
}//End of LogicbistVerify wrapper

The Memory BIST Verification is used for verification of the memory BIST controllers in your
design.
Use the MembistVerify wrapper to verify your NonProgrammable controllers. Use the
MembistPVerify wrapper to verify your Programmable controllers.
Figure 4-8 summarizes the complete syntax of the MembistVerify and MembistPVerify
wrappers in the ETVerify configuration file. Properties that can only be specified within the
MembistPVerify wrapper are commented.

September 2017
Figure 4-8. Memory BIST Verification Section
MembistVerify(<designName>){
or
MembistPVerify(<designName>) {
AlgorithmSummary: On | (Off); // Only for MembistPVerify

CompareDiagDataToZero: On | (Off);
InhibitTapAsyncReset: On | (Off);
SimulationScript: <fileName>;
TCKPeriod: <time>;
TCKRatio: 1 | 4 | 8 | 16 | 32 | 64 | 128;
TestClockSource:(Functional) | TCK | System | System_2 | System_4 |
SystemPLL | SystemPLL_2 | SystemPLL_4| Test;
UserDRBit(n): On | (Off);
UserIRBit(n): On | (Off);
ClockPeriods{
<pinName>: <period>[s | ms | us | (ns) | ps];
.
}
DUTLoopBacks{
.
}
PinSettings{
}
}
Edge1: <0-99>;
Edge2: <1-100>;
}

September 2017
TestStep(<testStepId>){
CheckRepairNeeded: On | (Off);
DRStatus(<index>): 0 | 1 | X;
ForceVoltage (<pinName>): <Float Value>;
// Only for MembistPVerify
IncrementFailureLimit: On | (Off); //Only for MembistPVerify
InitialWaitCycles:<wCycles>;
IRStatus(<index>): 0 | 1 | X;
ParallelRetentionTest: On | (Off);
ParallelRetentionTime: <rTime>[s | (ms) | us | ns | ps];
RunMode: (HWDefault) | RunTimeProg | Autonomous |
BisrChainAccess | FuseBoxAccess;
SplitPattern: On | (Off);
BisrLoadAndRotate: On | (Off);
PinCompares{
<pinName>: 0 | 1 | X;
}
PinSettings{
}
}
Controller (<moduleName> | BPx | DPx | BPx.WBPy | DPx.WBPy) {
AddressGenerator { // Only for MembistPVerify
AddressRegister (A|B) { //Repeatable
LoadBankAddress: <BitsValue>;
LoadColumnAddress: <BitsValue>;
LoadRowAddress: <BitsValue>;
} //End of AddressRegister wrapper
} //End of AddressGenerator wrapper
AlgorithmPhase: StartToPause | PauseToPause | PauseToEnd |
(AllPhases);
AutonomousOperation: (PowerUpEmulation) | VerifyFuseBox |
SelfFuseBoxProgram | ClearBisrChain;
BisrChainRotate: On | (Off);
BisrChainSelect: Internal | (External);
CaptureBisrChain: (On) | Off;
CheckRepairStatus: On | (Off) | NonRepairable;
Collar(<RAMCollarID>){
CompStatIDSelect: <cpidNum>;
}
. //Repeat for all interfaces that
. //have selectable comparator status signals
Collar(<ROMCollarID>){
ExpectedROMSignature: <BitsValue>;
}
.//Repeat for all interfaces associated with ROMs
CompareCmpStat: On | (Off);
CompareStrobeCount: On | (Off); // Only for MembistPVerify
CompareGo: (On) | Off;

September 2017
CompareGoID: On | (Off);
CompareMISR: On | (Off);
DataCompareTimeSlots : (All) | Odd | Even;
DataGenerator { //Only for MembistPVerify
InvertDataWithColumnBit: (None) | c[<x>];
InvertDataWithRowBit: (None) | r[<x>];
LoadExpectData: <BitsValue>;
LoadWriteData: <BitsValue>;
} //End of DataGenerator wrapper
DebugMode: On | (Off); // Only for MembistPVerify
DisableMemoryList: <MemIDList>;// Only for MembistPVerify
EnableBiraCapture: On | (Off);
ETACompareCmpStat: On | (Off);
ExpectedStrobeCount: <int>; // Only for MembistPVerify
ExtractRepairFuseMap: On | (Off);
FailureLimit: <fCount>;
FreezeStep: On | (Off);
FreezeStepNumber: <stepNum>;
FreezeTestPort: On | (Off);
FreezeTestPortNumber: <testPortNum>;
FuseBoxAccessOperation: Program |(Read);
FuseBoxReadAddress(<HexAddress>): 1 | (0)| X;
FuseBoxReadAddressMax: <HexAddress>;
FuseBoxReadAddressMin: <HexAddress>;
FuseBoxWriteAddress(<int>): 1 | 0;
FuseBoxWriteDuration: <Duration>[ms | us | (ns)];
HardCodedAlgorithm: <HardCodedAlgorithmName>;
InhibitFuseBoxProgramming: (Off) | On;
LoadCounterA_EndCount: <integer>; // Only for MembistPVerify
// Only for SoftProgrammable controllers
LoadCounterA_StartCount: <integer>;// Only for MembistPVerify
MaxRepairCount: <int>;
MemoryReset: On | (Off);
OperationSet: <operationSetName>;// Only for MembistPVerify
ParallelRetentionGroup: <groupNum>;
PersistentBISTInputs: Yes | (No);// Only for MembistPVerify
PowerDomainGroupLabels: <listOfLabels>;
PreserveFuseRegisterValues: On | (Off);
ReducedAddressCount: On | (Off);
RunLength: <integer>; // Only for MembistPVerify
RunTimeRefreshEnable: On | (Off);// Only for MembistPVerify
RunTimeRefreshInterval: <time>;// Only for MembistPVerify
SelectLibraryAlgorithm: <algorithmName>;
SetBisrChain(<int>): 1 | (0);
SetBisrChainExpected(<timeSlot>): 1;
SpareElementPriority: (Column) | Row;
TestEndRefreshEnable: On | (Off);// Only for MembistPVerify
TestEndRefreshInterval: <time>;// Only for MembistPVerify
TestTimeMultiplier: <mulNum>;
SdfFiles{
<sdfFileName>;
}

September 2017
Scan Verification Section
}//End of Controller wrapper

.//Repeat for all controllers to be run in the same test step
.//Repeat for all test steps
} //End of MembistVerify or MembistPVerify wrapper

The Scan Verification Section is used for verification of logic circuits by externally
applying/reading scan patterns through the scan chains.
Typical tests run in this section are as follows:
• Logic BIST TopUp ATPG patterns
• Test of flop’s asynchronous set/reset
• Tests of flop’s value retention (retention tests)
• Tests of scan chains (flush tests)
• IDDQ patterns
Figure 4-9 illustrates the complete syntax for the ScanVerify wrapper in the configuration file.
Figure 4-9. Scan Verification Section
ScanVerify(<designName>) {
ClockPeriods{
.
}
TCKRatio: 1 | 4 | 8 | 16 | 32 | 64 | 128;
TCKPeriod: <time>;
DUTLoopBacks{
.
}

September 2017
ForceDisable:(On) | Off;
UserBitAlias(<aliasName>): <binaryName>;
PinSettings{
<pinName>: 0 | 1;
}
WTAPSettings(<moduleName> | DP# | BP#) {// Repeatable
}
Edge1: <0-99>;
Edge2: <1-100>;
}
TestStep(<testStepId>) {
DRStatus (<index>): 0 | 1 | X;
Mode: Single | Multi | Prepare | ControllerChain| EDT | |
EDT_ncapture | Single_ncapture | Multi_ncapture |
Prepare_Iddq | Single_Iddq | Multi_Iddq;
UserBitAlias(<aliasName>): <binaryName>;
FlushTest: On | (Off);
PowerLevel: (Full) | P7_8 | P3_4 | P5_8 | P1_2 | P3_8 | P1_4 | P1_8;
}
LowerELTIscanInitCycles: <cycles>;
PinSettings{
}
StartVector: <value>; // default = 1
EndVector: <value>; // default = 0 (all vectors)
Controller(<ctrlName> | BPx | DPx | BPx.WBPy | DPx.WBPy) {
AsyncSetResetTest: On | (Off);
RetentionTime: <time>;
PatternDBFile: <filename>;

September 2017
TAP Verification Section
SdfFiles {
<sdfFileName>;
}
StilVectorFile: <fileName>;
StartVector: <value>; // default = 1
EndVector: <value>; // default = last vector
BurstClockController (<N>){
}
. // Repeat for N burst clock controllers
.
.
}//End of Controller wrapper
}//End of ScanVerify wrapper

The TAP Verification Section is used for verification of the TAP controller in your design. This
section consists of the JtagVerify wrapper and properties and wrappers within this wrapper. The
ETVerify tool creates a separate JtagVerify wrapper for each TAP.
The ETVerify tool generates a test bench for the IEEE 1149.1-compliant TAP and boundary-
scan chains. The JtagVerify wrapper provides additional flexibility in optimizing simulation
time and test effectiveness. Using syntax in this wrapper, you can select which algorithms need
to be run within the test bench to optimize simulation time and ensure high manufacturing test
coverage.
Figure 4-10 illustrates the complete syntax for the JtagVerify wrapper in the configuration file.

September 2017
Figure 4-10. TAP Verification Section
JtagVerify(<chipDesignName>) {
BsdlFile : <fileName>;
ActiveControlCells: <n>;
TCKPeriod: <time>;
ExternalPullUps: On | (Off);
BondingOption: <BondingOptionName>;
PhysicalConstraintFile: <fileName>;
PinComments: (On) | Off;
UserDRBit(n): On | (Off);
UserIRBit(n): On | (Off);
LVBScanFile: <path to .lvbscan>;
LoadBoardInfoFile: <path to file>;
LoadBoardInfoFileForPinMap: <path to file>;
ContactedPins{
DesignPin{
Control: (None) | TwoStateWeak | TwoStateStrong | ThreeState |
H | L | Z | X;
Observation: (None) | TwoState | ThreeState;
PullResistor: (None) | Up | Down;
}
}
DUTLoopBacks {
.
.
}
PinSettings {
.
. //Repeat for each pin name
.
}
SimulationModel {
GlobalPadDecayTime: <n>(ns) | us | ps;
PadDecayTime{
<pinName>: <n>(ns) | us | ps;
}
}
Edge1: <0-99>;
Edge2: <1-100>;
}

September 2017
TestStep(<testStepId>){// Repeatable
CellCompares {
<cellNumber>: 0 | 1 | X;
}
CellSettings {
<cellNumber>: 0 | 1;
}
InternalCellSettings {
<cellNumber1> | <cellLabel1>: 0 | 1;
[<cellNumberN> | <cellLabelN>: 0 | 1;...]
}
Controller (<ctrlName> | BPx | DPx | BPx.WBPy | DPx.WBPy) {
}
ETATestGroupName: <groupName>;
NoCheckerBoard: On | (Off);
RunTest: BScanReg | BypassReg | Clamp | Controlr | DisabledOutputs |
HighZ | HighzMode | IDReg | IIH | IIL | Input | InstReg |
Output | OutputClamp | Sample | TAPIntDR | TestLogicReset |
VOH | VOL | LeakageNC | TristateEnableNC | None |
Dot6ACInput | Dot6ACOutput | Dot6DCInput | Dot6DCOutput |
Dot6ACSelectCells | Dot6DC00/01/10/11 | Dot6AC00/01/10/11;
// Dot6ACInput, Dot6ACOutput, Dot6DCInput, Dot6DCOutput,
// Dot6ACSelectCells, Dot6DC00/01/10/11, Dot6AC00/01/10/11
// tests are 1149.6 specific
.
. // Repeat RunTest property for each test to run.
. // There is no default.
LeakageNCOptions {
LogicLevel: (Both) | IIH | IIL;
NumberOfCycles: <n>; //Default is 0
}
MaskedPins {
<pinName>: Masked | Normal;
.
.
.
}
PinCompares {
<pinName>: 0 | 1 | X;
}
PinSettings {
.
.
}
TriStateEnableNCOptions {
TestPath: (Both) | Local | Global;
LogicLevel: (Both) | High | Low;
NumberOfCycles: <n>; //Default is 1
}
} // End of TestStep wrapper

September 2017
WTAP Verification Section
.
. //Repeat TestStep wrapper for all test steps.
.
} // End of JtagVerify wrapper
}// End etv wrapper

The following syntax of the ETVerify configuration file is specific for WTAP Verification:
Figure 4-11 summarizes the contents of the WTAPVerify wrapper in the ETVerify
configuration file that are used in verification process of WTAPs in your design.
The UserDefinedSequence wrapper includes a WTAP-specific property that is used for
enabling or disabling of specific controllers—BistEn. Figure 4-12 shows BistEn inside the
UserDefinedSequence wrapper in the ETVerify configuration file.
Figure 4-11. Complete Syntax for the WTAPVerify Wrapper
WTAPVerify (<designName>) {
TCKPeriod: <time>;
DUTLoopBacks{
.
.
}
PinSettings {
.
.
.
}
UserIRBit (<n>): On | (Off);
}

September 2017
Edge1: <0-99>;
Edge2: <1-100>;
}
TestStep (<testStepId>) {// Repeatable
WTAPSettings(<moduleName> | DP# | BP#) { // Repeatable
}
UserBitAlias(<moduleName> | DP# | BP#) {// Not Repeatable
RunTest: TestLogicReset | InstReg | BypassReg | IDReg;
.
.
SdfFiles{
<sdfFileName>;
}
}// End of Controller wrapper
PinSettings {
.
.
}
.
.
} // End of WTAPVerify wrapper
}// End etv wrapper
Figure 4-12. UserDefinedSequence Wrapper for WTAP Verification
UserDefinedSequence(<designName>) {
TestStep (<testStepId>) {// Repeatable
...
WTAPSettings {// Repeatable
IRStatus(<index>): 1 | 0 | X;
}
}
}
}

September 2017
SerdesTest Verification Section

The following syntax of the ETVerify configuration file is specific for Tessent SerdesTest
Verification:
Figure 4-13 summarizes the contents of the SerdesVerify wrapper in the ETVerify
configuration file that are used in verification process of Tessent SerdesTest performed by an
ULTRA controller and its associated hardware in your design.
Figure 4-13. Complete Syntax for the Tessent SerdesTest Verify Wrapper
SerdesVerify(<designName>) {
TCKPeriod: <time>;
PinCompares{
<pinName>: 0 | 1 | X;
}
PinSettings{
}
Edge1: <0-99>;
Edge2: <1-100>;
}
BasePeriod: <time>;
ClockPeriods{
.
.
}
ClockPeriodsDividers{
<clockPinName>: <int>;
}
TCKRatio: 1 | 4 | 8 | 16 | 32| 64 | 128;
PreTAPUserDefinedSequence : <sequenceName>;

September 2017
DUTLoopBacks{
.
.
}
ETATestGroupName: <groupName>;
TestStep(<testStepId>) {// Repeatable
UserDRBit (<n>): On | (Off);
DRStatus: 0 | 1 | x;
IRStatus: 0 | 1 | x;
PinCompares{
<pinName>: 0 | 1 | X;
}
PinSettings{
.
.
}
SerdesTest: AverageSlewRate | AverageVoltage | BasicTests |
DutyCycleDistortion | FunctionalLoopBack |
JitterFromCDF | (Jitter) | LFJitterFromCDF |
MeanSampleInstant | MultiPhaseSamplingError |
OffsetFrequency | TransitionDensityDependentDelay;
SanityCheck: (On) | Off;
InjectErrors: On | (Off);
Pattern: (P1010) | P1100 | PHalfOne | PV60 | PHalfIsoOne |

PHalfWord | PHalfPlusOne | P10J | PRBS | P0101 |
P0011 | PHalfOneC | PHalfIsoOneC | P01J | PRBSC;
Controller(<controllerIdentifier>) {// Repeatable
CaptureMeasurement: On | (Off);
DataBitNo: <int>;
ChannelSelect: <int>;
SignalToMeasure: (Databit) | RecoveredClock |
TransmitterClock;
TPGChannelEnable: <int>;
RPAChannelEnable: <int>;
MeasurementEdge: (Rise) | Fall | RiseFall;
ComparisonToLimits: None | UpperLimit | LowerLimit | (Both);
MeasurementLimits(““ | kHz | ps | %){
LowerLimit: <real>;
UpperLimit: <real>;
}
SdfFiles{
<sdfFileName>;
}

September 2017
CPU Verification Section
TestTimeMultiplier: <x>;
SurfaceProportion: (1/2) | 1/4 | 1/8 | PEAK2PEAK;
LoopbackDurationInWordClockCycles: <int>;
UnderSamplingClkRatio: <int>;
TestDurationInBeatCycles: <int>;
} // End of Controller wrapper
.
.
} // End of SerdesVerify wrapper
}// End etv wrapper
CPU Verification Section

The following syntax of the ETVerify configuration file is specific for CPU Verification:
Figure 4-14 summarizes the contents of the CPUVerify wrapper in the ETVerify configuration
file that are used in verification process of the proper access of the TAP and BIST circuitry
through the TAP CPU interface.
Figure 4-14. Complete Syntax for the CPUVerify Wrapper
CPUVerify(<designName>) {//Repeatable
ClockPeriods{
.
.
}
CPUReadWriteSetupTasksFile: <fileName>;
TestStep(<testStepId>) {// Repeatable
CPUActionsFile: <fileName>;
Variable{
<VariableName>: <binaryValue>;
}
.
.
} // End of CPUVerify wrapper
}// End etv wrapper

September 2017
FastScan Verification Section

The following syntax of the ETVerify configuration file is specific for FastScan Verification:
Figure 4-14 summarizes the contents of the FastScanVerify wrapper in the ETVerify
configuration file that are used to verify Tessent FastScan-generated test benches in the
SoCScan flow.
Figure 4-15. Complete Syntax for the FastScanVerify Wrapper
FastScanVerify(<designName>) { // Repeatable
} // End of FastScanVerify wrapper
} // End etv wrapper

September 2017

September 2017
Chapter 5
Physical Constraints File
This chapter describes the physical constraints file that is an optional file for TAP verification.
This chapter topics are as follows:
Optional Input for TAP Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

PhysicalConstraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
EnableGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
EnableCell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
PortPolarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Optional Input for TAP Verification

The physical constraints file is an optional input file for TAP verification that enables you to
specify groups of active enable cells during an output test, as well as port’s polarity, relative to
other ports, when ETVerify generates a checkerboard input/output pattern. This file gives you
some control over the patterns generated by ETVerify. The ETVerify tool reads the physical
constraints file if the JtagVerify: PhysicalConstraintFile property in the ETVerify
configuration file is specified.
The ETVerify tool generates a starter template for this file with the default filename
<chipDesignName>.jtag_phy. This file contains the PhysicalConstraints, EnableGroup, and
PortPolarity wrappers. For both the filename and the value to the main wrapper
PhysicalConstraints, chipDesignName specifies the following:
• Prefix that ETVerify uses to search your working directory for a .bsdl file generated by
ETAssemble.
• Default prefix for the input test connection map file (.tcm).
• Name of the top-level module or entity in your design.
Figure 5-1 illustrates the syntax for the .jtag_phy file. Subsequent subsections describe this
syntax in detail.

September 2017
Optional Input for TAP Verification
Figure 5-1. Syntax for the .jtag_phy File
PhysicalConstraints(<designName>) {
EnableGroup(<groupName>) {
EnableCell: <integer>;
.
. // Repeat for each enable cell
.
} // End of EnableGroup wrapper
.
. // Repeat wrapper for each group of enable cells
.
PortPolarity {
<portName>: Even | Odd;
.
. // Repeat for input and bidirectional pins
.
} // End of PortPolarity wrapper
} // End of PhysicalConstraints wrapper

September 2017
PhysicalConstraints
PhysicalConstraints
The PhysicalConstraints wrapper is the top-most wrapper in the optional .jtag_phy file.
Syntax
PhysicalConstraints (<designName>) {
where designName is the top-level module name for which you are generating the verification
test bench.
Default Value
The default value to this wrapper is the top-level module name for which you are generating the
verification test bench.
Usage Conditions
The ETVerify tool places a starter template for this file in the output directory.
Example
The following syntax shows a complete .jtag_phy file beginning with the PhysicalConstraints
wrapper. Note that there are two main sections defined by the EnableGroup and PortPolarity
wrappers.
PhysicalConstraints (CYCKLV01_normal) {
EnableGroup (Engroup0) {
EnableCell: 122;
EnableCell: 132;
EnableCell: 134;
EnableCell: 136;
EnableCell: 170;
EnableCell: 172;
EnableCell: 174;
EnableCell: 190;
EnableCell: 192;
EnableCell: 194;
}
PortPolarity {
p_RxOutDisable1: Odd;
p_HostRcvRdy1: Even;
p_RxFifAlmEmpt1: Odd;
p_RcvStatValid1: Even;
p_RxPktValid1: Odd;
p_RcvValid1: Even;
p_TxValid1: Odd;
p_Xmt1Rdy: Even;
p_XmtPausePkt1: Odd;
p_TxFifAlmEmpt1: Even;
}
}

September 2017
PhysicalConstraints
Related Information
EnableGroup PortPolarity
EnableCell

September 2017
EnableGroup
EnableGroup
The EnableGroup wrapper gives you control over which enable cells are activated
simultaneously during an output test. Enable groups are enabled one at a time during the IO
tests. To minimize the length of the test, by default, all enable cells are active simultaneously
during the output test.
Syntax
EnableGroup (<groupName>) {
.
. // Repeat for each enable cell
.
} // End of EnableGroup wrapper
.
. // Repeat wrapper for each group of enable cells
.
where valid values are as follows:

• groupName — is an identifier specifying the name of the enable group.
• integer — is the number of the enable cell defined in the BSDL file.
Default Value
None
Usage Conditions
The following usage conditions apply:
• The physical constraints file does not require that you completely specify the EnableGroup
wrapper. The ETVerify tool applies its default grouping capabilities to enable cells not
appearing within this file. The ETVerify tool writes a complete physical constraints file in
the output directory to document the groupings that the tool applied during execution.
• You repeat the EnableGroup wrapper for each enable group that you want activated during
an output test.
• You repeat the EnableCell property for each enable cell within the specified enable group
that you want simultaneously activated during an output test.
• If the EnableGroup wrapper definition in the physical constraints file is larger than the value
you specify with the ActiveControlCells property in the ETVerify configuration file,
ETVerify generates a new physical constraints file, distributing the enable cells into
recalculated enable groups according to the ActiveControlCells setting. For example, if you
specify ActiveControlCells: 3, and the physical constraints file has one enable group with
four enable cells, all enable groups are removed and recreated with a size of 3.

September 2017
EnableGroup
Example
This example defines active enable cells within two enable groups Engroup0 and Engroup1.
PhysicalConstraints(CYCKLV01_normal) {
EnableCell: 122;
EnableCell: 132;
EnableCell: 134;
EnableCell: 136;
}
EnableCell: 170;
EnableCell: 172;
EnableCell: 174;
EnableCell: 190;
EnableCell: 192;
EnableCell: 194;
}
}
Related Information
PhysicalConstraints EnableCell
ActiveControlCells

September 2017
EnableCell
EnableCell
The EnableCell property specifies active enable cells.
Syntax
The following syntax specifies this property:
where integer is the number of the enable cell defined in the BSDL file.
Default Value
To minimize the length of the test, by default, all enable cells are active during the output test.
Usage Conditions
• The EnableCell property is used in the EnableGroup wrapper.
• You repeat the EnableCell property for each enable cell within the specified enable group
that you want simultaneously activated during an output test.
• You repeat the EnableGroup wrapper for each enable group that you want activated during
an output test.
Example
In this example, 122, 132, 174, and 194 are defined as active enable cells.
PhysicalConstraints (CYCKLV01_normal) {
EnableCell: 122;
EnableCell: 132;
EnableCell: 174;
EnableCell: 194;
}
}
Related Information
PhysicalConstraints EnableGroup

September 2017
PortPolarity
PortPolarity
The PortPolarity wrapper lets you override the default assignments by ETVerify of an input,
output, or bidirectional pin to an even or odd group. This assignment determines the polarity to
which pins are driven during the testing process.
Syntax
PortPolarity {
<portName>: Even | Odd;
.
. // Repeat for input, output, and bidirectional
// pins
.
}

• portName — is an identifier specifying the name of the input, output, or bidirectional pin for
which you want to indicate opposite polarity.
• Even and Odd — define polarity for pins specified with portName.
Default Value
By default, ETVerify extracts the assignment of a pin’s polarity based on the chain order
defined in the BSDL file. Pins controlled by adjacent boundary-scan cells are driven to opposite
values during the test.
Usage Conditions
• Like enable grouping, the assignment of port polarity also influences the patterns that
ETVerify generates.
• The .jtag_phy file does not require that you completely specify the PortPolarity wrapper.
The ETVerify tool applies its default grouping capabilities to ports not appearing within this
file. The ETVerify tool writes a complete physical constraints file in the output directory to
document the groupings that the tool applied during execution.
Example
The port definitions in the boundary-scan register description attribute
attribute BOUNDARY_REGISTER of top: entity is
-- num cell port function safe [ccell disval rslt]
" 9 (BC_4, CLK, clock, X ) ,"&
" 8 (BC_4, ENB, observe_only, X )
,"&
" 7 (BC_2, INP, input, X ) ,"&
" 6 (BC_2, OPT, output3, X , 2, 1, Z
),"&
" 5 (BC_2, INT_CELL, input, X )
,"&

September 2017
PortPolarity
" 4 (LV_INT_FC, *, internal, X )

,"&
" 3 (LV_BC_7, IO, bidir, X , 2, 1, Z
),"&
" 2 (BC_2, *, control, 1 ) ,"&
" 1 (BC_2, OPT1, output2, X )
,"&
" 0 (BC_2, OUT_INT, output2, X )
“;
result in this syntax in the PortPolarity wrapper in the physical constraints file.
PhysicalConstraints (top) {
EnableCell: 2;
}
PortPolarity {
OUT_INT : Odd;
OPT1 : Even;
IO : Odd;
INT_CELL: Even;
OPT : Odd;
INP : Even;
ENB : Odd;
CLK : Even;
}
}
Related Information
PhysicalConstraints

September 2017
PortPolarity

September 2017
Chapter 6
This chapter describes in detail Tessent MemoryBIST Algorithm file used for soft-coded
algorithms.
Tessent MemoryBIST Algorithm File Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
MemBistAlgorithmList. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Tessent MemoryBIST Algorithm File Syntax

The Tessent MemoryBIST Algorithm file is used for soft-coded algorithms. Figure 6-1
illustrates the complete syntax of the Tessent MemoryBIST Algorithm File.
Figure 6-1. Complete Syntax for Tessent MemoryBIST Algorithm File
MemBistAlgorithmList {
Algorithm (<algorithmName>) {
.
. // For complete information on the Algorithm wrapper, refer to
. // the Tessent MemoryBIST User’s and Reference Manual
} // End of Algorithm
.
. // Repeat for all algorithms
.
} // End of MemBistAlgorithmList

September 2017
Algorithm
Algorithm
For complete information on the Algorithm wrapper, refer to the Tessent MemoryBIST User’s
and Reference Manual.
This section below provides detailed information on the usage of the Algorithm wrapper in the
Tessent MemoryBIST Algorithm file used for soft-coded algorithms.
Within the Tessent MemoryBIST Algorithm file, you can program custom test algorithm using
the Algorithm wrapper. Use the SelectLibraryAlgorithm property to select an algorithm from
the Tessent MemoryBIST Algorithm file to be loaded into the SoftProgrammable Tessent
MemoryBIST controller for execution. In addition, you must specify one BIST step to which
the algorithm will be applied.
Syntax
The syntax for this wrapper is as follows:
MemBistAlgorithmList {
Algorithm (<algorithmName>) {
...
}
}
Usage Conditions
This wrapper is used in the MemBistAlgorithmList wrapper of the Tessent MemoryBIST
Algorithm File.
• You can specify one or more Algorithm wrappers in the Tessent MemoryBIST Algorithm
file.
• Use the SelectLibraryAlgorithm property to select a custom algorithm defined in the
Tessent MemoryBIST Algorithm file.
Related Information
MemBistAlgorithmList SelectLibraryAlgorithm
.controllerStepAlgoSelection File Tessent MemoryBIST User’s and Reference
Manual
-membistAlgoFile

September 2017
MemBistAlgorithmList
The MemBistAlgorithmList wrapper includes wrappers and properties that define custom
algorithms to be used with Tessent MemoryBIST SoftProgrammable controllers. Each Tessent
MemoryBIST algorithm is described using the Algorithm wrapper.
Syntax
The complete syntax for this wrapper is shown in Figure 6-1.
Default Value
None
Usage Conditions
This is a top-most wrapper of the Tessent MemoryBIST Algorithm file.
The Tessent MemoryBIST Algorithm file is only applicable to Tessent MemoryBIST
SoftProgrammable controllers.
Related Information
FreezeStep BitSliceWidth in the manual ETPlanner Tool
Reference
FreezeStepNumber NumberOfInstructions in the manual
ETPlanner Tool Reference
MembistPVerify Algorithm wrapper in the Tessent
MemoryBIST User’s and Reference Manual
RunMode

September 2017

September 2017
Chapter 7
.controllerStepAlgoSelection File
This chapter describes in detail the .controllerStepAlgoSelection file used for soft-coded
algorithms. This chapter topics are as follows:
.controllerStepAlgoSelection File Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

ControllerStepAlgoSelection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ETMemoryController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
.controllerStepAlgoSelection File Syntax

The .controllerStepAlgoSelection file is used for soft-coded algorithms. Figure 7-1 illustrates
the complete syntax of the controllerStepAlgoSelection file.
Figure 7-1. Complete Syntax for the .controllerStepAlgoSelection File
ControllerStepAlgoSelection (<designName>) {
ETMemoryController (<bistPortName>) {
Step (<stepNum>) {
Algorithm (<algorithmName>): Yes | (No);
.
. // Repeat for all algorithms
.
} // End of Step
.
. // Repeat for all controller steps
.
} // End of ETMemoryController
.
. // Repeat for all Tessent MemoryBIST SoftProgrammable controller
.
} // End of ControllerStepAlgoSelection
the Tessent MemoryBIST User’s and Reference Manual.
The following sections of this chapter provide detailed information on wrapper and properties
of the .controllerStepAlgoSelection file.

September 2017
ControllerStepAlgoSelection
The ControllerStepAlgoSelection wrapper includes wrappers and properties to select the soft-
coded algorithms to be applied for each step of Tessent MemoryBIST SoftProgrammable
controllers. The algorithm to controller step assignments will be used by ETVerify to create the
.etManufacturing configuration file for manufacturing pattern generation.
Syntax
The complete syntax for this wrapper is shown in Figure 7-1.
Default Value
None
Usage Conditions
This is a top-most wrapper of the .controllerStepAlgoSelection file.
These usage conditions apply:
• The .controllerStepAlgoSelection file is only applicable to Tessent MemoryBIST
• If the .controllerStepAlgoSelection file exists, it will be read by ETVerify to populate the
.etManfacturing file. The resulting .etManufacturing file will contain one pattern per
controller step per soft-coded algorithm.
• If the .controllerStepAlgoSelection file does not exist, ETVerify will generate a template file
with the extension .controllerStepAlgoSelection_tpl. This template file will apply all soft-
coded algorithms defined in the Tessent MemoryBIST Algorithm file to all controller steps.
you need to remove algorithms that are not applicable to a controller step by deleting or
commenting the “<AlgorithmName>: Yes;” lines, or setting the property value to No. Once
the changes are complete, rename the template file extension to
.controllerStepAlgoSelection and regenerate the .etManfacturing file.
Example
This example will create manufacturing patterns to apply algorithms TEST1 and TEST2 to the
controller step 0, and algorithm TEST1 to the controller step 1:
ControllerStepAlgoSelection (TOP) {
ETMemoryController (BP1) {
Step (0) {
Algorithm (TEST1): Yes;
}
Step (1) {
Algorithm (TEST2): No;
}
}
}

September 2017
Related Information
Tessent MemoryBIST Algorithm File -membistAlgoFile
Syntax

September 2017
ETMemoryController
ETMemoryController
The ETMemoryController wrapper specifies an Tessent MemoryBIST SoftProgrammable
controller in the .controllerStepAlgoSelection file.
Syntax
The syntax for this wrapper is:
ETMemoryController (<bistPortNum>) {
...
}
where bistPortNum identifies the controller as specified in the Test Connection Map (.tcm) file.
Default Value
None
Usage Conditions
This property is used in the ControllerStepAlgoSelection wrapper of the
.controllerStepAlgoSelection file.
Related Information
Syntax

September 2017
Step
Step
The Step wrapper specifies a controller step of an Tessent MemoryBIST SoftProgrammable
controller in the .controllerStepAlgoSelection file.
Syntax
The syntax for this wrapper is:
ETMemoryController (<bistPortNum>) {
Step (<stepNum>) {
...
}
}
where stepNum specifies the controller step number for SofProgrammable controller
bistPortNum.
Default Value
None
Usage Conditions
This property is used in the ETMemoryController wrapper of the .controllerStepAlgoSelection
file.
Related Information
Syntax

September 2017
Algorithm
Algorithm
The Algorithm property specifies a soft-coded algorithm to be applied to the current controller
step in the .controllerStepAlgoSelection file.
Syntax
The syntax for this wrapper is as follows:
Step (<stepNum>) {
Algorithm (<algorithmName>): Yes | (No);
...
}
}

• algorithmName — specifies the name of a soft-coded algorithm defined in the Tessent
MemoryBIST Algorithm file.
• Yes — generates manufacturing pattern to apply the algorithm to the current controller step.
• No — does not apply the algorithm to the current controller step.
Default Value
The default value is No.
Usage Conditions
This wrapper is used in the Step wrapper of the .controllerStepAlgoSelection File.
Example
This example will create manufacturing patterns to apply algorithms TEST1 and TEST2 to
controller step 0, and algorithm TEST1 to controller step 1:
ControllerStepAlgoSelection (TOP) {
ETMemoryController (BP1) {
Step (0) {
}
Step (1) {
Algorithm (TEST2): No;
}
}
}
Related Information
Step -membistAlgoFile
Tessent MemoryBIST Algorithm File Algorithm wrapper in the Tessent
Syntax MemoryBIST User’s and Reference Manual

September 2017
Chapter 8
Loadboard Information File
This chapter describes the contents of the ETVerify loadboard information file.
.loadboardInfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
ACLoopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
ContactedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
DCLoopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Dot6TTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
LoadBoardInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
.loadboardInfo File
The loadboard information file specified using the LoadBoardInfoFileForPinMap or
LoadBoardInfoFile properties in the ETVerify configuration file describes the contacted pin
properties and the DUT card configuration. A loadboard information file template, named
<design name>.loadboard_info_tpl, is created during a run of ETVerify using the make target
make_testbench.
Mentor Graphics recommends that you copy the template file prior to editing or modifying it.
Mentor Graphics also recommends that you name the file <design name>.loadboard_info. For
information on the available DUT card configurations, refer to Supported DUT Card
Configurations of Application Note Support for 1149.6 Boundary Scan.
Note that you need an .loadboardInfo file only when:
1. Your tester supports applying a 'Z' pattern state (highZ) to an input-only pin, and you
want to use that capability in your dot6INPUT test pattern. For details, refer to the
section |IEEE 1149.6 Boundary Scan Tests of Application Note Support for 1149.6
Boundary Scan.
2. Your DUT card features loopbacks between output and input JTAG pins.
3. On your DUT card, some of your JTAG pins:
o Have pull-up resistors
o Are tied to a constant value
o Are uncontrollable (input and bidirectional pins) or unobservable (output and
bidirectional pins) by the tester during the IO tests

September 2017
.loadboardInfo File
When no .loadboardInfo file is specified, ETVerify assumes the following:
• All input and bidirectional JTAG pins are controllable.

• The tester cannot disable the drive of an input-only pin.
• All output and bidirectional pins can be observed for states 0, 1, and Z.
Figure 8-1 illustrates the complete syntax for the ETVerify .loadboardInfo file.
Figure 8-1. Complete Syntax of the .loadboardInfo File
LoadBoardInfo (<label>) {
ContactedPins {
<Wrappers and properties>
}
DCLoopbacks {
// to 1149.1: from 1149.1
<inputPin>: <outputPin>;
...
// to 1149.6: from 1149.6
...
}
Dot6TTest: <time>;
ACLoopbacks {
// to 1149.6: from 1149.6
...
}
}
The following sections provide in alphabetic order detailed reference information for all
available syntax of the loadboard information file.

September 2017
ACLoopbacks
ACLoopbacks
The ACLoopBacks wrapper specifies one or more capacitively coupled connection loopbacks
from 1149.6 output pins to 1149.6 input pins on your test load board. Direct loopback
connections are called DCLoopbacks, as opposed to ACLoopbacks, which connect output pins
to input pins through a coupling capacitor.
Syntax
ACLoopbacks {
<inputPin1>: <outputPin1>;
....
<inputPinN>: <outputPinN>;
}
where inputPin and ouptutPin are pins of the device under test.
Default Value
This wrapper can be left absent or empty if your loadboard does not feature such connection.
Usage Conditions
This wrapper is only specified inside the .loadBoardInfo file, under the LoadBoardInfo
wrapper. The IO tests specified in the JtagVerify wrapper of the ETVerify configuration file are
the only ones using the ACLoopbacks information.
ACLoopback connections are only valid between two 1149.6 pins.
Example
The following syntax specifies that your test loadboard has capacitively coupled loopbacks
from output pins AC_A_out and AC_C_out to input pins AC_B_in, and AC_D_in.
LoadboardInfo (myLoadBoard) {
ACLoopbacks {
AC_B_in: AC_A_out;
AC_D_in: AC_C_out;
}
}
Related Information
LoadBoardInfo |IEEE 1149.6 Boundary Scan Tests of
Application Note Support for 1149.6
Boundary Scan.
JtagVerify in the ETVerify configuration file

September 2017
ContactedPins
ContactedPins
The ContactedPins wrapper enables you to specify which design pins are to be contacted to a
tester channel during test pattern execution. You can also specify the properties of each tester
channel.
Syntax
ContactedPins {
DesignPin (<pin name>) {
Control: (None) |TwoStateWeak |TwoStateStrong |
ThreeState | H | L | Z | X;
Observation: (None) |TwoState |ThreeState;
}
}
Default Value
This wrapper can be left absent or empty if your loadboard do not feature such connection.
Usage Conditions
wrapper. THis wrapper can be specified as well within the JtagVerify wrapper of the ETVerify
configuration file.
The following usage conditions apply to this wrapper:
• The ContactedPins wrapper is optional with these conditions:
o The absence of this wrapper indicates that all device pins are to be contacted with all
capabilities. That means that ETVerify assumes that Control is equal to
TwoStateStrong for all input and bidirectional pins, and Observation is equal to
ThreeState for all output and bidirectional pins. No Pullup is assumed.
o No device pins are assumed contacted if the wrapper is defined but empty.
o When ETVerify is executed with the -genConfigFile runtime option, the resulting
configuration file does not contain the ContactedPins wrapper; that is, all pins are
contacted with full capabilities.
• IO tests patterns depend on information provided by the ContactedPins wrapper. For
example, an input pin that is not contacted by a tester channel will not be tested during the
INPUT test. A warning is issued at the time of generating the patterns.
Example
ContactedPins {
DesignPin (E_out) {
PullResistor: Up;
}
}

September 2017
ContactedPins
Related Information
LoadBoardInfo Application Note Support for 1149.6
Boundary Scan
JtagVerify in the ETVerify configuration file

September 2017
DCLoopbacks
DCLoopbacks
The DCLoopBacks wrapper specifies one or more connection loopbacks from output pins to
input pins of the device under test. Direct connections are called DCLoopbacks, as opposed to
ACLoopbacks, which connect output pins to input pins through a coupling capacitor.
Syntax
DCLoopbacks {
....
<inputPinN>: <outputPinN>;
}
where inputPin and ouptutPin are pins of the device under test.
Default Value
This wrapper can be left absent or empty if your loadboard does not feature such connection.
Usage Conditions
This wrapper is only specified inside the .loadboardInfo file, under the LoadBoardInfo wrapper.
The IO tests specified in the JtagVerify wrapper of the ETVerify configuration file are the only
ones using the DCLoopbacks information. All other Mentor Graphics controllers use the
ETVerify configuration file’s DUTLoopBacks wrapper instead.
There are DCloopback connection rules:
• Interconnecting 1149.1 and 1149.6 together is not allowed.
• Connecting .1 outputs to .1 inputs is allowed.
• Connecting .6 outputs to .6 inputs is allowed.
• Inout pins are not allowed in the DCloopbacks wrapper.
Example
The following syntax specifies that your test loadboard has direct-coupled loopbacks from
output pins A_out and C_out to input pins B_in, and D_in.
LoadboardInfo(myLoadBoard) {
DCLoopbacks {
B_in: A_out;
D_in: C_out;
}
}
Related Information
DUTLoopBacks of ETVerify configuration Application Note Support for 1149.6
file Boundary Scan

September 2017
DCLoopbacks
LoadBoardInfo

September 2017
Dot6TTest
Dot6TTest
The Dot6Ttest property specifies the minimum time required by the slowest coupling capacitor
among all AC loopbacks to fully discharge. The value of this property (also referred to as TTest
in the IEEE 1149.6 standard) is used mainly by DC-related tests such as dot6DCInput and
dot6DCOutput. This ensures that DC levels are systematically blocked by all coupling
capacitors and therefore cannot be captured by the test receiver.
Syntax
Dot6Ttest: <time>;
where time is specified in seconds, and represent the minimum time that allows all coupling
capacitors in your ACLoopbacks connections to discharge to under 1% of their original full-
charge voltage.
Default Value
This property is optional if there is no coupling capacitor on the DUT card. When no loadboard
information file is specified, or when the Dot6TTest property is not specified, ETVerify
assumes a Dot6TTest value that equals three times the slowest time constant along all Dot6 pads
that have an on-chip high-pass or low-pass filter as recommended by IEEE 1149.6 standard.
ETVerify does not support AC coupling capacitors on the DUT card, between the tester pins
and chip pins. If no on-chips filter is present, Dot6TTest is made equal to 3 periods of TCK.
ETVerify rule-checks that you specify a non-zero value to Dot6TTest if you also have specified
ACLoopbacks in your .loadboardInfo file.
Usage Conditions
wrapper, and is only used by the Dot6-related JtagVerify IO tests.
Mentor Graphics tools create a DUT card simulation model for which coupling capacitors are
modeled by a two-pin device that passes any input transition directly to its output and sets the
same output back to Z after a Dot6TTest period of time.
Example
The following syntax specifies that the Dot6 IO tests wait for 15.0 nanoseconds in RunTestIdle
state before allowing the input pins AC_B_in and C_D_in to capture the latest updated data on
AC_A_out and AC_C_out, so as to let their ACLoopback coupling capacitor to fully discharge.
Dot6TTest: 15.0e-09;
ACLoopbacks {
AC_B_in: AC_A_out;
AC_D_in: AC_C_out;
}
}

September 2017
Dot6TTest
Related Information
ACLoopbacks Application Note Support for 1149.6
Boundary Scan
LoadBoardInfo

September 2017
LoadBoardInfo
LoadBoardInfo
Description
The LoadBoardInfo wrapper fully describes your test loadboard configuration and your tester
interfaces to your chip pins.
Syntax
The following syntax shows the syntax of the .loadboard_info file.
LoadboardInfo (<label>) {
ContactedPins {
<Wrappers and properties>
}
DCLoopbacks {
// to 1149.1: from 1149.1
...
// to 1149.6: from 1149.6
...
}
Dot6TTest: <time>;
ACLoopbacks {
// to 1149.6: from 1149.6
...
}
}
Default Value
None
Usage Conditions
This wrapper is mandatory inside the .loadboardInfo file.
Note that you need an .loadboardInfo file only when either:
1. Your tester supports applying a 'Z' pattern state (highZ) to an input-only pin, and you
want to use that capability in your dot6INPUT test pattern. For details, refer to Section
Support for IEEE 1149.6 Boundary Scan of Application Note Support for IEEE 1149.6
Boundary Scan.
2. Your DUT card features loopbacks between output and input JTAG pins.
3. On your DUT card, some of your JTAG pins:
o Have pull-up resistors
o Are tied to a constant value
o Are uncontrollable (input and bidirectional pins) or unobservable (output and
bidirectional pins) by the tester during the IO tests

September 2017
LoadBoardInfo
When no .loadboardInfo file is specified, ETVerify assumes the following:

• All input and bidirectional JTAG pins are controllable.
• The tester cannot disable the drive of an input-only pin.
• All output and bidirectional pins can be observed for states 0, 1, and Z.
The <design name>.loadboardInfo file can contain three optional wrappers and one property:
• ContactedPins—This wrapper contains information about the tester channel features of all
contacted pins.
• DCLoopbacks—This wrapper identifies all pins with DC loopbacks.
• ACLoopbacks—This wrapper identifies all pins with AC loopbacks.
• Dot6TTest—This property is required with the presence of an AC loopback.
Example
The following syntax specifies that your test loadboard implements the following:
• Has a pull-up resistor on output pin E_out
• Cannot control input pin F_in
• Has a DC-coupled loopback from output pin B_out to input pin A_in
• Has a loopback through a capacitor from output pin D_out to input pin C_in
• The minimum dot6 TTest time constant is 7.5 nanoseconds.
LoadboardInfo(myLoadBoard) {
ContactedPins {
DesignPin (E_out) {
PullResistor: Up;
}
}
ContactedPins {
DesignPin (F_in) {
Control: X;
}
}
DCLoopbacks {
A_in: B_out;
}
DCLoopbacks {
C_in: D_out;
}
Dot6Ttest: 7.5e-09;
}
Related Information
ACLoopbacks Dot6TTest
ContactedPins Application Note Support for 1149.6
Boundary Scan

September 2017
LoadBoardInfo
DCLoopbacks

September 2017
Chapter 9
svf2cpu Utility
This chapter describes the svf2cpu translator—a utility that you use to translate a pattern
described in SVF format into a CPUActionsFile that you can then reference within the
CPUVerify wrapper in the ETVerify configuration file.
The svf2cpu Translator Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Files’ Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The svf2cpu Translator Overview

The svf2cpu translator is a utility that you use to translate a pattern described in SVF format
into a CPUActionsFile that you can then reference within the CPUVerify wrapper.
The utility is written in Tcl and requires you to have a valid Tcl shell called tclsh in your search
path.
The svf2cpu utility accepts these arguments:
• <CPUDataBusWidht> (Mandatory) — Integer specifying the width of your CPU
interface. It must match the value of the CPUInterface property you have specified in
ETPlanner.
• <InputSVFFile> (Mandatory) — Path to SVF file containing the pattern you want to
translate into a CPUActionsFile.
• <outDir> (Optional) — Defines the location where the CPUActionsFile is to be written
to .Defaults to outDir/CPUInterfaceFiles when not specified.
• -skipPostTapUDS (Optional) — Specifies not to translate the SVF commands
corresponding to the PostTAPUserDefinedSequence. It is probable that the actions
performed by the PostTAPUserDefinedSequence do not need to be performed when
running the patterns through the CPU interface. For example, the
PostTAPUserDefinedSequence might initialize a PLL during manufacturing test. The
same PLL is most likely already initialized by the time the pattern will be executed
through the CPU interface in the system. To simulate such scenario, you would initialize
the PLL within the CPUSetupMethod and skip it when running svf2cpu such that the
PLL is not re-initialized by the TAP.

September 2017
svf2cpu Utility
Files’ Examples
Files’ Examples
The following example translates the file ./example.svf into ./example.cpuWR to be used by a
12-bit CPU interface:
svf2cpu 12 ./example.svf .
Figure 9-1 illustrates an example input SVF file, and Figure 9-2 shows the corresponding
generated output CPUActionsFile.
Figure 9-1. Example Input SVF File
!Setting up Controller block1_clk_MBIST1_LVISION_MBISTPG_CTRL connected to

BP1.WBP0
!Loading TAP Instruction BP1_WIR_SEL
SIR 18 TDI (0F37A) TDO (3FFFD) MASK (00003);

!Loading WTAP BP1 Instruction WBP0_SHORT_SETUP
!Inverting Asynchronous Interface clock of Bist controller because the
ratio 'TCK Period/bist controller clock Period' (14.0) is higher or equal
to 8.
SDR 29 TDI (0224040C) TDO (00000001) MASK (00000003);
SIR 18 TDI (0FF3A) TDO (3FFFD) MASK (00003);
SDR 102 TDI (00100000000000000000000000) TDO (00000000000000000000000000)

MASK (00000000000000000000000000);
!
!Starting Controller chip_clk_MBIST1_LVISION_MBISTPG_CTRL connected to BP0
SIR 18 TDI (0FFFD) TDO (3FFFD) MASK (00003);
SIR 18 TDI (0FFFD) TDO (3FFFD) MASK (00003);

! Checking that the DONE signal is NO on DR_STATUS0 at beginning of test
! Checking that the GO signal is FAIL on DR_STATUS1 at beginning of test
!LV TDO_SYMBOL[ 1: 1] DR_STATUS1[1];

!LV TDO_SYMBOL[ 0: 0] DR_STATUS0[1];
SDR 26 TDI (0237001) TDO (0000000) MASK (0000003);
Figure 9-2. Example Output CPUActionsFile
CPUComment ("Setting up Controller

block1_clk_MBIST1_LVISION_MBISTPG_CTRL connected to BP1.WBP0");
CPUComment ("Loading TAP Instruction BP1_WIR_SEL");
// SIR 18 TDI (0F37A) TDO (3FFFD) MASK (00003);

CPUWrite ({toPauseIR,10'b0111101000});
CPUWaitCycles (20);
CPURead ({2'bx1,10'bxxxxxxxx01},
"IR[9]",

September 2017
svf2cpu Utility
Files’ Examples
"IR[8]",
"IR[7]",
"IR[6]",
"IR[5]",
"IR[4]",
"IR[3]",
"IR[2]",
"IR[1]",
"IR[0]"
);
CPUWrite ({toRTI,10'b0011110011});
CPUWaitCycles (20);
CPUComment ("Loading WTAP BP1 Instruction WBP0_SHORT_SETUP");
CPUComment ("Inverting Asynchronous Interface clock of Bist controller
because the ratio 'TCK Period/bist controller clock Period' (14.0) is
higher or equal to 8.");
// SDR 29 TDI (0224040C) TDO (00000001) MASK (00000003);

CPUWrite ({toPauseDR,10'b0000011000});
CPUWaitCycles (20);
"DR[9]",
"DR[8]",
"DR[7]",
"DR[6]",
"DR[5]",
"DR[4]",
"DR[3]",
"DR[2]",
"DR[1]",
"DR[0]"
);
CPUWaitCycles (20);
CPUWaitCycles (20);
// SIR 18 TDI (0FF3A) TDO (3FFFD) MASK (00003);

CPUWaitCycles (20);
"IR[9]",
"IR[8]",
"IR[7]",
"IR[6]",
"IR[5]",
"IR[4]",
"IR[3]",
"IR[2]",
"IR[1]",
"IR[0]"
);
CPUWaitCycles (20);
// SDR 102 TDI (00100000000000000000000000) TDO

(00000000000000000000000000) MASK ( ...

September 2017
svf2cpu Utility
Files’ Examples
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUWaitCycles (20);
CPUComment ("");
CPUComment ("Starting Controller chip_clk_MBIST1_LVISION_MBISTPG_CTRL
connected to BP0");
// SIR 18 TDI (0FFFD) TDO (3FFFD) MASK (00003);

CPUWaitCycles (20);
"IR[9]",
"IR[8]",
"IR[7]",
"IR[6]",
"IR[5]",
"IR[4]",
"IR[3]",
"IR[2]",
"IR[1]",
"IR[0]"
);
CPUWaitCycles (20);
// SIR 18 TDI (0FFFD) TDO (3FFFD) MASK (00003);

CPUWaitCycles (20);
"IR[9]",
"IR[8]",
"IR[7]",
"IR[6]",
"IR[5]",
"IR[4]",
"IR[3]",
"IR[2]",
"IR[1]",
"IR[0]"
);

September 2017
svf2cpu Utility
Files’ Examples
CPUWaitCycles (20);
CPUComment (" Checking that the DONE signal is NO on DR_STATUS0 at
beginning of test");
CPUComment (" Checking that the GO signal is FAIL on DR_STATUS1 at
beginning of test");
// SDR 26 TDI (0237001) TDO (0000000) MASK (0000003);

CPUWaitCycles (20);
"DR[9]",
"DR[8]",
"DR[7]",
"DR[6]",
"DR[5]",
"DR[4]",
"DR[3]",
"DR[2]",
"DR_STATUS1",
"DR_STATUS0"
);
CPUWaitCycles (20);
CPUWaitCycles (20);

September 2017
svf2cpu Utility
Files’ Examples

September 2017
Chapter 10
ETVerify Runtime Options
This chapter describes in detail all the ETVerify runtime options.
ETVerify Runtime Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

-cdp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
-configFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
-controlInputOnlyPins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
-controllerStepAlgoSelectionFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
-createLVDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
-etaInfoFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
-etPlannerInfoDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
-exclude. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
-extractLVDBSubset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
-faultSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
-faultSimTrialNumber. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
-finalLvdbDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
-genConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
-genETAConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
-genManufacturingConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
-genParallelLoadConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
-genPinMapFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
-genUserDefinedSequenceInfoFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
-inputLVDBName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
-lbistVectorDump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
-outDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
-outputLVDBName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
-packageDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
-patternType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
-preLayoutFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
-reportSimProgress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
-select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
-serverExtraArgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
-startupFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
-stil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
-svf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

September 2017
-svfDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
-testLowerLevelControllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
-tcmFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
-topHDLConfig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
-tstl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
-userDefinedSequenceDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
-userScanModelDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
-useSVInterfacePortsFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
-verificationFlow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
-verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
-vif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
-wgl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

September 2017

The complete syntax for running ETVerify from the command line is as follows:
etv
etv -help
etv <designName>
-allowSOEDiagWithDifferentDefaultAlgos true | (false)
-cdp STIL | SVF
-configFile <configFileName>
-controlInputOnlyPinsThreeState | TwoStateWeak |(TwoStateStrong)
-controllerStepAlgoSelectionFile <fileName>
-createLVDB On | (Off)
-etaInfoFile <fileName>
-etPlannerInfoDir <directoryName>
-exclude <WrapperIdSet>
-extractLVDBSubset (Off) | NoLBISTDiag | NoVectors | NoDesignData
-faultSim On | (Off)
-faultSimTrialNumber <trialNumber>
-finalLvdbDir <dirName>
-genConfigFile EarlyVer | SignOff | PrepareSignOff
-genETAConfigFile On | (Off)
-genManufacturingConfigFile On | (Off)
-genParallelLoadConfig On | (Off)
-genPinMapFile On | (Off)
-inputLVDBName <lvdbDirName>
-lbistVectorDump On | (Off) | ChainInfo
-log <logFileName>
-membistAlgoFile <fileName>
-outDir <directoryName>
-outputLVDBName <lvdbDirName>
-packageDir <directoryName>
-patternType (Wgl) | Lsiwgl | None
-preLayoutFlow On | (Off)
-reportSimProgress (On) | Off
-select <WrapperIdSet>
-select <WrapperIdSet>
-startupFile <fileName>
-stil On | (Off)
-svf On | (Off)
-svfDir <directoryName>
-testLowerLevelControllers On | (Off)
-tcmFile <filename>
-tstl On | (Off)
-userDefinedSequenceDir <pathName>
-userScanModelDir <directoryName>
-useSVInterfacePortsFile On | Off
-verificationFlow EarlyVer | SignOff | PrepareSignOff
-verilog On | (Off)
-vif <directoryName>
-wgl On | (Off)
Valid values for command-line options are case-insensitive.
In the syntax above, designName specifies the top-level module name of the circuit. The top-
level module name of the circuit serves as default base name of the test connection map file,

September 2017
excluding the file extension. The default file extension for this file is .tcm. If the .tcm file is not
located in the current working directory, you must point to it using the -tcmFile command line
option. designName also specifies the base name of the input configuration file unless you
specify a configuration file name with the -configFile option. The default output file names
from ETVerify include designName as part of the base name. For example, the default file name
for the ETVerify configuration file is <designName>.etSignOff.
Specifying the -help option displays a summary of the command-line syntax and usage. Typing
etv without any parameters also displays this summary.

September 2017
-allowSOEDiagWithDifferentDefaultAlgos
-allowSOEDiagWithDifferentDefaultAlgos
The -allowSOEDiagWithDifferentDefaultAlgos option specifies whether to override the
default error that occurs with a warning when there are different default algorithms in different
controller steps.
Syntax
The following syntax specifies this option:
-allowSOEDiagWithDifferentDefaultAlgos true | (false)

• true — instructs ETVerify to override the default error that the tool produces with a warning
when there are different default algorithms in different controller steps. The tool issues a
warning and proceeds with CDP generation.
• false — instructs ETVerify to issue an error.
Default Value
The default value is false.
Usage Conditions
• You must specify this option with the -serverExtraArgs option. For example:
-serverExtraArgs "-allowSOEDiagWithDifferentDefaultAlgos TRUE"
• Use this option in conjunction with the -cdp option when generating a CDP for SOE
diagnosis with Tessent SiliconInsight as described in the Tessent SiliconInsight User’s
Manual for the LV Flow.
• You can also use this switch when invoking interactive Tessent SiliconInsight.
Examples
The following example generates a CDP that contains STIL test patterns and issues warnings if
the tool encounters different default algorithms.
etv designA -inputLVDBName ../../TOP.lvdb \
-configFile TOP.etManufacturing -cdp stil \
The following example invokes interactive Tessent SiliconInsight:

sid -cable signalyzer -lvdb ./lib/TOP.lvdb -pinmapfile
./lib/TOP.pinmap_tpl_tap -configFile TOP.etManufacturing
-outdir ./outDir_eta
Related Topics
-cdp

September 2017
-cdp
-cdp
The -cdp option generates a Characterization and Debug Package (CDP) that contains test
patterns.
Syntax
-cdp STIL | SVF

• STIL — instructs ETVerify to generate the test patterns in STIL pattern format.
• SVF — instructs ETVerify to generate the test patterns in SVF pattern format.
Usage Conditions
• This option is required when you are generating enhanced Stop-on-Nth-Error test patterns
for memory diagnostics as described in the Tessent SiliconInsight Usage Guide and
Reference.
• When you use this switch, you must also specify the -inputLVDBName and the -configFile
options.
Example
The following example generates a CDP that contains STIL test patterns.
etv designA -inputLVDBName ../../TOP.lvdb \
-configFile TOP.etManufacturing -cdp stil
Related Information
-configFile -inputLVDBName

September 2017
-configFile
-configFile
The -configFile option enables you to specify the name of the input configuration file. This file
enables you to add sections for verifying TAP, scan structures, and all types of embedded test
controllers.
Syntax
-configFile <configFileName>
where configFileName can be any identifier that is a valid operating system filename.
configFileName might include path information as well.
Default Value
The default value is <designName>.etEarlyVer.
Usage Conditions
• Only one of the -genManufacturingConfigFile, -genConfigFile, -configFile, and -
verificationFlow options can be specified at a time.
• When used along with -inputLVDBName, the configuration file is looked up in the LVDB
if there is no path associated with the filename. Otherwise, the specified file is used.
Example
This example instructs ETVerify to read the specified configuration file, config1.etEarlyVer
rather than the default configuration file, myDesignA.etEarlyVer.
etv myDesignA -configFile config1.etEarlyVer
Related Information
-genConfigFile -inputLVDBName
-genManufacturingConfigFile -verificationFlow

September 2017
-controlInputOnlyPins
The -controlInputOnlyPins option enables you to specify the default value that ETVerify will
assign to the control capability of tester channels contacted to the input design pins when it
generates the loadboard information template file(Loadboard Information File).
Note
This information affects the way ETVerify generates 1149.6 boundary scan tests. Refer to
Application Note Support for IEEE 1149.6 Boundary Scan for more details about 1149.6
boundary scan tests and LoadBoardInfo file.
Syntax
-controlInputOnlyPins ThreeState | TwoStateWeak |
(TwoStateStrong)

• ThreeState — instructs ETVerify to set to ThreeState the default control capability of tester
channels contacted to the design pins when generating the loadboard information template
file.
• TwoStateWeak — instructs ETVerify to set to TwoStateWeak the default control capability
of tester channels contacted to the input design pins when generating the loadboard
information template file.
• TwoStateStrong — instructs ETVerify to set to TwoStateStrong the default control
capability of tester channels contacted to the input design pins when generating the
loadboard information template file.
Default Value
The default value is TwoStateStrong.
Usage Conditions
This option is only meaningful when -genConfigFile is On.
Example
This example instructs ETVerify to set the default control capability of tester channels
contacted to the input design pins to ThreeState in the loadboard information template file it
generates.
etv TOP -genConfigFile SignOff \
-genStartupFile ./TOP.etv_startup \
-tcmFile ../ETAssemble/TOP.tcm \
-controlInputOnlyPins ThreeState
The commands above result in the following loadboard information template file:
LoadboardInfo (TOP) {
ContactedPins {

September 2017
DesignPin (TDI) {
Control: ThreeState;
}
DesignPin (TMS) {
}
...
DesignPin (Y(0)) {
Observation: ThreeState;
}
DesignPin (Y(1)) {
}
...
}
}
Related Information
-genConfigFile Application Note Application Note Support for
IEEE 1149.6 Boundary Scan and
LoadBoardInfo.

September 2017
-controllerStepAlgoSelectionFile
-controllerStepAlgoSelectionFile
The -controllerStepAlgoSelectionFile option enables you to specify the
.controllerStepAlgoSelection File that will be used by ETVerify to populate the
.etManufacturing file. The controller step algorithm selection file designates the soft-coded
algorithms to be applied for each step of Tessent MemoryBIST SoftProgrammable controllers.
Syntax
-controllerStepAlgoSelectionFile <fileName>
where fileName can be any identifier that is a valid operating system filename. It might include
path information as well.
Default Value
The default value is <designName>.controllerStepAlgoSelectionFile.
Usage Conditions
• This option is optional and not repeatable.
• The .controllerStepAlgoSelection file is only applicable to Tessent MemoryBIST
• You must specify -membistAlgoFile to reference the Tessent MemoryBIST Algorithm File.
• If the .controllerStepAlgoSelection file does not exist, ETVerify will generate a template file
with the extension .controllerStepAlgoSelection_tpl. This template file will apply all soft-
coded algorithms defined in the Tessent MemoryBIST Algorithm file to all controller steps.
You need to remove algorithms that are not applicable to a controller step by deleting or
commenting the “<AlgorithmName>: Yes;” lines, or setting the property value to No. Once
the changes are completed, rename the template file extension to
.controllerStepAlgoSelection and regenerate the .etManfacturing file.
Example
In this example, the soft-coded algorithms are defined in the test.softAlgos algorithm file, and
the algorithm assignments are specified in the test.stepAlgos selection file.
etv TOP -membistAlgoFile test.softAlgos \
-controllerStepAlgoSelectionFile test.stepAlgos
Related Information
-membistAlgoFile .controllerStepAlgoSelection File

September 2017
-createLVDB
-createLVDB
The -createLVDB option instructs ETVerify to create the Mentor Graphics sign-off database
(LVDB) directory. This generated LVDB directory contains all vector and signature
information and internal Mentor Graphics files related to your design.
Syntax
-createLVDB On | (Off)

• On — instructs ETVerify to create the LVDB directory based on your entire netlist,
including all softlinks.
• Off — instructs ETVerify to not create the database.
Default Value
The default value is Off.
Usage Conditions
• You can use the LVDB directory for manufacturing and system reuse of the embedded test
capabilities.
• LVDB directory can be used to hand-off cores with embedded test to third party vendors.
Example
The following example instructs ETVerify to create the LVDB directory using the TOP.netlist
file.
etv TOP -createLVDB On
Related Information
-inputLVDBName -outputLVDBName

September 2017
-etaInfoFile
-etaInfoFile
The -etaInfoFile option specifies the location of the ETVerify output file—ETA.info. This file
is used to support parameterized Tessent MemoryBIST soft-coded algorithms.
Syntax
The syntax for this option is as follows:
-etaInfoFile <fileName>
where fileName can be any identifier that is a valid operating system filename. fileName might
also include path information.
Default Value
The default is ETA.info within the Mentor Graphics database (LVDB) directory.
Usage Conditions
• This option is optional and not repeatable.
• The ETA.info file is required if you specify parameterized properties within your soft-coded
algorithm definition.
• The ETA.info file is generated by ETVerify as part of the LVDB. The Tessent MemoryBIST
tool also creates the ETA.info file for the memory assembly module.
Example
This example instructs ETVerify to read the ETA.info within the LVDB:
etv TOP -etaInfoFile ../../finalLVDB/TOP.lvdb/ETA.info
Related Information
-createLVDB

September 2017
-etPlannerInfoDir
-etPlannerInfoDir
The -etPlannerInfoDir option specifies the name of the directory from where the files will be
generated by ETPlanner, and ETChecker will be copied in the LVDB when created.
This option is meant to be used in ETSignOff Step.
Syntax
-etPlannerInfoDir <dirName>
where dirName can be any directory path information.

Default Value
The default value is ../ETPlannerInfo. This value enables you to specify the name of the input
configuration file that will be used to add sections for verifying TAP, scan structures, and all
types of embedded test controllers.
Usage Conditions
None
Example
This example specifies that the name of is ../ETPlannerInfo.
etv myDesignA -etPlannerInfoDir ../ETPlannerInfo
Related Information
None

September 2017
-exclude
-exclude
The -exclude option enables you to exclude the specified wrappers in the Specific Verification
Sections of the ETVerify configuration file from being processed.
Syntax
-exclude “<wrapperIdSet>”
where wrapperIdSet is a string in the format

<verifyWrapperName> (<id>)[:TestStep (<Id>)[:Controller (<id>)]].
Valid values of this string are as follows:
• verifyWrapperName — is one of the wrappers in the Specific Verification Section of the
ETVerify configuration file, such as:
o CustomVerify
o JtagVerify
o LogicbistVerify
o MembistVerify
o MembistPVerify
o ScanVerify
o SerdesVerify
o WTAPVerify
or a string containing wild card characters * and/or ? that match one of them.
• id — is a string that may contain wildcard characters * and/or ? matching the name of the
corresponding wrappers.
• Substrings inside [] are optional.
• No spaces are allowed inside the wrapperIdSet string.
Default Value
None that means “exclude nothing”.
Usage Conditions
More than one -exclude runtime option can be specified on the command-line, and their effect
will be cumulative. The ETVerify tool issues a warning if the given combination of -exclude
and -select options does not select any wrapper at all.

September 2017
-exclude
Example
This example specifies to ETVerify to process the configuration file excluding all
LogicbistVerify wrappers.
etv myDesignA -exclude “logicbistVerify(*)”
Related Information
Summary of Specific Verification Sections MembistVerify
-select MemBistController
CustomVerify ScanVerify
JtagVerify SerdesVerify
LogicbistVerify WTAPVerify

September 2017
-extractLVDBSubset
-extractLVDBSubset
The -extractLVDBSubset option enables you extract a subset of the LVDB and copy the
contents into a new directory for Go/NoGo testing. This new LVDB directory does not contain
diagnostic vector files.
Syntax
-extractLVDBSubset (Off) | NoLBISTDiag | NoVectors |
NoDesignData
• Off — does not create an extracted subset LVDB directory.
• NoLBISTDiag — instructs ETVerify to exclude logic BIST diagnostic vectors. Scan vectors
for single- and multi-modes are still preserved.
• NoVectors — instructs ETVerify to exclude all vector files from the extracted subset,
including the logicBIST single- and multi-scan modes. This results in a compact LVDB that
contains enough information for Go/NoGo testing of logic BIST.
• NoDesignData — instructs ETVerify to exclude design specific data files from the extracted
subset including all signatures files (*.siga). Note that without the .siga files, gate-level
diagnosis and re-computation of the logic BIST signature in the presence of masking of
chains or chain segments is not possible.
Default Value
Usage Conditions
• This option must be used with the following runtime options when you want to extract a
subset of the existing LVDB:
o -inputLVDBName — specifies the path to the input LVDB from which the subset is
to be extracted.
o -outputLVDBName — specifies the path to the output LVDB to be created with the
subset.
• This option cannot be used when the following runtime options are set as follows:
o -genConfigFile Prepare, EarlyVer, PrepareSignOff, or SignOff
o -createLVDB On
Example
In the following example, ETVerify is instructed to extract a subset of MyDesign.lvdb excluding
all diagnostic vector files.
etv MyDesign \

September 2017
-extractLVDBSubset
-extractLVDBSubset NoVectors \
-inputLVDBName ../../MyDesign.lvdb \
-outputLVDBName ../../MyDesign_noDiag.lvdb
Related Information
-inputLVDBName -genConfigFile
-outputLVDBName -createLVDB

September 2017
-faultSim
-faultSim
The -faultSim option specifies whether a fault simulation with random patterns is performed to
generate a fault coverage report for the current design.
Syntax
-faultSim On | (Off)
Default Value
Usage Conditions
None
Example
In the following example, ETVerify is instructed to perform a fault simulation with random
patterns.
etv MyDesign \
-faultSim On \
Related Information
-faultSimTrialNumber

September 2017
The -faultSimTrialNumber option specifies how many random trials to simulate, when logic
BIST is not present in the current design, to obtain a fault coverage report for the current design.
Syntax
-faultSimTrailNumber <trailNumber>
Default Value
The default value is 100K
Usage Conditions
Use this option in conjunction with the -faultSim option.
Example
In the following example, ETVerify is instructed to simulate 50 random trials.
etv MyDesign \
-faultSimTrialNumber 50K
Related Information
-faultSim

September 2017
-finalLvdbDir
-finalLvdbDir
The -finalLvdbDir option instructs ETVerify on where to save the final LVDB. In a Bottom-
Up flow, it also instructs ETVerify on where to find final LVDB files of lower-level physical
regions.
Syntax
-finalLvdbDir <dirName>
Default Value
None
Usage Conditions
• When lower-level LVDBs exist, they should be all (or soft-linked) in this directory so that
ETVerify can source appropriate files to build the final LVDB for the actual level.
• You use this runtime option in conjunction with -createLVDB set to On.
Example
This example instructs ETVerify to create the final LVDB files in the directory ../../finalLVDB.
If lower-level final LVDBs are required, they should also be present (or soft-linked) in this
directory.
etv TOP
-createLVDB On
-etPlannerInfoDir TOP.lvdb_preLayout
-outputLVDBName ../../finalLVDB/TOP.lvdb
-finalLvdbDir ../../finalLVDB
-tcmFile TOP.lvdb_preLayout/TOP.tcm ...
Related Information
-createLVDB -outputLVDBName
-faultSim

September 2017
-genConfigFile
-genConfigFile
The -genConfigFile option instructs ETVerify to create the configuration files for sign-off
verification. These files may require editing before you use them with the -configFile runtime
option in subsequent runs.
Syntax
-genConfigFile EarlyVer | PrepareSignOff | SignOff

• EarlyVer — instructs ETVerify to generate the configuration file during the Early
Verification in the ETASsemble Step on the block or top—<designName>.etEarlyVer file.
• PrepareSignOff — instructs ETVerify to generate the configuration file for scan-inserted
block sign-off — <designName>.etSignOff file.
• SignOff — instructs ETVerify to generate the configuration file for TOP or core sign-off in
the Final ETSignOff Step — <designName>.etSignOff.
Default Value
None
Usage Conditions
• The configuration files are always created in the current working directory. The value of the
-outDir option is ignored. Also, the names of the configuration files are always as shown
above. If you want to specify different names for the configuration files, you must rename
the files after ETVerify has created them.
• Depending on the value of -patternType, a format-specific wrapper is generated in the
configuration file.
• Only one of the -configFile, -genConfigFile, -genManufacturingConfigFile, and
-verificationFlow options can be specified at a time. The exception to this is the usage of the
-configFile and -genManufacturingConfigFile runtime options together.
Example
This example instructs ETVerify to generate the configuration file for the Sign-Off Flow—
<myDesignA>.etSignOff.
etv myDesignA -genConfigFile SignOff
Related Information
-configFile -verificationFlow
-outDir -genManufacturingConfigFile
-patternType

September 2017
-genETAConfigFile
-genETAConfigFile
The -genETAConfigFile option instructs ETVerify to translate the configuration file specified
with the -configFile option into the ETA configuration format. The translated file is named
<configFileName>.config_eta.
Syntax
-genETAConfigFile On | (Off)
Default Value
The default is Off.
Usage Conditions
None
Example
This example instructs ETVerify to translate the configuration file TOP.etManufacturing_2 into
the ETA configuration format.
etv myDesignA -configFile TOP.etManufacturing_2
-genETAConfigFile On
Related Information
-configFile

September 2017
-genManufacturingConfigFile
The -genManufacturingConfigFile option instructs ETVerify to create the configuration file
for manufacturing pattern generation. You may have to edit this file before you use it with the -
configFile option in subsequent runs.
Syntax
-genManufacturingConfigFile On | (Off)

• On — instructs ETVerify to generate the manufacturing configuration file
<designName>.etManufacturing
• Off — instructs ETVerify to not generate the manufacturing configuration file
<designName>.etManufacturing
Default Value
Usage Conditions
• The configuration files are always created in the current working directory. The value of the
-outDir option is ignored.
• The name of the configuration file is always <designName>.etManufacturing. If you want
to specify a different name for the configuration file, you must rename it after ETVerify has
created it.
• Depending on the value of the -patternType option, a format-specific wrapper is generated
in the configuration file.
• Always use the -configFile option with the -genManufacturingConfigFile option.
ETVerify reads the configuration file specified with the -configFile option (typically—
<designName>.etSignOff) to detect commonly used settings entered in this file. The
commonly-used settings are the following:
o UserIRBit
o UserDRBit
o Pin Settings
o UserDefinedSequence
ETVerify then propagates (copies) these commonly used settings to the Manufacturing
configuration file using one of the following propagation schemes:
o The commonly-used settings are propagated per controller.

September 2017
When one of the options is found in the specified configuration file, ETVerify
detects to which controller(s) the option applies and propagates it into any ETVerify
wrapper in the manufacturing configuration file that contains this controller.
o The commonly used settings are propagated to all ETVerify wrappers. When one of
the options is found in the CustomVerify wrapper of the specified configuration file
that has the option -monitorClocks defined, ETVerify propagates (copies) the
option into all xxxVerify wrappers of the manufacturing configuration file
• Only one of the -genManufacturingConfigFile, -genConfigFile, and -verificationFlow
options can be specified at a time.
Example
This example instructs ETVerify to generate the manufacturing configuration file
<myDesignA>.etManufacturing:
etv myDesignA -genManufacturingConfigFile On
-configFile myDesignA.etSignOff
Related Information
-genConfigFile -outDir
-verificationFlow -patternType
-configFile CustomVerify

September 2017
-genParallelLoadConfig
-genParallelLoadConfig
The -genParalleLoadConfig option is used along with the -genConfigFile or -verificationFlow
runtime option to instruct ETVerify whether or not to generate a configuration file that has
some test steps in ParallelLoad mode for the ScanVerifyand LogicbistVerify wrappers.
Syntax
-genParallelLoadConfig (On) | Off

• On — instructs ETVerify to generate a configuration file that has some test steps in
ParallelLoad mode for the ScanVerifyand LogicbistVerifywrappers.
• Off — instructs ETVerify not to generate a configuration file that has some test steps in
ParallelLoad mode for the ScanVerify and LogicbistVerifywrappers.
Default Value
The default is On.
Usage Conditions
• This option is only meaningful if used along with the -genConfigFile and -verificationFlow
runtime options.
• .etManufacturing configuration file does not contain any TestStep wrappers with
ParallelLoad set to On.
• Set this runtime option to Off if your simulator does not support parallel-loading test
benches.
Example
This example instructs ETVerify not to generate the configuration files for the Sign-Off Flow—
<myDesignA>.etSignOff and <myDesignA>.etManufacturing files, if they have some test steps
in ParallelLoad mode for the ScanVerifyand LogicbistVerify wrappers.
etv myDesignA -genConfigFile SignOff
-genParallelLoadConfig Off
Related Information
-genConfigFile ParallelLoad
-verificationFlow ScanVerify
LogicbistVerify

September 2017
-genPinMapFile
-genPinMapFile
The -genPinMapFile option instructs ETVerify to generate a Pin Mapping template file.
Syntax
-genPinMapFile On | (Off)

• On — instructs ETVerify to generate the Pin Mapping template file
<designName>.pinmap_tpl.
• Off — instructs ETVerify to not generate t the Pin Mapping template file
<designName>.pinmap_tpl.
Default Value
The default is Off.
Usage Conditions
• The Pin Mapping File usually resides in and LVDB directory and is used by the Mentor
Graphics Silicon Insight. It sets the mapping between the design pin names and a tester’s pin
names and specifies conditions external to the Design-Under-Tests such as pull resistors and
loopbacks.
• The Pin Map file generated by ETVerify is a “template” (the suffix _tpl stand for
“template”) and is typically renamed and customized by the user to reflect the test
conditions prior to be used with Silicon Insight.
For more details on Pin Mapping files, refer to “Creating a Tessent SiliconInsight Pin Map
File” in the Tessent SiliconInsight User’s Manual for the LV Flow.
Note
ETVerify automatically generates a Pin Mapping File template in the LVDB directory
when the runtime option -createLVDB is On.
• The following runtime options must all be set to Off when -genPinMapFile is On:
o -genConfigFile
o -createLVDB
o -extractLVDBSubset
Example
This example instructs ETVerify to generate a Pin Mapping template file for the design TOP:
etv Top -genPinMapFile On \
-tcmFile TOP.lvdb_preLayout/TOP.tcm

September 2017
-genPinMapFile
Related Information
-createLVDB -genConfigFile
-extractLVDBSubset

September 2017
-genUserDefinedSequenceInfoFiles
-genUserDefinedSequenceInfoFiles
The -genUserDefinedSequenceInfoFiles option instructs ETVerify to translate
UserDefinedSequences containing ClockSourceOverride information into .pgsl_uds_info files
that are used by SID to know what clock overrides are applied in a UDS.
Syntax
-genUserDefinedSequenceInfoFiles On | (Off)

• On — instructs ETVerify to translate UserDefinedSequences containing
ClockSourceOverride information into .pgsl_uds_info files.
• Off — instructs ETVerify to not translate UserDefinedSequences containing
ClockSourceOverride information into .pgsl_uds_info files.
Default Value
The default is Off.
Usage Conditions
The .pgsl_uds_info files are automatically created starting in the Tessent v2016.2 release. Use
this option if your LVDB is from a release older than Tessent v2016.2, and you just need the
.pgsl_uds_info files for SID.
Related Information
ClockSourceOverride UserDefinedSequence

September 2017
-inputLVDBName
-inputLVDBName
The -inputLVDBName option specifies the name of the LVDB directory ETVerify uses to
generate test patterns for manufacturing files.
Syntax
-inputLVDBName <lvdbDirName>
where lvdbDirName is the name of the LVDB directory in which all files pertaining to the entire
netlist are stored.
Default Value
None
Usage Conditions
When you run ETVerify to create a subset of LVDB, you must specify this option with the
following:
• lvdbDirName — which specifies the path to the input LVDB from which the subset needs to
be extracted.
• -extractLVDBSubset — instructs ETVerify to extract a subset of LVDB excluding vector
files.
• -outputLVDBName — specifies the path to the output LVDB to be created with the subset.
Example
The following example instructs ETVerify to create patterns for manufacturing in the WGL
format using the TOP.etManufacturing file and the TOP.lvdb directory.
etv TOP \
-inputLVDBName ../../TOP.lvdb \
-configFile TOP.etManufacturing \
-wgl On
Related Information
-createLVDB -outputLVDBName
-extractLVDBSubset

September 2017
-lbistVectorDump
-lbistVectorDump
The -lbistVectorDump option instructs ETVerify to generate a set of files that will be used by
Silicon Insight for logic diagnostics.
Syntax
-lbistVectorDump On | (Off) | ChainInfo
Default Value
Usage Conditions
• You must specify the -inputLVDBName option when running -lbistVectorDump On.
• With -lbistVectorDump set to ChainInfo, the .lbist_chain_info file is only generated.
• With -lbistVectorDump set to On, the .lbist_chain_info file and all other files are generated.
Example
This example instructs ETVerify to generate a set of files that will be used by Tessent Silicon
Insight for logic diagnostics.
etv myDesign -lbistVectorDump On \
-inputLVDBName ../../TOP.lvdb -outDir out1
Related Information
-inputLVDBName -outDir

September 2017
-log
-log
The -log option specifies the name of the log file that ETVerify automatically generates.
Syntax
-log <fileName>
where fileName can be any identifier that is a valid operating system character string defining a
filename or a complete pathname.
Default Value
The default value is etv.log.
Usage Conditions
Two usage conditions apply for the -log runtime option:
• If you do not specify a log file using the -log option, ETVerify writes the log file to the
output directory specified using the -outDir option as <outputDirectory>/etv.log.
• If you specify a file name that does not contain a directory path, the log file is placed in the
directory specified by the -log option. If the -log option includes a directory specifier, then
the log file is created using the given file name, ignoring the -outDir option.
Example
This example runs ETVerify and generates a log file, lbistv_Run1.log in the out1 directory.
etv myDesign -log etv_Run1.log -outDir out1
The following syntax examples illustrate the resulting directory location according to the usage
conditions described above:
Syntax Example Log File Location
etv myDesign ./etv.log
etv myDesign -outDir out out/etv.log
etv myDesign -log mylog ./mylog
etv myDesign -outDir work \
-log ../logdir/mylog ../logdir/mylog
etv myDesign -outDir work \
-log mylog work/mylog
Related Information
-outDir

September 2017
-membistAlgoFile
-membistAlgoFile
The -membistAlgoFile option specifies the file containing the definitions of Tessent
MemoryBIST soft-coded algorithms. This file will be read by the ETVerify tool for test bench
and pattern generation.
Syntax
-membistAlgoFile <fileName>
also include path information.
Default Value
The default is ETMemoryAlgorithms/default.membistAlgo within the Mentor Graphics database
(LVDB) directory.
Usage Conditions
• This property is optional and not repeatable.
• You must specify this option if you will be using soft-coded algorithms with your Tessent
MemoryBIST SoftProgrammable controllers.
Example
This example instructs ETVerify to read the soft-coded algorithms from the specified file:
etv TOP -membistAlgoFile ../../tsmc65nm/mem.algos
Related Information
Tessent MemoryBIST Algorithm File MemBistAlgorithmFile property in the
manual ETPlanner Tool Reference

September 2017
-outDir
-outDir
The -outDir option identifies the directory in which ETVerify generates its output files.
Syntax
-outDir <directoryName>
where directoryName can be any identifier or pathname that is a valid operating system
filename.
Default Value
The default output directory is the current working directory—the directory from which you
invoked ETVerify.
Usage Conditions
• If the directory specified with directoryName does not exist, ETVerify creates it.
• This option has no effect on the placement of the startup file and configuration files
generated by ETVerify.
• This option has no effect on the placement of the VIF database specified by the -vif runtime
option.
• ETVerify includes the intermediate test bench patterns (VIF) in a separate directory
specified by the -vif runtime option. The default directory for VIF patterns is
<designName>.vif.
• Vector dataset is stored in LV_WORKDIR.
Example
In this example, ETVerify creates the directory Run1 and places the ETVerify output files in it.
etv myDesignA -outDir Run1
Related Information
Identifiers -log
-genConfigFile -vif

September 2017
-outputLVDBName
-outputLVDBName
The -outputLVDBName option specifies the name of the LVDB in which you want ETVerify
to store the files needed for design hand-off.
Syntax
-outputLVDBName <lvdbDirName>
where lvdbDirName is the name of the LVDB directory.

Default Value
None
Usage Conditions
This option is only meaningful when either the option -extractLVDBSubset or
-inputLVDBName are set to On. When you run ETVerify to create a subset of LVDB, you must
specify this option with the following:
• lvdbDirName — specifies the path to the output LVDB to be created with the subset.
• -extractLVDBSubset — instructs ETVerify to extract a subset of LVDB excluding vector
files.
• -inputLVDBName — specifies the path to the input LVDB from which the subset needs to
be extracted.
Example
The following example instructs ETVerify to create an LVDB directory, ../../TOP.lvdb, and
store all required files in the directory.
etv TOP \
-createLVDB On \
-outputLVDBName ../../TOP.lvdb
Related Information
-createLVDB -inputLVDBName
-extractLVDBSubset

September 2017
-packageDir
-packageDir
The -packageDir option identifies one or more directories in which necessary BSDL packages
reside.
Syntax
-packageDir <directoryName>
filename.
Default Value
The default directory is the current working directory—that is, the directory from which you
invoked ETVerify.
Usage Conditions
• You can repeat this option to specify additional directories.
• The ETVerify tool searches for BSDL packages in the same order in which you specified
the -packageDir runtime option.
Example
In this example, ETVerify searches the directory bsdl_packages for BSDL packages.
etv myDesignA -packageDir bsdl_packages
Related Information
None

September 2017
-patternType
-patternType
The -patternType option, when used with the -genConfigFile SignOff option, instructs
ETVerify to insert a format-specific wrapper in the .etManufacturing configuration file. This
information is used by ETVerify during creation of the test vector file. You edit the generated
configuration file to further customize the properties in the format-specific wrapper.
Syntax
-patternType: (Wgl)| Lsiwgl | None;

• Wgl — instructs ETVerify to insert a WGL wrapper in the .etManufacturing file.
• Lsiwgl — instructs ETVerify to insert a WGL wrapper in the .etManufacturing file and to
set the Type property to LSI.
• None — specifies that no format-specific is inserted.
Default Value
The default value is Wgl.
Usage Conditions
When you specify -wgl On option and the .etManufacturing configuration file contains a WGL
wrapper, ETVerify uses the property values specified in the wrapper to generate test patterns in
the WGL format.
Example
The following syntax instructs ETVerify to create TOP.etManufacturing. Also, the syntax
instructs ETVerify to insert the WGL wrapper with format-specific property place holders in the
TOP.etManufacturing file.
etv TOP \
-genConfigFile TOP.etSignOff \
-genManufacturingConfigFile On \
-tcmFile TOP.lvdb_preLayout/TOP.tcm \
-patternType Wgl \
-wgl On
Related Information
-genManufacturingConfigFile Type
-wgl WGL

September 2017
-preLayoutFlow
-preLayoutFlow
The -preLayoutFlow option specifies whether ETVerify is being run in the pre-layout flow.
When set to On, it only copies a minimal set of files to the LVDB to keep its size as small as
possible.
Syntax
-preLayoutFlow: On | (Off);
Default Value
Usage Conditions
This option is only meaningful when used with -createLVDB On
Example
The following syntax instructs ETVerify to create an LVDB in preLayoutFlow mode.
etv TOP \
-createLVDB On \
-etPlannerInfoDir ../ETPlannerInfo
-preLayoutFlow On \
-outputLVDBName .../ETSignOff/TOP.lvdb_preLayout \
-tcmFile TOP.tcm \
-log outDir/etv.log_CreateLVDB
Related Information
None

September 2017
-reportSimProgress
-reportSimProgress
The -reportSimProgress option specifies whether or not ETVerify includes reporting of
simulation progress in the test bench it creates. When this option is selected, the Verilog
simulation tool reports simulation progress in 5% increments.
Syntax
-reportSimProgress (On) | Off

• On — specifies that simulation progress is to be reported in 5% increments for each major
simulation loop, such as the initial wait and each test step.
• Off — specifies that simulation progress is not to be reported.
Default Value
The default value is On.
Usage Conditions
This option is only meaningful with -verilog On.
Example
In this example, ETVerify creates a Verilog test bench that does not include simulation progress
reporting.
etv myDesignA -configFile TOP.etSignOff \
-inputLVDBName ../../finalLVDB/TOP.lvdb \
-verilog On \
-reportSimProgress Off
Related Information
-verilog

September 2017
-select
-select
The -select option enables you to select which controller-specific wrappers in the sign-off
configuration files are to be processed during an ETVerify run.
Syntax
-select “<wrapperIdSet>”
where wrapperIdSet is a string in the format <verifyWrapperName> (<id>)[:TestStep

(<Id>)[:Controller (<id>)]]. wrapperIdSet must not contain in spaces.
Valid values of this string are as follows:
• verifyWrapperName — is one of the wrappers in the Specific Verification Sections of the
ETVerify configuration file, such as:
o CPUVerify
o CustomVerify
o LogicbistVerify
o JtagVerify
o MembistPVerify
o MembistVerify
o ScanVerify
o SerdesVerify
o WTAPVerify
or a string containing wild card characters * and/or ? that matches one of them.
• id — is a string that may contain wildcard characters * and/or ? matching the name of the
corresponding wrappers.
• Substrings inside [] are optional.
• No spaces are allowed inside the wrapperIdSet string.
Default Value
The default behavior is to use all wrappers.
Usage Conditions
More than one -select option can be specified on the command-line, and their effect will be
cumulative. Some of the wrappers can be excluded with -exclude option. The ETVerify tool
issues a warning if the given combination of -exclude and -select options does not select any
wrapper.

September 2017
-select
Example
This example specifies to ETVerify to process only the LogicbistVerify wrapper in the
ETVerify configuration file.
etv myDesignA -select “logicbistVerify(*)”
Related Information
Summary of Specific Verification Sections MembistVerify
-exclude MembistPVerify
CPUVerify ScanVerify
CustomVerify SerdesVerify
JtagVerify WTAPVerify
LogicbistVerify

September 2017
-serverExtraArgs
-serverExtraArgs
The -serverExtraArgs option allows you to disable the 2% safety scaling factor to the clock
period on the BIST clock.
Syntax
-serverExtraArgs “-disableAsyncClockTwoPercentScaling true | (false)”

• true — instructs ETVerify to disable the 2% safety scaling factor to the clock period.
false — instructs ETVerify to apply the 2% safety scaling factor to the clock period.
Default Value
The default behavior is to apply the 2% safety scaling factor.
Usage Conditions
This command is applicable only when you are using the -cdp switch to generate a CDP for
purposes of diagnosing and validating ESOE test patterns.
Related Information
-cdp “Generating a CDP That Contains ESOE Test
Patterns” in the Tessent SiliconInsight User’s
Manual for the LV Flow.

September 2017
-startupFile
-startupFile
The -startupFile option enables you to specify the name of the startup file that is used to
customize ETVerify configuration files.
Syntax
-startupFile <fileName>
where fileName can be any identifier that is a valid operating system filename. fileName can
also include the path information.
Default Value
The default startup file name is <designName>.etv_startup.
Usage Conditions
The startup file is typically generated by ETAssemble.
Example
This example instructs ETVerify to read the specified startup file, startup1.etv_startup rather
than the default startup file, myDesignA.etv_startup.
etv myDesignA -startupFile startup1.etv_startup
Related Information
None

September 2017
-stil
-stil
The -stil option enables you to control whether or not ETVerify generates STIL format pattern
files.
Syntax
-stil On | (Off)

• On — generates STIL format pattern files.
• Off — does not generate STIL format pattern files.
Default Value
The default value is Off. The ETVerify tool creates a pattern set in Mentor Graphics VIF format
and does not generate STIL format pattern files.
Usage Conditions
To use -stil On, you must not set -svf to On.
Example
In this example, ETVerify creates STIL simulation test benches.
etv myDesignA -stil On
Related Information
-outDir -vif
-svf

September 2017
-svf
-svf
The -svf option controls whether or not ETVerify generates appropriate serial vector format
(SVF) files to run on an automatic test equipment.
Syntax
-svf On | (Off)

• On—generates an SVF file.
• Off—does not generate an SVF file.
Default Value
Usage Conditions
ETVerify ignores the options -stil, -verilog, -vif, and -wgl when you specify -svf On.
Example
In this example, ETVerify creates a etv_myDesignA.svf test pattern file.
etv myDesignA -svf On
Related Information
-stil -vif
-verilog -wgl

September 2017
-svfDir
-svfDir
The -svfDir option specifies the name of the directory where to look for the SVF files specified
by the SVFFile property in the CustomVerify wrapper(s) of the ETVerify configuration file.
Syntax
-svfDir <directoryName>
filename.
Default Value
The default value is the current working directory when -createLVDB is Off. There is no default
value when -createLVDB is On.
Usage Conditions
Use this option under the following conditions:
• You are referencing SVF files within the CustomVerify wrapper.
• You want to collect SVF files into your /lvdb directory for reference by CustomVerify
wrappers(s) within the .etSignoff or .etMAnufacturing files.
• When used along with -createLVDB On, all files inside svfDir are copied to the SVFFiles
directory inside LVDB. When used with -inputLVDBName, this option is ignored, and all
SVF files are looked up in <LVDB>/SVFFiles directory. Otherwise, the SVF file
corresponding to the SurfaceProportion property in the CustomVerify wrapper is searched
in svfDir.
Example
In the following example, ETVerify will look for the referenced SVF file inside the directory
called MySVFFiles:
etv TOP -svfDir MySVFFiles
Related Information
CustomVerify -createLVDB
SVFFile -inputLVDBName

September 2017
-testLowerLevelControllers
-testLowerLevelControllers
The -testLowerLevelControllers option is used along with the -genConfigFile runtime option
to instruct ETVerify to generate a configuration file in which each controllers of the design is
tested regardless their test hierarchy level in the design.
Syntax
-testLowerLevelControllers On | (Off)
where the values are as follows:

• On — instructs to test each controller in a design regardless their test hierarchy level in the
design.
• Off — does not instruct to test each controller in a design regardless their test hierarchy level
in the design.
Default Value
The default is Off.
Usage Conditions
• This option is only meaningful if used along with the-genConfigFile runtime options set to
SignOff.
• By default, when the -genConfigFile runtime option is set to SignOff, and the
-testLowerLevelControllers runtime option is not turned on, ETVerify generates a
configuration file that tests controllers present at the current level (core, block, or top) only
assuming that lower-level controllers are already tested by ETVerify in their respective
design workspace.
• For designs that have multiple test hierarchy levels, simulation of these additional tests
might take long time to complete.
Example
This example instructs ETVerify to generate a configuration file that tests all controller of the
design.
myDesignA -genConfigFile SignOff \
-testLowerLevelControllers On \
-tcmFile TOP.lvdb_preLayout/TOP.tcm
Related Information
-genConfigFile

September 2017
-tcmFile
-tcmFile
The -tcmFile option specifies the name of the test-connection map file to be used as input.
Syntax
-tcmFile <fileName>
also include the path information.
Default Value
The default is <designName>.tcm.
Usage Conditions
• The designExtract tool automatically creates the test connection map (.tcm) file.
• When used along with -inputLVDBName, the .tcm file is looked up in the LVDB ignoring
any path associated with the specified filename.
Example
This example instructs ETVerify to read the specified test connection map file,
myDesignA.tcm_sys rather than the default configuration file, myDesignA.tcm.
etv myDesignA -tcmFile myDesignA.tcm_sys
Related Information
-inputLVDBName

September 2017
-topHDLConfig
-topHDLConfig
The -topHDLConfig option accepts a VHDL configuration name to be used by the Verilog
testbench. Normally when ETVerify creates the Verilog testbench it binds the design to the
CHIP instance as follows:
<root_design_name> CHIP (...);
When this option is specified, the CHIP instance will use the provided configuration name as
follows:
<top_configuration_name> CHIP (...);
Syntax
-topHDLConfig <string>
Default Value
None
Usage Conditions
This property will be automatically added to the ETAssemble Makefile testbench target when
the TopLevelConfiguration property in the ETPlanner VhdlRtlFileList is specified.
Related Information
VhdlRtlFileList in the ETPlanner Tool
Reference

September 2017
-tstl
-tstl
The -tstl option specifies whether or not ETVerify generates TSTL2 (Toshiba Standard Tester
Language) format files for the tests specified in the configuration file to run on automatic test
equipment. There is a separate TSTL2 testdata file for each xxxVerify section in the
configuration file.
Syntax
-tstl On | (Off)
Default Value
The default is Off.
Usage Conditions
TSTL2 files are generated with the extension .tsl.
Example
This example instructs ETVerify to generate TSTL2 format files for the tests specified in the
configuration file to run on automatic test equipment. There is a separate TSTL2 testdata file for
each xxxVerify section in the configuration file.
etv myDesignA -tstl On
Related Information
None

September 2017
-userDefinedSequenceDir
-userDefinedSequenceDir
The -usedDefinedSequenceDir option specifies the name of the directory where you have
stored the sequences created during early verification. This option is used in combination with
the -createLVDB option. The user-defined sequences found within the specified directory will
be copied into the a sub-directory called UserDefinedSequences inside the LVDB directory.
They then are available for reference from the .etSignOff and .etManufacturing files.
Syntax
-userDefinedSequenceDir <pathName>
where pathName can be any identifier that is a valid operating system filename.
Default Value
None
Usage Conditions
You use this runtime option in combination with -createLVDB On.
Example
This example instructs ETVerify to collect the user-defined initialization sequences from the
directory ../topVerify/outDir/UserDefinedSequences.
etv myDesignA -createLVDB On -userDefinedSequenceDir
../topVerify/outDir/UserDefinedSequences
Related Information
-createLVDB UserDefinedSequence wrapper(s) in all
xxxVerify wrappers, except ScanVerify
UserDefinedSequence

September 2017
-userScanModelDir
-userScanModelDir
The -userScanModelDir option specifies the name of the directory where you have stored scan
models for scan test or logic BIST. The user scan models found within the specified directory
with the extension .scan will be copied into a sub-directory called UserScanModels inside the
LVDB directory.
Syntax
-userScanModelDir <directoryName>
where directoryName can be any identifier that is a valid operating system filename.
Default Value
None
Usage Conditions
You use this runtime option in combination with -createLVDB On.
Example
This example specifies to ETVerify the name of the directory where you have stored scan
models for scan test or logic BIST ../LVDB/UserDefinedSequences.
etv myDesignA -createLVDB On
-userScanModelDir ../LVDB/UserScanModels
Related Information
-createLVDB

September 2017
-useSVInterfacePortsFile
-useSVInterfacePortsFile
The -useSVInterfacePortsFile option specifies whether ETVerify should use the
.sv_interface_ports file in creating the test bench. This file, which is created by
DesignAssemble, provides a mapping of ports in the top module of the design to SystemVerilog
interface types when such types are used to define the ports. ETVerify uses this data to properly
instantiate the top module in the test bench using the necessary SystemVerilog syntax.
If the design that ETVerify sees is RTL, the .sv_interface_ports file should be used; otherwise,
the file should not be used. Normally ETVerify can make this decision without any user
intervention, in which case the -useSVInterfacePortsFile option is not needed. The decision is
based on the directory in which ETVerify is executed. If ETVerify is executed in the ETScan or
ETSignOff directory, the file is not used. If ETVerify is executed in the ETAssemble directory,
the file is used. Cases may occur when the directory in which ETVerify is executed is not
enough to determine whether the design is RTL. In such cases, you should use the
-useSVInterfacePortsFile option to override ETVerify’s decision.
Syntax
-useSVInterfacePortsFile On | Off
where the values are as follows:

• On — Enables the processing of the System Verilog interface ports. You should set the
option to On only if the design is RTL.
• Off — Disables the processing of the System Verilog interface ports. You should set the
option to Off when the design is gate-level.
Default Value
The default is On when ETVerify is executed in the ETAssemble directory and Off when
ETVerify is executed in the ETScan or ETSignOff directory.
Usage Conditions
None
Related Information
None

September 2017
-verificationFlow
-verificationFlow
The -verificationFlow option enables ETVerify to create a default configuration file if it does
not exist prior generation of test benches or patterns.
Syntax
-verificationFlow EarlyVer | PrepareSignOff | SignOff

• EarlyVer — instructs ETVerify to generate the configuration file during the Early
Verification in the ETASsemble Step on the block or top — <designName>.etEarlyVer file.
• PrepareSignOff — instructs ETVerify to generate the configuration file for scan-inserted
block sign-off — <designName>.etSignOff file.
• SignOff — instructs ETVerify to generate the configuration file for TOP or core sign-off in
the Final ETSignOff Step — <designName>.etSignOff.
Default Value
None
Usage Conditions
• Only one of the -configFile, -genConfigFile, -genManufacturingConfigFile, and
-verificationFlow options can be specified at a time.
• If the configuration file does not exist ETVerify creates the configuration file and uses the
generated file.
• If either the default or the specified configuration files already exist, ETVerify uses these
files and continues processing.
Example
In this example, ETVerify generates the configuration files, <designName>.etSignOff and
<designName>.etManufacturing, and performs verification in the Sign-Off Flow.
etv myDesignA -verificationFlow SignOff
Related Information
-configFile -genManufacturingConfigFile
-genConfigFile

September 2017
-verilog
-verilog
The -verilog option enables you to control whether or not ETVerify generates appropriate
Verilog simulation test benches named <patternName>.v.
Syntax
-verilog On | (Off)

• On—generates Verilog simulation test benches.
• Off—does not generate Verilog simulation test benches.
Default Value
The default value is Off. The ETVerify tool creates a pattern set in Mentor Graphics VIF format
and does not generate Verilog simulation test benches.
Usage Conditions
To use -verilog On, you must not set -svf to On.
Example
In this example, ETVerify creates Verilog simulation test benches.
etv myDesignA -verilog On
Related Information
-outDir -vif
-svf -wgl

September 2017
-vif
-vif
The -vif option specifies the name of the directory in which ETVerify stores the VIF
intermediate test patterns.
Syntax
-vif <directoryName>
where directoryName can be either a relative or an absolute pathname that is a valid operating
system character string.
Default Value
The default value is <designName>.vif.
Usage Conditions
• If you specify a directory that does not exist, the ETVerify tool creates the directory. If the
directory is already exists, and is compatible with the current design, the ETVerify tool
updates it. Otherwise, the existing directory is renamed with a .bak extension and a new VIF
directory is created.
• This option ignores the -outDir option.
Example
In this example, ETVerify creates the directory Default.vif, if it does not exist, and stores the
intermediate test bench patterns in Default.vif.
etv myDesignA -vif Default.vif
Related Information
-outDir -verilog
-svf -wgl

September 2017
-wgl
-wgl
The -wgl option controls whether or not ETVerify generates appropriate WGL format pattern
files.
Syntax
-wgl On | (Off)

• On—generates WGL format pattern files.
• Off—does not generate WGL format pattern files.
Default Value
The default value is Off. ETVerify creates a pattern set in Mentor Graphics VIF format and does
not generate WGL format files.
Usage Conditions
To use -wgl On, you must not set -svf to On.
Example
In this example, ETVerify creates WGL format files.
etv myDesignA -wgl On
Related Information
-exclude -verilog
-reportSimProgress -vif
-stil WGL
-svf

September 2017
Chapter 11
ETVerify Output File
This chapter describes the output files from the ETVerify tool, as follows:
ETVerify Output Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
ETVerify Output Overview

In a typical usage of the LV Flow, ETVerify is invoked in the following three steps that are
described in detail in the LV Flow User’s Manual:
• Step 3 ETAssemble (the ETAssemble directory)

• Step 4 ETScan and Pre-Layout ETSignOff (the ETScan directory)
• Step 5 Final ETSignOff (the ETSignOff directory)
The ETVerify tool is run numerous times in these three steps of the LV Flow and generates
various output files depending on which runtime options are used.
Table 11-1 provides the list of files generated by ETVerify along with their usage and the
context which triggers their generation.
The table is spitted into 3 sections which represent its 3 major usages:
• Configuration file generation

• Test bench/pattern generation
• LVDB generation
Table 11-1. ETVerify Output Files in Step 3: ETAssemble/Early Verification
This Output File... Description make targets (and Is Required

runtime/configuration options) Input for...
that trigger its generation
Configuration File Generation

September 2017
Table 11-1. ETVerify Output Files in Step 3: ETAssemble/Early Verification (cont.)

<designName> ETVerify make config_etEarlyVer in Generation of
.etEarlyVer configuration file ETAssemble Early
for Early Verification
Verification (-genConfigFile EarlyVer) simulation test
benches by
ETVerify
<designName> ETVerify make config_etSignOff in ETScan Generation of
.etSignOff configuration file or SignOff
for pre- and post- make config_etSignOff in Verification
layout SignOff ETSignOff *1 simulation test
Verification benches by
(-genConfigFile SignOff) ETVerify
<designName> ETVerify make config_etManufacturing in Generation of
.etManufacturing configuration file ETSignOff *2 manufacturing
for test patterns by
manufacturing (-genManufacturingConfigFile On) ETVerify
pattern
generation
<designName> Silicon Insight (-genETAConfigFile On) Real silicon
.config_eta configuration file Debug/Manufac
turing Testing
using Silicon
Insight
<designName> Template file of make config_etManufacturing in Generation of
.controllerStepAlgo an ETVerify ETSignOff *2 *3 manufacturing
Selection_tpl configuration file test patterns by
for the selection (-genManufacturingConfigFile On) ETVerify
of
soft-coded
algorithms for
Tessent
MemoryBIST
SoftProgrammab
le controllers

September 2017

<designName>.pin Template of a pin (-genPinMapFile On) Real silicon
map_tpl mapping file. Debug/Manufac
This file can be turing Testing
used to using Silicon
customize the Insight
mapping between
the Design pin
names and
tester’s pin
names and
specifies
conditions
external to the
DUT such as pull
resistors and
loopbacks
<designName> Physical make config_etEarlyVer in Generation of
.jtag_phy constraints file ETAssemble IEEE 1149.1
describing enable make config_etSignOff in ETScan and 1149.6
grouping and or Boundary scan
port polarity make config_etSignOff in tests test
ETSignOff *1 benches and
patterns by
(-genConfigFile EarlyVer) ETVerify
(-genConfigFile SignOff)
<designName> Configuration make config_etEarlyVer in Generation of
.loadboard_info_tpl files describing ETAssemble IEEE 1149.1
the contacted pin make config_etSignOff in ETScan and 1149.6
properties or Boundary scan
and the DUT make config_etSignOff in tests test
card ETSignOff *1 benches and
configuration. patterns by
(-genConfigFile EarlyVer) ETVerify
README_etv Help on how to make config_etSignOff in ETScan n/a
customize or
configuration make config_etSignOff in
.etEarlyVer and ETSignOff *1
.etSignOff files

September 2017

Test Bench/Pattern Generation
<patternName>.v Serial-loading or make testbench in ETAssemble Verilog
parallel-loading make testbench in ETScan simulation
Verilog test make testbench in ETSignOff
bench
(-verilog On)
<patternName>.stil Serial-loading (-stil On) STIL
STIL test bench simulation
<designName>.vif VIF database to make testbench in ETAssemble Verilog and
store patterns in make testbench in ETScan WGL generator
intermediate make testbench in ETSignOff
form (-vif On)
<patternName>_D DUT simulation make testbench in ETAssemble Verilog
UT card model make testbench in ETScan simulation
.vb located in the make testbench in ETSignOff
output directory.
This model (ExternalPullUps: On;)
instantiates the (UseAsyncClocks: On;)
circuit-under-test (UseDUTLoopBacks: On)
and contains the (CustomVerify {
external pull-up MonitorClocks {)
and external pull-
down
specifications for
the required
output or
bidirectional
pins.
<patternName> Verilog module make testbench in ETAssemble Verilog
_ClockMon.vb and tasks make testbench in ETScan simulation
definition for make testbench in ETSignOff
Clock
Monitoring (CustomVerify {
MonitorClocks {)
(MembistVerify)
(MembistPVerify)
(LogicbistVerify)
(ScanVerify)

September 2017

<designName> Ordered list of make patterns in ETSignOff *2 Real silicon
.TestProgramSeque pattern routines Manufacturing
nce which must be (-wgl On) Testing using
invoked by the (-tstl On) ATE equipment
test program
<designName> Simulation script make testbench in ETAssemble Verilog
_sim.script called by make testbench in ETScan simulation
Makefiles that make testbench in ETSignOff
can run test
benches with
different
simulators
<designName> HSDL definition make testbench in ETAssemble *4 Generation of
.hsdl_ebscan of block or make testbench in ETScan *4 IEEE 1149.1
ELTCore with make testbench in ETSignOff *4 scan tests a
embedded block/ELTCore
boundary scan (JtagVerify { with an
registers LVBScanFile: <fileName>;) embedded
Boundary scan
register
<designName> Verilog source (-svf) Verilog
.sdf_annotate file used to load simulation with
SDF files upon timing (sdf)
definition of the back annotation
parameter
LVS_SDF_ANN
OTATE

September 2017

LVDB Generation
LVDB/LVDB.info Encrypted file make lvdb_preLayout in Real silicon
with basic ETAssemble *1 Debug/Manufac
information make lvdb_preLayout in ETScan turing Testing
about the make lvdb_final in ETSignOff *2 using Silicon
generated LVDB Insight
(-createLVDB On)
LVDB/ETA.info Encrypted file make lvdb_preLayout in Real silicon
containing test ETAssemble *1 Debug/Manufac
configuration make lvdb_preLayout in ETScan turing Testing
of the design make lvdb_final in ETSignOff *2 using Silicon
that is used by Insight
Silicon Insight. (-createLVDB On)
Among others,
it contains the
information
required to
support
parameterized
Tessent
MemoryBIST
soft-coded
algorithms
LVDB/default.confi The default make lvdb_final in ETSignOff *2 Real silicon
g_eta configuration Debug/Manufac
(encrypted) file (-createLVDB On) turing Testing
for Silicon using Silicon
Insight Insight
LVDB/ETA.defaults Default settings make lvdb_final in ETSignOff *2 Real silicon
of each controller Debug/Manufac
in the design (-createLVDB On) turing Testing
using Silicon
Insight

September 2017

LVDB/<designNam Template of a pin make lvdb_final in ETSignOff *2 Real silicon
e> mapping file. Debug/Manufac
.pinmap_tpl This file can be (-createLVDB On) turing Testing
used to using Silicon
customize the Insight
mapping between
the Design pin
names and a
tester’s pin
names and
specifies
conditions
external to the
DUTs such as
pull resistors and
loopbacks.
LVDB/<designNam Template of a pin make lvdb_final in ETSignOff *2 Real silicon
e> mapping file that Debug/Manufac
.pinmap_tpl_tap includes only the (-createLVDB On) turing Testing
TAP controller using Silicon
pins. This file Insight
can be used to
customize the
mapping between
the Design pin
names and a
tester’s pin
names and
specifies
conditions
external to the
DUTs such as
pull resistors and
loopbacks
*1 When Scan Insertion is not part of the LV Flow
*2 Only for TOP level (excludes cores and block modules)
*3 When the circuit contains Tessent MemoryBIST SoftProgrammable controllers with soft-
coded algorithms
*4 When the design contains embedded boundary scan register

September 2017

September 2017
Appendix A
Reference ETVerify Configuration File
Syntax
This appendix describes in detail all wrappers and properties available for the ETVerify input
files in alphabetic order.
Appendix topics follow this sequence:
Reference for ETVerify Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

ActiveControlCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
AddressGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
AddressRegister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
AlgorithmPhase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
AlgorithmSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
ApplyTCKClockCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
AsyncSetResetTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
AutonomousOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
BasePeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
BisrChainRotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
BisrChainSelect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
BisrFlushTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
BisrLoadAndRotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
BistEn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
BondingOption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
BsdlFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
BurstClockController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
BurstCyclesWithShiftClock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
BypassOpCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
CaptureBisrChain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
CaptureMeasurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
CellCompares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
CellSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
ChainBypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
ChannelSelect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
CheckRepairNeeded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
CheckRepairStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
ClockInput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
ClockPeriod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
ClockPeriods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
ClockPeriodsDividers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

September 2017
Reference ETVerify Configuration File Syntax
ClockSourceOverride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Collar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
CompareCmpStat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
CompareDiagDataToZero. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
CompareGo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
CompareGoID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
CompareHardCodedSignature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
CompareMISR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
ComparisonToLimits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CompareStrobeCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
CompStatIDSelect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
ContactedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
CPUActionsFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
CPUReadWriteSetupTasksFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
CPUVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
CustomVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
DataBitNo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
DataCompareTimeSlots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
DataGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
DebugMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
DefineClock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
DesignPin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
DeviceId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
DisableCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
DisableClocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
DisableMemoryList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
DRStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
DUTLoopBacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
EffectiveSlowedDownFrequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
EnableBiraCapture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
EndVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
ETACompareCmpStat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
ETATestGroupName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
ExpectedROMSignature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
ExpectedStrobeCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
ExternalPullUps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
ExtractRepairFuseMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
FailureLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
FastScanVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
FlattenLoops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
FlushTest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
ForceBidir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

September 2017
ForceDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
ForceVoltage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
FreezeStep. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
FreezeStepNumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
FreezeTestPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
FreezeTestPortNumber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
FreqRatioRelToSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
FuseBoxAccessOperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
FuseBoxReadAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
FuseBoxReadAddressMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
FuseBoxReadAddressMin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
FuseBoxWriteAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
FuseBoxWriteDuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
GlobalPadDecayTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
HardCodedAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
IgnoredVectorNum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
IncludeAllNonPowerPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
IncludeAllPowerPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
IncludeTapInit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
IncrementFailureLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
InhibitFuseBoxProgramming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
InitialWaitCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
InhibitTapAsyncReset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
InjectErrors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
InternalCellSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
InvertDataWithColumnBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
InvertDataWithRowBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
IRStatus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
JtagVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
JTAPAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
LeakageNCOptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
LeakageNumberOfCycles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
LeakageLogicLevel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
LoadBankAddress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
LoadBoardInfoFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
LoadBoardInfoFileForPinMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
LoadColumnAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
LoadCounterA_EndCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
LoadCounterA_StartCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
LoadExpectData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
LoadRowAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
LoadWriteData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
LockTimePause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
LogicbistVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
LogicLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

September 2017
LoopbackDurationInWordClockCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
LowerELTIscanInitCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
LowerLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
LVBScanFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
MaskedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
MaxLoopCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
MaxRepairCount. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
MeasurementEdge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
MeasurementLimits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
MemBistController . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
MembistPVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
MembistVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
MemoryReset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
MISRCompares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
MonitorClocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
NoCheckerBoard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
NumberOfCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
OperationSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
PadDecayTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
ParallelLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
ParallelRetentionGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
ParallelRetentionTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
ParallelRetentionTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
PatternDBFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
PatternName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
PatternSetID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Pause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
PersistentBISTInputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
PhysicalConstraintFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
PhysicalRegion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
PinComments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
PinCompares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
PinInv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
PinSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
PostAmble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
PostTAPUserDefinedSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
PostTestUserDefinedSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
PowerDomainGroupLabels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
PowerLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
PreserveFuseRegisterValues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
PreAmble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

September 2017
PreTAPUserDefinedSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
PullResistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
ReducedAddressCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
RetentionTime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
RPAChannelEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
RunLength. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
RunMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
RunTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
RunTimeRefreshEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
RunTimeRefreshInterval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
SanityCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
ScanVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
SdfAnnotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
SdfFiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
SelectLibraryAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
SerdesVerify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
SerdesTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
SetBisrChain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
SetBisrChainExpected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
SetupChainRegister. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
SetupRate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
ShiftClkSelect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
ShiftClockController. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
ShiftClockSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
SignalToMeasure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
SimulationModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
SimulationScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
SimulationTimePrecision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
SimulationTimeUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
SpareElementPriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
SlowedDownBurstCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
StartVector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
SplitPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
StilVectorFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
SurfaceProportion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
SVFFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
SVFName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
TCKPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
TCKRatio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
TestBenchModuleName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
TestClockSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
TestDurationInBeatCycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
TestEndRefreshEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
TestEndRefreshInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560

September 2017
Reference for ETVerify Syntax
TestPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
TestStep. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
TestTimeMultiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
TogglePattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
TPGChannelEnable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
TriStateEnableNCOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
UnderSamplingClkRatio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
UpperLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
UseAsyncClocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
UseChildBisrEmulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
UseDUTLoopBacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
UserBitAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
UserDefinedSequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
UserDRBit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
UserIRBit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
WGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
WTAPSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
WTAPVerify. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Reference for ETVerify Syntax

The following sections provide detailed descriptions for all available wrappers and properties of
the ETVerify configuration file in alphabetic order.
Note the following:
• Some of the described wrappers and properties are generic for most of types of verification,
and some of them are specific for particular types of verification. Refer to the “Usage
Conditions” sections of the following reference pages.
• + denotes that a particular usage condition is applied to a specific verification type, such as
memory BIST, logic BIST, and so on.
• All cross-references are marked in Blue.

September 2017
ActiveControlCells
ActiveControlCells
The ActiveControlCells property specifies the number of enable boundary-scan cells that can be
active simultaneously during the clamp and output tests.
Syntax
ActiveControlCells: <n>;
where n is any integer that represents the number of enable boundary-scan cells that can be
activated simultaneously.
Default Value
The default is 0.
Usage Conditions
This property is used in the JtagVerify wrapper.
• This property affects only the clamp and output tests.
• A large value generates a shorter overall test. However, you can diagnose problems with the
enable-control cells easily when each cell is tested independently.
• To create the shortest clamp and output tests, specify a value greater than or equal to the
actual number of enable-control boundary-scan cells in the chip-level netlist.
• To reduce the noise of simultaneous-switching outputs created by test fixtures and package
inductances, use a value of 1.
• If the EnableGroup wrapper definition in the physical constraints file (.jtag_phy) is larger
than the value you specify for ActiveControlCells, ETVerify generates a new .jtag_phy file,
distributing the enable cells into recalculated enable groups according to the
ActiveControlCells setting. For example, if you specify ActiveControlCells: 3, and the
.jtag_phy file has one enable group with four enable cells, all enable groups are removed
and recreated with a size of 3.
Example
This example instructs ETVerify to generate a clamp and output tests that have a maximum of
four enable-control cells active.
etv (MyDesignA) {
JtagVerify (1) {
ActiveControlCells: 4;
}
}
Related Information
JtagVerify EnableGroup

September 2017
AddressGenerator
AddressGenerator
The AddressGenerator sub-wrapper groups the properties of the address generator that require
initialization prior to execution of the microprogram. The AddressGenerator sub-wrapper
consists of two possible wrappers:
• AddressRegister(A) sub-wrapper
• AddressRegister(B) sub-wrapper
For more information, see the appendix Functional Debug Memory Access in the Tessent
MemoryBIST User’s and Reference Manual.
Syntax
Figure A-1 provides the complete syntax for the AddressGenerator wrapper.
Figure A-1. AddressGenerator Wrapper Syntax
AddressGenerator {
AddressRegister (A|B) {
}
.
. // Repeat for AddressRegister(A|B)
.
}//end of AddressGenerator sub-wrapper
This wrapper consists of several properties that allow you to specify the following:
• Starting count range values of Bank Address
• Starting count range values of Row Address
• Starting count range values of Column Address
Usage Conditions
This property is used in the MembistPVerify:TestStep:Controller wrapper.
• The Controller:DebugMode property must be enabled.
• The FunctionalDebugMode property must be enabled in ETPlanner.
Related Information
MembistPVerify TestStep
Controller Functional Debug Memory Access in the
Tessent MemoryBIST User’s and Reference
Manual
FunctionalDebugMode DebugMode

September 2017
AddressRegister
AddressRegister
The AddressRegister sub-wrapper in the AddressGenerator wrapper groups the properties of
the named address register. The AddressRegister sub-wrapper consists of properties that allow
you to specify the following:
• Initialization of the BankAddress
• Initialization of the RowAddress
• Initialization of the ColumnAddress
Two address registers, AddressRegister(A) and AddressRegister(B), are available in the
Programmable Memory BIST architecture. Each address register represents a counter
generating addresses during execution of Programmable Memory BIST. One or both of these
AddressRegisters may be specified in the AddressGenerator wrapper.
Syntax A
Syntax A represents the AddressRegister(A) sub-wrapper and begins with the following:
AddressRegister(A) {
Syntax B
Syntax B represents the AddressRegister(B) sub-wrapper and begins with the following:
AddressRegister(B) {
Figure A-2 provides the complete syntax for the AddressRegister wrapper.
Figure A-2. AddressRegister Wrapper Syntax
AddressRegister (A|B) {
}
.
. // Repeat for AddressRegister(A|B)
.
.
Usage Conditions
This wrapper is used inside the MembistPVerify:TestStep:Controller:AddressGenerator
wrapper.
Related Information

September 2017
AddressRegister

Manual

September 2017
AlgorithmPhase
AlgorithmPhase
The AlgorithmPhase property specifies whether the memory BIST controller applies to all
phases of the specified algorithm or only one of three possible sub-phases. This property
provides support for parallel static retention testing.
Syntax
AlgorithmPhase: StartToPause | PauseToPause |
PauseToEnd | (AllPhases);

• StartToPause — indicates that the controller is to apply only the portion of the selected
algorithm that ends at the first static retention test pause. This property value corresponds to
the application of the checkerboard pattern.
• PauseToPause — indicates that the controller is to apply only the portion of the selected
algorithm that runs from the first static retention pause to the second static retention test
pause. This property value corresponds to the application of the inverse checkerboard
pattern.
• PauseToEnd — indicates that the controller is to apply only the portion of the selected
algorithm that runs from the second static retention pause and onward.
• AllPhases — indicates that the controller is to apply the entire selected algorithm.
Default Value
The default is AllPhases.
Usage Conditions
This property is used in the TestStep: Controller wrapper of the following wrappers:
• MembistVerify
• MembistPVerify
• This property is valid only if you set the ETPlanner property ParallelRetentionTest to Yes or
PerGroup.
• Use the Pause property to specify the duration of a static retention pause.
• When there are multiple controllers, parallel retention testing can be performed sequentially
on groups of controllers. This mode of parallel retention testing can be enabled using the
ParallelRetentionTest property.
• The RunMode property must be set to HWDefault.
• If you want to generate a retention test for a subset of the algorithm phases then the
ParallelRetentionTest property must be set to Off in the TestStep wrapper. This property
will be ignored when ParallelRetentionTest is set to On.

September 2017
AlgorithmPhase
Example
The following syntax specifies that the controller applies only the first algorithm sub-phase.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
ParallelRetentionTest: Off;
Controller (SAMPLE) {
AlgorithmPhase: StartToPause;
}
}
}
}
Related Information
Controller Pause
MembistPVerify RunMode
MembistVerify TestStep
ParallelRetentionTest ParallelRetentionTest in the manual

September 2017
AlgorithmSummary
AlgorithmSummary
The AlgorithmSummary property enables you to specify whether a brief or detailed algorithm
summary is generated in the .log file.
Syntax
AlgorithmSummary: On | (Off);

• On — generates a detailed summary of the default algorithm in the .log file.
• Off — generates only a brief summary of the default algorithm in the .log file.
Default Value
The default is Off.
Usage Conditions
This property is used in the MembistPVerify wrapper.
Example
This example specifies to ETVerify that the execution of ETVerify provides a detailed summary
of the programmed default algorithm.
etv (MyDesignA) {
MembistPVerify (1) {
AlgorithmSummary: On;
}
}
Related Information
MembistPVerify -log

September 2017
ApplyTCKClockCycles
ApplyTCKClockCycles
The ApplyTCKClockCycles property enables you to specify the number of TCK clock cycles
to run:
• Before running the logicTest controllers
• In a UserDefinedSequence: TestStep wrapper
Syntax
where cycles is an integer that specifies the number of TCK clock cycles.
Default Value
This property defaults to 0.
Usage Conditions
This property is used in the following wrappers:
• UserDefinedSequence: TestStep
• LogicbistVerify
• ScanVerify
Example
This example specifies to ETVerify that there are to be 5 TCK clock cycles after the specified
PinSettings have been applied.
etv (MyDesignA) {
UserDefinedSequence (MyUDS) {
TestStep (0) {
PinSettings {
DIN[0]: 0;
}
ApplyTCKClockCycles: 5;
}
}
}
Related Information
UserDefinedSequence: TestStep ScanVerify
LogicbistVerify

September 2017
AsyncSetResetTest
AsyncSetResetTest
The AsyncSetResetTest property enables you to control the generation of the asynchronous
reset or set test sequence. This test sequence covers new possible faults that are present in the
logic fanning into the asynchronous set or reset signals on the flip-flops of the design.
Syntax
AsyncSetResetTest: On | (Off);

• On — turns on the asynchronous reset or set test.
• Off — turns off the asynchronous reset or set test.
Default Value
Usage Conditions
This property is used in the ScanVerify: Controller wrapper.
As soon as either AsyncSetResetTest, or FlushTest, or RetentionTime is present in a
ScanVerify: Controller wrapper, these tests are the only ones that are generated for the
controller. Any other property, other than the AsyncSetResetTest, FlushTest, and
RetentionTime properties, has no effect.
Example
This example specifies that the reset/set test to be applied.
etv (MyDesignA) {
ScanVerify (ETC) {
TestStep (3) {
Controller (controllerName) {
AsyncSetResetTest: On;
}
}
}
}
Related Information
Controller RetentionTime
FlushTest ScanVerify

September 2017
AutonomousOperation
AutonomousOperation
The AutonomousOperation property is used when the RunMode: Autonomous is specified.
This property is used with a BISR loader controller only. The BISR loader controller supports
the following autonomous operation modes:
• PowerUpEmulation
• VerifyFuseBox
• SelfFuseBoxProgram
• ClearBisrChain
Syntax
AutonomousOperation: (PowerUpEmulation) | VerifyFuseBox |
SelfFuseBoxProgram | ClearBisrChain;

• PowerUpEmulation — simulates a power-up event. During this mode, the BISR controller
calculates the BISR chain length and decompresses the repair information from the fuse box
into the BISR chain. Typically, this mode is used when accessing the chip through the TAP
interface.
• VerifyFuseBox — verifies the content of the fuse box against the content of the BISR chain.
The BISR chain is rotated as the content of the fuse box is decompressed. The BISR
controller GO signal goes high at the end of the test if the decompressed data from the fuse
box matches the content of the BISR chain.
• SelfFuseBoxProgram — when the BISR chain contains the repair information for all
memories, BISR loader controller rotates the BISR chain, compresses its content, and writes
it to the fuse box. If the GO and DONE signals of the BISR loader controller are high when
the test step completes, the initial BISR chain content is preserved.
• ClearBisrChain — initializes all flip-flops in the BISR chain without calculating its length.
This enables quick initialization of the memory repair inputs when performing memory
BIST verification.
Default Value
The default value is PowerUpEmulation.
Usage Conditions
This property is used in the TestStep: Controller wrapper of the following verification
wrappers:
• MembistVerify
• MembistPVerify
The RunMode property must be set to Autonomous.

September 2017
AutonomousOperation
Example
This example shows how to generate a test bench that simulates a power-up emulation.
MembistPVerify (TOP) {
TestStep (Step0) {
RunMode: Autonomous;
Controller (TOP_LVISION_FUSE_BOX_CTRL) {
AutonomousOperation: PowerUpEmulation;
}
}
}
Related Information
Controller RunMode
MembistVerify

September 2017
BasePeriod
BasePeriod
The BasePeriod property allows the creation of simulation test benches with asynchronous
clocking where, instead of specifying the various clocks by their period directly (in a
ClockPeriods wrapper), they are generated by deriving their final periods from the BasePeriod
multiplied by an integer value specified in the ClockPeriodsDividers wrapper.
Clocks that exhibit this behavior are generated by multiplying a reference clock using PLLs
(Phase Lock Loops). For example, with a pair of PLLs that each multiply a common base
frequency of 100kHz by 1000 and 1001, then the output of the two PLLs are guaranteed to be
perfectly every time one period of the input base frequency has elapsed (10us).
Syntax
BasePeriod: <time>;
where time is a real value optionally followed by a suffix which is a scaling factor like s
(seconds), ms (milliseconds), us (microseconds), ns (nanoseconds), ps (picoseconds). When the
suffix is absent, then the real value is interpreted in ns.
Default Value
This property has no effect if it is not specified.
Usage Conditions
This property is used in the SerdesVerify wrapper
• This property is taken into consideration only if the UseAsyncClocks property is set to On.
• When BasePeriod is specified, then the ClockPeriods wrapper content is ignored, and the
ClockPeriodsDividers wrapper content is used instead. An error message is generated when
this wrapper is empty or unspecified with a valid BasePeriod being specified.
Example
The following example shows how to apply two asynchronous clocks to top level pins, CLK1
and CLK2, derived from a BasePeriod of 10us and dividers of 1000 and 1001 respectively:
UseAsyncClocks: On;
DefineClock (P): CLK1;
DefineClock (P): CLK2;
BasePeriod:10us;
ClockPeriodsDividers {
CLK1: 1000;
CLK2: 1001;
}
Related Information
ClockPeriods UseAsyncClocks

September 2017
BasePeriod
ClockPeriodsDividers SerdesVerify

September 2017
BisrChainRotate
BisrChainRotate
The BisrChainRotate property instructs the BISR controller to enable the BISR chain rotation.
When set to On, BISR_SI of the BISR scan is driven by the BISR_SO port of the last BISR
chain. When BisrChainRotate is set to Off, the BISR_SI port of the BISR chain is driven by the
JTAP TDI input port. This allows you to scan in the values for all the BISR registers from the
JTAP TDI port.
The BISR chain rotation is generally used to transfer the repair information from the external
BISR register to the internal BISR register of memories with serial BISR interface. The BISR
chain rotation can also be used to monitor the content of the BISR registers on the JTAP TDO
output port while preserving their initial content.
Syntax
BisrChainRotate: On | (Off);
where the valid value are as follows:

• On—indicates that the BISR chain rotation is enabled.
• Off—indicates that the BISR chain rotation is disabled.
Default Value
The default expected value is Off.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
Example
This example instructs the BISR controller to scan out the internal BISR registers and perform a
complete rotation of the BISR chain. Note that the example uses the BisrChainSelect property
set to Internal in combination with BisrChainRotate set to On. This has the effect of
transferring the content of the internal BISR register of memories with serial BISR interfaces to
the external BISR register. If BisrChainSelect was set to External, the content of the external
BISR register would be transferred to the internal BISR registers.
TestStep (Step0) {
RunMode: BisrChainAccess;
BisrChainRotate: On;
BisrChainSelect: Internal;
}
}
}

September 2017
BisrChainRotate
Related Information
BisrChainSelect MembistVerify
Controller TestStep
MembistPVerify

September 2017
BisrChainSelect
BisrChainSelect
The BisrChainSelect property selects which of the internal or external BISR register of
memories with serial BISR interface will be scanned out during BISR scan chain access. The
BISR chain length is not affected by the value of the BisrChainSelect property.
Note
The BisrChainSelect property has no effect for a memory with either:
a) A parallel BISR interface; the external BISR register is always selected during a BISR
chain access because no internal BISR register exists.
b) A serial BISR interface but no shift out port; the external BISR register is always
selected because the internal BISR register cannot be extracted.
Syntax
BisrChainSelect: Internal | (External);
where the valid value are as follows:

• Internal—selects the internal BISR register of memories with a serial BISR interface.
• External—selects the external BISR register of memories with a serial BISR interface.
Default Value
The default value is External.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
Example
This example instructs the BISR controller to scan out the internal BISR registers. Note that the
example uses the BisrChainSelect property set to Internal in combination with
BisrChainRotate set to On. This has the effect of transferring the content of the internal BISR
register to the external BISR register of memories with a serial BISR interface. If
BisrChainSelect was instead set to External, the content of the external BISR register would be
transferred to the internal BISR register. This property determines which BISR register will be
sampled on the TAP TDO pin when executing a BisrChainAccess test step.
TestStep (Step0) {
BisrChainSelect: Internal;

September 2017
BisrChainSelect
}
}
}
Related Information
BisrChainRotate MembistVerify
Controller TestStep
MembistPVerify

September 2017
BisrFlushTest
BisrFlushTest
The BisrFlushTest property is used to generate a BISR chain verification test bench for a
memory assembly that contains repairable memories with BISR modules. This property is used
to verify the BISR chain for an assembly module, a core or a block module. The BISR chain
verification includes testing of the reset, the BISR chain length, and the shifting functionality of
the BISR chain. The BISR chain ports must be accessible at the top of the module to perform
the BISR chain verification.
Syntax
BisrFlushTest: On| (Off);

• On—enables the BISR chain verification test bench.
• Off—disables the BISR chain verification test bench.
Default Value
Usage Conditions
This property is used in the CustomVerify wrapper of the ETVerify configuration file.
These usage conditions apply to this property:
• The BisrFlushTest property is used when verifying a memory BIST assembly module. This
property cannot be used at the chip level since the BISR chain ports are connected to the
Fuse Box Controller and are not available as top-level ports.
• This property is used with memory BIST controllers that have memory interfaces with self-
repair capability. Memories with self-repair capability have the MemBistCollarOptions:
DisableSelfRepair set to No in the .etplan File
Example
This example instructs etVerify to create a BISR chain verification test bench for
MBIST1_ASSEMBLY module.
CustomVerify (MBIST1_ASSEMBLY) {
PatternName: MBIST1_ASSEMBLY;
SimulationScript: MBIST1_ASSEMBLY_sim.script;
TCKPeriod: 100.0ns;
UseAsyncClocks: On;
BisrFlushTest: On;
}
Related Information
CustomVerify Custom Verification Section

September 2017
BisrFlushTest
MemBistCollarOptions “Implementing and Verifying Memory

DisableSelfRepair in the manual ETPlanner Repair” in the Tessent MemoryBIST User’s
Tool Reference and Reference Manual

September 2017
BisrLoadAndRotate
BisrLoadAndRotate
The BisrLoadAndRotate property is used to perform BISR verification at the block or memory
BIST assembly level. A pattern will be created to capture the BIRA output value into the BISR
register and then apply enough clock cycle to rotate the values through the entire chains such
that they end up back in the same place in the BISR register.
The rotation serves two purposes:
1. Verifies the BISR chain actually match the computed length and that its shift mode
operates correctly
2. Allows loading the Serial BISR register found in some repairable memories such as
those from TSMC
Syntax
BisrLoadAndRotate: On | (Off);

• On—specifies that you want the BISR Load and Rotate patterns to be created.
• Off—specifies that you do not want the BISR Load and Rotate patterns to be created.
Default Value
Usage Conditions
This property is used in the TestStep wrapper of the following xxxVerify wrappers:
• MembistPVerify
• MembistVerify
• You use this property to create a test bench at the block or memory BIST assembly level to
verify that your BIRA specification matches the redundancy scheme of your memory.
• You put a TestStep above it where you run memory BIST to compute the BIRA solution,
and you put a TestStep after it to rerun memory BIST to see that the BIRA solution fixed
the fault you inserted into the memory.
• The .etEarlyVer file created for each memory BIST assembly module contains a description
of this method in details.
Example
This example uses the BisrLoadAndRotate property in the middle TestStep to perform BIRA
validation using fault insertion. This example reflects the test method automatically generated
in the .etEarlyVer file created for each memory BIST assemble in the ETAssemble directory.
MembistVerify (Block3_ck_MBIST2_assembly_P1) {

September 2017
BisrLoadAndRotate
PatternName: membistv_P1_ck_MBIST2_assembly;
SimulationScript: Block3_ck_MBIST2_assembly_sim.script;
SetupRate: TCK;
TestClockSource: Functional; // BIST_CLK
ClockPeriod: 10.0ns;
TCKRatio: 16;
// A loopback connection between the BISR_SO and BISR_SI is created in the

// DUT model. The BISR chain loopback is used to transfer the content from
// the BISR chain to the memory repair register chains in the
// BiraToBisr_Rotate test step.
//
UseDUTLoopBacks: On;
DUTLoopBacks {
BISR_SI <= BISR_SO;
}
// The Default_PreRepair test step runs memory Bist on memories with

// fault insertion. CompareGo is disabled because it is expected that
// the GO will be low during this test step.
// The CheckRepairStatus is enabled. The following table describes the
// repair status codes that are scanned out at the end of this test
// step:
//
// STATUS[1:0] Memory status
// ----------- -------------
// 00 No Repair needed (No failures detected)
// 01 Repairable
// 1X Non-Repairable
TestStep (Default_PreRepair) {
RunMode: RunTimeProg;
Controller (DP0) { //Block3_ck_MBIST2_cntrl
ExtractRepairFuseMap: Off;
CheckRepairStatus: On;
CompareGoID: On;
CompareGo: Off;
ReducedAddressCount: Off;
}
}
// This test step captures the BIRA solution inside the BISR registers.
// The BISR chain is then rotated. The BISR chain rotation is used
// to transfer the content of the BISR chain into the repair register
// chain of the memories with a serial BISR interface.
// Once this test step completes, the next test step (Default) will
// run memory Bist on the repaired memories. If all memories were
// declared as repairable during the Default_PreRepair test step,
// the Default test step should execute without any compare failures
// on the GO and DONE signals.
TestStep (BiraToBisr_Rotate) {
BisrLoadAndRotate : On;
}
TestStep ( Default ) {
Controller ( DP0 ) { //Block3_ck_MBIST2_cntrl
ReducedAddressCount : Off;
CompareCmpStat : Off;

September 2017
BisrLoadAndRotate
}
}
}
Related Information
MembistVerify

September 2017
BistEn
BistEn
The BistEn property is a WTAP-specific property. This property enables you either to enable or
to disable WTAP output port bistEn(n). This property is intended to be used to start any third-
party embedded test controller in Go/NoGo mode that is connected to this bistEn(n) port.
Syntax
BistEn (#): On | Off;
where valid values for the BistEn property are as follows:

• # — specifies a WTAP output port bistEn(n).
• On — enables WTAP output port bistEn(n).
• Off — disables WTAP output port bistEn(n).
Figure A-3 shows the BistEn property in the WTAPSettings wrapper in the ETVerify
configuration file:
Figure A-3. UserDefinedSequence Wrapper for WTAP Verification
UserDefinedSequence (<sequenceName>) {
TestStep (<stepName>) {// Repeatable
...
WTAPSettings (<moduleName> | DP# | BP#) {
// Repeatable
UserIRBit#: On | Off;
UserIRBitAlias (<aliasName>):
<binaryNumber>;
BistEn (#): On | Off;
}
}
}
}
Default Value
None
Usage Conditions
This property is used in the WTAPSettings wrapper.

September 2017
BistEn
• The status of the bistEn(n) port that connects a third-party embedded test controller in
go/nogo mode is read by IRStatus.
• Inside the UserDefinedSequence: TestStep wrapper, this property is TAP-specific.
• Inside the UserDefinedSequence: TestStep: WTAPSettings wrapper, this property is the
WTAP-specific.
Example
The following syntax specifies to ETVerify to disable the third-party embedded test controller
that is connected through the port bistEn(1).
etv (MyDesignA) {
UserDefinedSequence {
TestStep (0) {
WTAPSettings (BP0) {
BistEn(1): Off;
}
}
}
}
Related Information
UserDefinedSequence WTAPSettings
TestStep IRStatus

September 2017
BondingOption
BondingOption
The BondingOption property defines the bonding option to which the JtagVerify wrapper
belongs. The property selects bonding option-specific information from the .tcm (Test
Connection Map) file. ETVerify creates a test bench and test vectors for each bonding option.
Syntax
BondingOption: <BondingOptionName>;
where BondingOptionName is the name defined in the ETAssemble configuration file’s

BondingOption wrapper.
Default Value
None
Usage Conditions
• This property is used once per JtagVerify wrapper, each with a unique name.
• Each bonding option has its own physical constraint and ETVerify loadboard information
file.
• The JtagVerify wrapper is defined in the form <DesignName>_<BondingOptionName>.
• The PatternName property, which is specified along with each BondingOption property, is
defined in the form <PatternName>_<BondingOptionName>. The PatternName property
defines the file name of the created test benches and test vectors.
Example
The following example contains three JtagVerify sections that correspond to the three different
package options illustrated in the BondingOption wrapper’s example in ETAssemble Tool
Reference.
etv (myChip) {
JtagVerify (myChip_default) {
BondingOption: default;
PatternName: tapbistv_default;
...
}
JtagVerify (myChip_package1) {
BondingOption: package1;
PatternName: tapbistv_package1;
...
}
JtagVerify (myChip_package2) {
BondingOption: package2;
PatternName: tapbistv_package2;
...

September 2017
BondingOption
}
}
Related Information
BondingOption wrapper in ETAssemble Tool .tcm Files in ETAnalysis Tools Reference
Reference

September 2017
BsdlFile
BsdlFile
The BsdlFile property specifies a third-party BSDL file to hand off to ETVerify to create a
simulation test bench and/or a test pattern based on the information contained in the specified
third-party BSDL file.
Syntax
BsdlFile : <path_to_user_BSDL_file>;
where path_to_user_BSDL_file is the path to and name of the third-party BSDL file.
Default Value
None
Usage Conditions
• The BsdlFile property specifies a path to the BSDL file that provides the design’s boundary-
scan information to ETVerify when generating the JtagVerify test patterns. This property is
primarily used in BSDL-only verification flows when boundary-scan insertion and BSDL
file creation were done previously with a third-party tool.
• In the BSDL-only flow, ETVerify reads only the following file(s):
o Your 3rd-party BSDL file
o The optional Physical Constraints File
o The optional LoadBoardInfoFile file
If a file named yourDesign.tcm exists in the same directory where you run ETVerify, the
tool picks up the file and expects to find all the other files produced by the standard
ETBscan flow. In such a context, the BsdlFile property only overrides the location of the
input BSDL file.
• The BSDL-only flow is supported for both 1149.1 and 1149.6. The only difference from the
1149.1 setup is the addition of 1149.6-related tests that can be performed and should be
listed in the ETVerify configuration file as follows:
//
// 1149.6 I/O tests
//
RunTest : Dot6DCInput;
RunTest : Dot6DCOutput;
RunTest : Dot6ACInput;
RunTest : Dot6ACOutput;
//
//1149.6 parametric tests
//
RunTest : Dot6DC00;

September 2017
BsdlFile
//RunTest : Dot6DC01;
//RunTest : Dot6DC10;
RunTest : Dot6DC11;
RunTest : Dot6AC00;
//RunTest : Dot6AC01;
//RunTest : Dot6AC10;
RunTest : Dot6AC11;
Note
The tests ending in xxx01 or xxx10 are commented out because they are expected to fail in
simulation but not on the ATE.
• Currently, the following features are not supported in the BSDL-only flow:
o TAP IR and DR bit settings in test steps
o VDD/GND pins in the netlist that need to be asserted
o Include and control pins in test benches that are not listed in the BSDL file
o NJTAG netlist data pins that are linkage pins in the BSDL file
• ETVerify’s command-line option -genConfigFile is not supported in BSDL-only flow, so
you must write your ETV.config from scratch. You can use the following ETVerify
configuration file example as a starting template:
etv ( TOP ) {
IncludeAllPowerPins : Yes; // Yes, (No)
JtagVerify(TOP) {
LoadBoardInfoFile : TOP.loadboard_info;
BsdlFile : ./TOP_user.bsdl;
PatternName : tapbistv;
SimulationScript : TOP_sim.script;
TCKPeriod : 100.0ns;
PhysicalConstraintFile : TOP.jtag_phy;
ActiveControlCells : 10;
TestStep ( Default ) {
RunTest : TestLogicReset;
RunTest : InstReg;
RunTest : IDReg;
RunTest : BypassReg;
RunTest : BscanReg;
RunTest : Input;
RunTest : Sample;
RunTest : HighZ;
RunTest : Clamp;
RunTest : Output;
}
}
}
Example
The following BSDL-only flow example shows how to create a Verilog test bench out of a
specified ETVerify configuration file:

September 2017
BsdlFile
etv TOP
-configFile ./TOP.myETConfig \
-outDir outDir_etv \
-verilog on \
-log outDir_etv/etv.log_testbench

September 2017
BurstClockController
The BurstClockController wrapper is used inside the following wrappers:
• Inside Controller of the LogicbistVerify and ScanVerify Wrappers
• Inside the UserDefinedSequence Wrapper
Inside Controller of the LogicbistVerify and ScanVerify Wrappers
The BurstClockController wrapper groups the properties that enable you to control the
operation of the Burst Clock controller.
Syntax
The complete syntax for the BurstClockController wrapper in the Controller wrapper in the
LogicbistVerify or ScanVerify wrapper is shown below:
BurstClockController (<N>) {
}
.// Repeat for N Burst Clock controllers
.
.
where N is an integer identifying a specific Burst Clock controller. When the .etSignOff file is
created by ETVerify, it also creates a file called README_etv which provides a comment to
show what number to use to select a given Burst Clock controller, for example:
// BurstClockController Number Associated Clock Labels
// ---------------------------------------------------
// 0 CK1_2, CK1_4, CK1_1 (SyncClkGroup: A)
// 1 CK2
// 2 CK3
Usage Conditions
This wrapper is used in the Controller wrapper inside either LogicbistVerify or ScanVerify
wrapper.
Related Information
BurstCyclesWithShiftClock LogicbistVerify
EffectiveSlowedDownFrequency ScanVerify
Controller SlowedDownBurstCycles
Inside the UserDefinedSequence Wrapper

The BurstClockController wrapper allows you to identify which Burst Clock controller clock
sources will be affected when the associated UserDefinedSequence is used in the ScanVerify
and LogicbistVerify wrappers.

September 2017
Syntax
UserDefinedSequence(<sequenceName>) {//Repeatable
ClockSourceOverride {
PhysicalRegion (<RE>) {//Repeatable
BurstClockContorller (<RE>) {//Repeatable
Pin: <string>;
PinInv: <string>;
where RE is a comma-separated list of regular expressions identifying a Burst Clock controller.

When the .etSignOff file is created by ETVerify, it also creates a file called README_etv which
provides a comment to show the number assigned to each Burst Clock controller, for example:
// BurstClockController Number Associated Clock Labels
// ---------------------------------------------------
// 0 CK1_2, CK1_4, CK1_1 (SyncClkGroup: A)
// 1 CK2
// 2 CK3
Default Value
None
Usage Conditions
This wrapper is used in the UserDefinedSequence: ClockSourceOverride: PhysicalRegion
wrapper.
• This wrapper is repeatable.
• The BurstClockController wrapper can only be used with a physical region that has been
generated with Version 7.0 or newer.
Example
The following example shows that the Burst Clock controllers, with ID numbers 0 and 3 in the
sub-physical region subCore will have their clock sources driven by the port clk2 on subCore
which is in turn is driven by the top-level pin clk[0].
UserDefinedSequence (1) {
PhysicalRegion (subCore) {
BurstClockController (0, 3) {
ClockInput: clk2;
}
ClockInput (clk2) {
Pin: clk[0];
}
}

September 2017
}
...
}
The following shows the summary that ETVerify would generate after processing the above
BurstClockController wrappers.
Summary of the Physical Region Overrides
----------------------------------------
Overrides for Physical Region: subCore_inst ( subCore )
BCC Id ClockInput on Physical Region FreqRatioRelToSource
----------------------------------------------------------------
0 clk2 1.0
3 clk2 1.0
ClockInput Source Pin FreqRatioRelToSource

----------------------------------------------------------------
clk2 clk[0] 1.0
Related Information
ClockInput Pin
ClockSourceOverride PinInv
FreqRatioRelToSource ScanVerify
LogicbistVerify UserDefinedSequence
PhysicalRegion

September 2017
BurstCyclesWithShiftClock
The BurstCyclesWithShiftClock property enables you to specify whether all clocks should be
driven by the shift clock rather than their functional clock sources during the logicTest
controllers burst phase.
Syntax

• Yes — all clocks are driven by the shift clock during the burst phase.
• No — all clocks are not driven by the shift clock during the burst phase.
Default Value
The default is No.
Usage Conditions
This property can be used directly in the LogicbistVerify and ScanVerify wrappers or on the
next level — inside the BurstClockController wrapper.
• BurstCyclesWithShiftClock cannot be set to No when the RunMode property is set to
HWDefault.
• Specifying BurstCyclesWithShiftClock directly in the LogicbistVerify or ScanVerify
wrapper is equivalent to repeatedly specifying it in a BurstClockController wrapper for all
Burst Clock controllers.
• BurstCyclesWithShiftClock declared in the BurstClockController wrapper has precedence
over the BurstCyclesWithShiftClock declared directly in the LogicbistVerify or
ScanVerify wrapper.
• When BurstCyclesWithShiftClock is set to Yes then the EffectiveSlowedDownFrequency
and SlowedDownBurstCycles properties have no effect.
Example
This example instructs ETVerify that all clocks are to be driven with the shift clock during the
burst phase except for those clocks controlled by BurstClockController (1) in TestStep (2).

September 2017
etv (MyDesignA) {
LogicbistVerify (ETC) {
BurstCyclesWithShiftClock: Yes;
TestStep (1) {
Controller (controllerA) {
StartVector: “LastVector *0.75”;
}
}
TestStep (2) {
BurstClockController (1) {
BurstCyclesWithShiftClock: No;
}
}
}
}
}
Related Information
BurstClockController SlowedDownBurstCycles
Controller LogicbistVerify

September 2017
BypassOpCode
BypassOpCode
The BypassOpCode property is used for multi-chip modules that consist of two or more die
packaged into a single part. Each die will have an IEEE 1149.1 TAP module that is daisy-
chained with the next die. ETVerify will generate test patterns to address the die-under-test. The
BypassOpCode property is used to define the OpCode necessary to place the daisy-chained
TAPs before and/or after the die-under-test into their Bypass mode.
Syntax
where binary is a binary number representing the OpCode needed to place a TAP into Bypass
mode.
Default Value
None
Usage Conditions
This property is used in the following wrappers inside the Global Section:
• JTAPAccess:PreAmble:Tap
• JTAPAccess:PostAmble:Tap
Example
Refer to Figure A-16 for an example of the BypassOpCode property.
Related Information
JTAPAccess PreAmble
PostAmble Tap
DeviceId

September 2017
CaptureBisrChain
CaptureBisrChain
The CaptureBisrChain property enables you to specify whether or not BISR chain registers
are sampled when the BisrChainAccess mode is selected. This property is only used with a
BISR loader controller.
Syntax
CaptureBisrChain: (On) | Off;
Default Value
Usage Conditions
wrappers of the .etEarlyVer, .etSignOff, and .etManufacturing files:
• MembistPVerify
• MembistVerify
• The property is only valid for a BISR loader controller.
• This property is used when the RunMode for the test step is BisrChainAccess.
Example
This example instructs ETVerify to create a test bench where the content of the BISR chain is
ignored during a BISR chain rotation:
MembistpVerify (TOP_P1) {
TestStep (RotateBisr) {
RunMode: BISRChainAccess;
CaptureBisrChain: Off;
EnableBiraCapture: Off;
}
}
}
Related Information
BisrChainSelect MembistVerify
Controller TestStep

September 2017
CaptureMeasurement
CaptureMeasurement
The CaptureMeasurement property forces the comparison of the measurement register of the
ULTRA controller with an all zero bitmap. Using this technique, the actual value of the
measurement can be reconstructed from the compare failures (the ETA software is capable of
performing this reconstruction on-a-fly, as the tests are performed). For this reconstruction to be
possible, a suitable tester is required—one with sufficient capture memory and the capability to
continue comparing despite failures.
Syntax
CaptureMeasurement: On | (Off);
Default Value
Usage Conditions
This property is used in the SerdesVerify: TestStep:Controller wrapper.
Example
CaptureMeasurement: On;
Related Information
Controller TestStep
SerdesVerify

September 2017
CellCompares
CellCompares
The CellCompares wrapper enables you to override boundary-scan cells expected captured
values for all scan operations performed during the test step.
Syntax
CellCompares {
...
}

• cellNumber — specifies a valid boundary-scan cell number as listed in the Boundary
Register Attribute section of the BDSL file of the design.
• 0 — instructs ETVerify to compare the cell’s capture value and shifted out for the specified
boundary-scan cell to a logic 0 value.
• 1 — instructs ETVerify to compare the cell’s capture value and shifted out for the specified
boundary-scan cell to a logic 1 value.
• X — instructs ETVerify not to compare the cell’s capture value and shifted out for the
specified boundary-scan cell.
Default Value
None
Usage Conditions
This wrapper is used in the JtagVerify: TestStep wrapper.
For specified cells, the CellCompares wrapper overrides all comparisons of its captured and
shifted-out value that are performed during the execution of the test step specified by the
RunTest property in the step. Typically, this wrapper is used to workaround false failures as a
result of a tied DUT pin on a DUT card.
Example
This example specifies that the values captured and shifted out from Cell 12 will be compared to
a logic 1 value during TestStep 3.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (3) {
RunTest: Input;
CellCompares {
12: 1;
}
}
}
}

September 2017
CellCompares
Related Information
TestStep RunTest
JtagVerify

September 2017
CellSettings
CellSettings
The CellSettings wrapper enables you to override the value to be shifted into a specific
boundary-scan cell for all scan operations performed during the test step.
Syntax
CellSettings {
...
}
where valid values are as follow:

• cellNumber — specifies a valid boundary-scan cell number as listed in the Boundary
Register Attribute section of the BDSL file of the design.
• 0 — instruct ETVerify to shift in and update the logic 0 value in the specified boundary-scan
cell.
• 1 — instruct ETVerify to shift in and update the logic 1 value in the specified boundary-scan
cell.
Default Value
None
Usage Conditions
This wrapper is used in the JtagVerify wrapper.
For the specified cells, the CellSetting wrapper overrides the value for all shift-in and update
operations that will be performed during the execution of the test specified by the RunTest
property in the test step. Comparisons of captured and pin values are adjusted accordingly.
Typically, this wrapper is used to force a static value on an output or bidirectional pin of DUT.
Example
This example specifies that the values shifted-in and updated on Cell 73 will be 1.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (1) {
RunTest: Input;
CellSettings {
73: 1;
}
}
}
}
Related Information
JtagVerify RunTest

September 2017
ChainBypass
ChainBypass
The ChainBypass property enables you to configure the logicTest controller so that logic BIST
scan chains are bypassed during a FlushTest or when scanning out a diagnostic logic BIST
pattern.
During a FlushTest the ChainBypass is helpful in isolating failing logic BIST chains so that a
problem with the scan path can be easily diagnosed.
The ChainBypass property can also reduce test time while diagnosing a problem by reducing
the number of scan in/out operations performed during a test.
Syntax
where chainList is comma-separated list of logic BIST chains to be bypassed. chainList can also
be specified as a range using a colon (:).
Default Value
None
Usage Conditions
• LogicbistVerify: TestStep: Controller
• ScanVerify: TestStep: Controller
• The ChainBypass property is only supported when LogicBIST is present.
• The ChainBypass property can only be used during a ScanVerify FlushTest or a
LogicbistVerify diagnostic test.
• The LogicBIST chain that a flop belongs to can be found by examining the
LV_WORKDIR/<designName>.ruleainfo_lbist file.
Example
The following example shows a LogicBIST diagnostic test that is bypassing the LogicBIST
chains 24, 15, 14, 13, 12, and 10:
LogicbistVerify (top_diagnostic) {
...
TestStep (Diagnostic) {
Controller (BP0) {
ChainBypass : 24, 15:12, 10;
Diagnostic : On;
StartVector : 1;
EndVector : 1;
}
}

September 2017
ChainBypass
Related Information
ScanVerify TestStep

September 2017
ChannelSelect
ChannelSelect
The ChannelSelect property allows you to select which pair of transmitter (serializer) and
receiver (de-serializer) associated with the current Controller instance will be subjected to
testing. This selection applies to all tests listed in SerdesTest, except the BasicTests and the
FunctionalLoopBack tests (SanityCheck: On;).
Syntax
ChannelSelect: <int>;
where int is an integer number greater or equal to 0.

Default Value
The default value is 0.
Usage Conditions
This property is used in the SerdesVerify: TestStep: Controller wrapper.
The maximum channel number allowed for any instance of the ULTRA controller depends on
how many Channel wrappers were specified in the .etplan file at the time the test hardware was
generated. The ETVerify tool will automatically generate an error if the value entered is
incorrect—the range is from 0 to one less than the number of channels tested.
Example
ChannelSelect: 3;
Related Information
Controller SerdesVerify
SanityCheck TestStep
SerdesTest Channel in the manual ETPlanner Tool
Reference

September 2017
CheckRepairNeeded
CheckRepairNeeded
The CheckRepairNeeded property determines whether any memory requires repair. This is
performed by comparing the GO signal of all memory BIST controllers connected to WTAPs
and the top-level TAP. A miscompare indicates that at least one memory with spare resources
has its 2-bit repair status register set to “01” after running memory BIST with BIRA enabled on
all memories with spare resources. The CheckRepairNeeded property is specified in a separate
TestStep and no other properties, other than the SplitPattern property, can be used in that
TestStep.
Syntax
Default Value
Usage Conditions
• MembistPVerify:TestStep
• MembistVerify: TestStep
If you specify the CheckRepairNeeded property, you cannot specify any other TestStep
property other than SplitPattern.
Example
For an example, see the “BIRA Repair Status Bits Checking” section of the “Implementing and
Verifying Memory Repair” chapter of the Tessent MemoryBIST User’s and Reference Manual.
Related Information
MembistVerify SplitPattern
“Incremental Repair” in the Tessent

September 2017
CheckRepairStatus
CheckRepairStatus
The CheckRepairStatus property enables you to specify that the repair analysis status registers
are to be examined after the BIST run is completed. The status registers report the repair status
of the memories with built-in redundancy.
Syntax
The syntax for this property is as follows:
CheckRepairStatus: On | (Off) | NonRepairable;

• On — specifies that the repair analysis status registers are sampled and compared against
the zero (0) value.
• Off — specifies that the repair analysis status registers are not to be sampled.
• NonRepairable — specifies that only the non-repairable flag of the status register is
sampled.
Default Value
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
At least one memory tested by the controller must have repair analysis defined in the memory
library file. When CheckRepairStatus is set to NonRepairable, the GO ID registers for the
repairable memories tested by this memory BIST controller are not sampled when local
comparators are used. The GO ID registers are sampled when CompareGoID is set to On for
memories with shared comparators. This feature is used to separate the bad or unrepairable
devices from the good or repairable devices during manufacturing. Refer to the “BIRA Repair
Status Bits Checking” section of the “Implementing and Verifying Memory Repair” chapter of
the Tessent MemoryBIST User’s and Reference Manual for further information.
Example
The following example specifies that the repair analysis status registers in controller SAMPLE
are to be examined:

September 2017
CheckRepairStatus
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
}
}
}
}
Related Information
CompareGoID MembistVerify
Controller TestStep
MembistPVerify “Incremental Repair” in the Tessent

September 2017
ClockInput
ClockInput
ClockInput is used both as a property and as a wrapper. Below are a separate sections for this
dual usage:
• Property
• Wrapper
Property
The ClockInput property allows you to specify a different clock input port on a sub-physical
region that will be sourcing the clock to a memory BIST controller, Burst Clock controller, or
Shift Clock controller.
Syntax
where string matches the name of a specified ClockInput Wrapper or a clock input associated
with the current physical region and defined in the TCM file.
Default Value
None
Usage Conditions
This property is used in the following wrappers inside the UserDefinedSequence:
ClockSourceOverride: PhysicalRegion wrapper:
• MemBistController: TestClockSource wrapper
• BurstClockController wrapper
• ShiftClockController: ShiftClockSource wrapper
• The ClockInput property must match the name of a specified ClockInput Wrapper or a
clock input associated with the current physical region and defined in the TCM file.
• The ClockInput property cannot be used when the PhysicalRegion wrapper corresponds to
the root physical region. You use the Pin and PinInv properties instead when documenting
clock source changes on the elements found within the root-level physical region.
Example
The following example shows that all memory BIST controllers in the sub-physical region
subCore, with module name and/or instance name containing the string .*F300.*, will have
their Functional TestClockSource driven by the port clk2 on subCore which is in turn is driven
by the
top-level port clk[0].

September 2017
ClockInput
MemBistController (.*F300.*) {
TestClockSource (Functional) {
ClockInput: clk2;
}
}
ClockInput (clk2) {
Pin: clk[0];
}
}
}
...
}
Related Information
BurstClockController PhysicalRegion
ClockInput ShiftClockController
ClockSourceOverride ShiftClockSource
MemBistController TestClockSource
Pin UserDefinedSequence
PinInv
Wrapper
The ClockInput wrapper allows you to reference a clock input port on physical region and
specify a new source and frequency ratio for it. You can also define a new clock input which is
not documented as such in the .tcm file so that you can make reference to it using the
ClockInput property.
Syntax
ClockInput (<RE> | new<portName>) {
//Repeatable
Pin: <string>;
PinInv: <string>;
where RE is a comma-separated list of regular expressions identifying a clock input port on the
sub-physical region.
When you are not referencing a clock source that is already documented as such in the .tcm file,
you must use new<portName> where new<> specifies that this is a new clock source not

September 2017
ClockInput
defined in the .tcm file, and portName is the name you want to create. Once created, a new
ClockInput can then be referenced by the ClockInput property.
Default Value
None
Usage Conditions
This wrapper is used in the ClockSourceOverride: PhysicalRegion wrapper.
• The ClockInput wrapper can only be used with a physical region that has been generated
with Version 5.0 or newer.
• The ClockInput wrapper cannot be used when the PhysicalRegion wrapper matches the root
physical region.
• The ClockInput wrapper can accept a regular expression to match any of the clock input
ports on the physical region that are defined as such in the .tcm file. Those are listed as
PI_CLK# in the .tcm file.
• The new<portName> syntax must be used if the specified ClockInput is not a clock pin that
is defined as such in the .tcm file.
Example
The following example shows that all memory BIST controllers in the sub-physical region
subCore, which module name and/or instance name contain the string .*F300.*, will have their
Functional TestClockSource driven by the port clk2 on subCore, which is in turn driven by the
top-level port clk[0].
ClockInput: clk2;
}
}
ClockInput (clk2) {
Pin: clk[0];
}
}
}
...
}

September 2017
ClockInput
ClockInput wrapper.
----------------------------------------
BCC Id ClockInput on Physical Region FreqRatioRelToSource
----------------------------------------------------------------
0 clk2 1.0
3 clk2 1.0

----------------------------------------------------------------
clk2 clk[0] 1.0
Related Information
ClockInput Pin
FreqRatioRelToSource UserDefinedSequence
PhysicalRegion

September 2017
ClockPeriod
ClockPeriod
The ClockPeriod property enables you to specify the master clock period used in the test
bench.
Syntax
where time is a real number specified in nanoseconds.

Default Value
The default value is 100 nanoseconds.
Usage Conditions
The ClockPeriod property is used in the following wrappers:
• CustomVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• SerdesVerify
• ScanVerify
Specify the period of the system clock when UseAsyncClocks is set to Off (the default) and
TestClockSource is not set to TCK. Otherwise the TCKPeriod property should be used instead.
Note that TestClockSource is used in the LogicbistVerify wrapper only for pre-existing cores
created with Mentor Graphics software prior to Version 5.0.
Example
This example instructs ETVerify to use a period of 10 nanoseconds.
etv (MyDesignA) {
CustomVerify (1) {
ClockPeriod: 10;
}
}
Related Information
TestClockSource UseAsyncClocks
TCKPeriod

September 2017
ClockPeriods
ClockPeriods
The ClockPeriods wrapper enables you to specify one or more system clock pins and their
associated clock periods.
Syntax
ClockPeriods {
.
.
}
where each pinName is a valid name for a system clock pin and period is a real number. Note
that there is no space between the period and unit. Valid values for specifying the units for
period are as follows:
• s — specifies the clock period time in seconds.
• ms — specifies the clock period time in milliseconds.
• us — specifies the clock period time in microseconds.
• ns — specifies the clock period time in nanoseconds.
• ps — specifies the clock period time in picoseconds.
Default Value
There is no default value. The default unit is ns for nanoseconds.

September 2017
ClockPeriods
Usage Conditions
The ClockPeriods wrapper is used in the following types of verification:
Table A-1. ClockPeriods Wrapper Usage Conditions

Usage Conditions Custom SerdesTest Memory
Verification Verification BIST
Section Section Verification
Section
Logic BIST CPU
Verification Verification
Section Section
Scan
Verification
Section
The ETVerify tool uses the information in this ✓ ✓ ✓
wrapper when creating test patterns, calculating
test time, and generating the DUT card
simulation model.
You can use the clock periods specified in the ✓ ✓ ✓
ClockPeriods wrapper when the
UseAsyncClocks property is set to On.
You must provide a pinName for each clock ✓ ✓ ✓
pin listed in the ClockPeriods wrapper.
When the UseAsyncClocks property is set to ✓ ✓ ✓
On, you must specify the system clock pin and
clock period for every controller in your
configuration file.
Some controllers might share the same clock ✓ ✓ ✓
pin, so the number of entries in your
ClockPeriods wrapper can be fewer than the
number of controllers in your configuration
file.
When the BasePeriod property is specified in ✓
an SerdesVerify wrapper, then the
ClockPeriods wrapper contents are ignored,
and the ClockPeriodsDividers wrapper
contents are used instead.
Example
This example specifies that a chip uses the clock on pin CKa with period of 10 nanoseconds.

September 2017
ClockPeriods
etv (MyDesignA) {
CustomVerify (ETC) {
ClockPeriods {
CKa: 10ns;
}
}
}
Related Information
BasePeriod MembistPVerify
ClockPeriodsDividers MembistVerify
CPUVerify SerdesVerify
CustomVerify UseAsyncClocks
LogicbistVerify

September 2017
ClockPeriodsDividers
ClockPeriodsDividers
When enabled by the fact that a BasePeriod is specified and that UseAsyncClocks is enabled,
the ClockPeriodsDividers wrapper allows the simulation of asynchronous clocks that are
derived from a common BasePeriod but are guaranteed to drift in a predictable manner. The
integer dividers specified for the clock pins listed in this wrapper will result in clocks that will
be perfectly aligned every time a BasePeriod has elapsed during simulation.
In practice, clocks that exhibit this behavior are generated by multiplying a reference clock
using PLLs (Phase Lock Loops).
Syntax
ClockPeriodsDividers {
<clockPinName>: <int>;
}
Usage Conditions
This wrapper is used in the SerdesVerify wrapper.
For this property to be considered, the UseAsyncClocks property must be set to On, and the
BasePeriod property must be specified.
Related Information
BasePeriod SerdesVerify
ClockPeriodsDividers UseAsyncClocks

September 2017
ClockSourceOverride
ClockSourceOverride
Users often have the ability to change clock sources and multiplication factors of PLL used by
BIST controller by creating UserDefinedSequence that performs custom transitions on primary
inputs or with userIRBits and/or userDRBits settings. The ClockSourceOverride wrapper
allows you to document the effect a UserDefinedSequence has on the clocking so that when it
is used in a xxxVerify wrapper, the pattern will be adjusted to the correct multiplication factor
between the clock pin and an embedded controller or to a newly selected clock source.
Figure A-4 shows an example chip with two sub physical regions called B1 and B2 and the top -
level called CHIP. The chip has a PLL in the top level which creates two-clock outputs—one
that multiplies the reference clock by 10 and the other by 5. These clocks are used by both
memory BIST and logic BIST controllers. The functional clocking is extracted by designExtract
and documented in the .tcm file. This is how the ETVerify tool (such as MembistVerify) knows
which clock input of the chip needs a free-running clock source, and how many clock cycles are
needed at the input of the chip for the memory BIST controller to receive the right amount of
clock cycles to complete the test.
Such PLLs often have programmable multiplication factors and/or alternate reference sources.
You might need to program a different clocking configuration during some embedded test
pattern generation. You use a UserDefinedSequence wrapper to program the new clocking
configuration and a ClockSourceOverride wrapper within it to document the effect of the
UserDefinedSequence actions such that the ETVerify tool knows that the clocking no longer
behaves as documented in the .tcm file but with the new configuration.
When you have multi-level blocks, the tool does not propagate the ClockSourceOverride
wrapper values through the multiple levels of hierarchy. In other words, you must specify the
wrapper for each level.
For example, Block_A instantiates Block_B which instantiates Block_C. If you specify the
ClockSourceOverride wrapper between Block_A and Block_B in order to change the clock
ratios going into Block_C, the tool does not propagate this value to Block_C. If under Block_B,
you have children Block_C, Block_D, Block_E, … (where Block_C, Block_D, and Block_E
are siblings), then you must specify the ClockSourceOverride wrapper for each of the blocks
(that is, Block_C, Block_D, and Block_E).
The code listing in Example 2 shows an example clocking re-configuration that can be applied
to the chip shown in Figure A-4, and how the ClockSourceOverride wrapper documents this
new clocking.
The ClockSourceOverride wrapper is new in Dragonfly Version 7.0 and relies on information
within the.tcm file which is only stored if designExtract Version 7.0 or higher was used to create
the top-level .tcm file. Refer to ClockSourceOverride with Pre-7.0 Designs for options about
how to use this feature on older designs.

September 2017
ClockSourceOverride
Figure A-4. Example CHIP with DFT Clocking Documented in TCM file
Syntax
Pin: <string>;
PinInv: <string>;
ClockInput(<pinName> | new<portName>) {
//Repeatable
Pin: <string>;
PinInv: <string>;

September 2017
ClockSourceOverride
Pin: <string>;
PinInv: <string>;
ShiftClockController(<RE>) {//Repeatable
Pin: <string>;
PinInv: <string>;
Default Value
None
Usage Conditions
This wrapper is used in the UserDefinedSequence wrapper.
At least one TestStep wrapper or SVFFile property must be declared in the
UserDefinedSequence wrapper to perform the actions needed to implement the clock source
overriding.
Example 1
The following example shows that all memory BIST controllers in the physical region interface
will be sourced by the pin clk2 with a frequency ratio of 6.0 after the actions in TestStep (0)
have been performed.
UserDefinedSequence (clk2x6) {
PhysicalRegion (interface) {
MemBistController (.*) {
TestClockSource (.*) {
Pin: clk2;
FreqRatioRelToSource: 6.0;
}
}
}
}
TestStep (0) {
// Actions needed to switch the clock
// driving the memory BIST to clk2 with
// a frequency ratio of 6.0
}
}
Example 2
In this example, UserDefinedSequence is used to reprogram the PLL multiplication factor to
5X and change the reference source to CK2.

September 2017
ClockSourceOverride
The chip shown in Figure A-5 is designed such that this PLL programing is controlled by
UserDRBits of the TAP, so a simple TestStep wrapper with UserDRBit settings is needed to
reprogram the PLL. The ClockSourceOverride wrapper documents the effect such that any
xxxVerify wrapper referencing UserDefinedSequence is automatically told about the new
clocking configuration.
Figure A-5. UserDefinedSequence Used to Reprogram the PLL Multiplication

Factor
The following code shows the syntax for the UserDefinedSequence wrapper:
UserDefinedSequence (PLLX5_CK2ref) {
TestStep (0) {
UserDRBit (0): On; //Enables X5 feedback
UserDRBit (1): On; //selects CK2 as reference
}
PhysicalRegion (B.) {
ClockInput (CK1_x10) {
Pin: CK2;

September 2017
ClockSourceOverride
}
ClockInput (CK1_x5) {
Pin: CK2;
}
}
PhysicalRegion (Chip) {
MemBistController (CK1_X10.*) {
TestClockSource (.*) {
Pin: CK2;
}
}
}
}
ClockSourceOverride with Pre-7.0 Designs

The ClockSourceOverride wrapper was introduced in Dragonfly Version 7.0. The feature
makes use of information stored in the .tcm file which was also introduced in Version 7.0. The
new information is the association of clock sources for memory BIST controllers to ClockInput
on the physical region the memory BIST controllers reside in. In Example 2 above, the .tcm file
created by designExtract Version 7.0 describes that M1 and M3 are driven by the clock input
CK1_X10 on the B1 physical region. This information is not present in the .tcm file generated by
an older designExtract as illustrated in Figure A-6.
Figure A-6. Lost Information by designExtract Prior to Dragonfly Version 7.0
To use this feature in ETVerify Version 7.0 with an older design, you must do one of the
following:
• Rerun designExtract Version 7.0 on the top level. No need to rerun designExtract on the
blocks.
• Manually add the missing PI_CLK entries in the .tcm file
• Explicitly specify the ClockInput property for each memory BIST controller affected by
UserDefinedSequence as shown below:
PhysicalRegion(B.) {

September 2017
ClockSourceOverride
ClockInput(CK1_x10) {
Pin: CK2;
}
ClockInput(CK1_x5) {
Pin: CK2;
}
//.tcm file
TestClockSource(.*) {
ClockInput: New<CK1_X10>;
}
}
TestClockSource(.*) {
ClockInput: new<CK1_X5>;
}
}
}
Related Information
SVFFile UserDefinedSequence
TestStep

September 2017
Collar
Collar
The Collar wrapper identifies a memory collar instance used in the design. This is only a
container for the collar CompStatIDSelect or ExpectedROMSignature property.
Figure A-7 presents the syntax for the Collar wrapper.
Figure A-7. Collar Wrapper in the MembistVerify: TestStep: Controller Wrapper
Collar (<RAMInstName>) {
}
Collar (<ROMInstName>) {
ExpectedROMSignature: <bitsValue>;
}
where RAMInstName and ROMInstName are from the ETAssemble/LV_WORKDIR/*.membist

file.
Usage Conditions
This wrapper is used in the TestStep: Controller wrapper inside the following wrappers:
• MembistPVerify
• MembistVerify
Related Information
CompStatIDSelect MembistPVerify
Controller MembistVerify
ExpectedROMSignature TestStep

September 2017
CompareCmpStat
CompareCmpStat
The CompareCmpStat property specifies that the compare status (CMP_STAT) controller port
is to be monitored during the test.
Syntax
CompareCmpStat: On | (Off);

• On—specifies that the compare status port is to be monitored.
• Off—specifies that the compare status port is not to be monitored.
Default Value
Usage Conditions
This property is used in TestStep: Controller of the following verification wrappers:
• MembistPVerify
• MembistVerify
• The ETPlanner property CompStat must be set to Yes or SharedWithGo in order to provide
the compare status controller port.
• If the ETPlanner property CompStat was set to SharedWithGo, you must set the Diagnostic
property to On.
• If the ETPlanner property CompStatMux was set to Yes, you must also use the
CompStatIDSelect property to specify the comparator that drives the compare status port in
order to observe the compare status result.
• The memory BIST controller’s compare status port must be connected to a chip pin.
Example
This example specifies that the compare status port is to be monitored during execution of the
BIST.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
CompareCmpStat: On;
}
}
}
}

September 2017
CompareCmpStat
Related Information
CompareGo MembistPVerify
CompStatIDSelect MembistVerify
Controller CompStat in the manual ETPlanner Tool
Reference
Diagnostic CompStatMux in the manual ETPlanner Tool
Reference

September 2017
CompareDiagDataToZero
CompareDiagDataToZero
The CompareDiagDataToZero property enables you to specify whether or not internal
registers of the memory BIST controller are sampled after the BIST run is completed. This
property is useful when the Stop-On-Nth-Error feature is enabled using FailureLimit. The
internal register values can be post-processed to provide diagnostic information on the detected
failures.
The internal register values are only meaningful if the controller has stopped at the requested
number of failures (DONE signal will be 0).
Syntax
CompareDiagDataToZero: On | (Off);

• On—specifies that internal registers are to be sampled after the memory BIST run is
completed.
• Off—specifies that the internal registers are not to be sampled.
Default Value
Usage Conditions
• MembistPVerify
• MembistVerify
Example
This example specifies to ETVerify that internal registers are to be sampled after the memory
BIST run is completed.
etv (MyDesignA) {
MembistVerify (1) {
CompareDiagDataToZero: On;
}
}
Related Information
FailureLimit MembistVerify
MembistPVerify

September 2017
CompareGo
CompareGo
The sections below provide detailed information on the following usage of the CompareGo
property:
• MembistVerify and MembistPVerify Usage
MembistVerify and MembistPVerify Usage
The CompareGo property specifies that the pass/fail (GO) controller port is to be checked for
the results at the end of the test. This operation provides the composite pass/fail result from all
comparators in the controller.
Syntax
CompareGo: (On) | Off;

• On— specifies that the pass/fail port is to be checked for the results at the end of the test.
• Off— specifies that the pass/fail port is not to be checked for the results at the end of the
test.
Default Value
Usage Conditions
This property is used in the TestStep: Controller wrapper of the following verification:
wrappers:
• MembistPVerify
• MembistVerify
• If the ETPlanner property CompStat was set to SharedWithGo, you must set the Diagnostic
property to Off to observe the composite pass/fail result.
• If the selected step does not contain any ROMs, make sure CompareGo is set to On.
Example
This example specifies that the pass/fail port is to be checked for the results at the end of the test
during execution of the BIST.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
CompareGo: On;
}
}
}
}

September 2017
CompareGo
Related Information
Controller Diagnostic
MembistVerify CompStat in the manual ETPlanner Tool
Reference

September 2017
CompareGoID
CompareGoID
The CompareGoID property specifies that the compare status registers (GoID) are to be
scanned and examined at the end of the test. This operation identifies which comparator failed,
but not necessarily the step in which it failed.
Syntax
CompareGoID: On | (Off);

• On — specifies that the GoID registers are to be examined at the end of the test.
• Off — specifies that the GoID registers are not to be examined at the end of the test.
Default Value
Usage Conditions
This property is used in the Controller wrapper in the following types of verification:
• MembistPVerify
• MembistVerify
• This property is meaningful only when one or more RAMs are tested by the memory BIST
controller.
• If you want to know which memory instance failed, you should turn on the FreezeStep
property and run the test with the number set in the FreezeStepNumber property to each of
the steps in the memory BIST configuration file. When a GoID fails, you can look up that
step in the memory BIST configuration file and find the memory instance associated with
the GOID comparator.
• When the CheckRepairStatus property is set to NonRepairable, the behavior of
CompareGoID is disabled for repairable memories with local comparators. The GO ID
registers for non-repairable memories or repairable memories with shared comparators are
always sampled when CompareGoID is set to On.
• This property is meaningful when the Diagnostic property is set to Off.
Example
This example specifies that the GoID registers are to be examined at the end of the test.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
CompareGoID: On;
}

September 2017
CompareGoID
}
}
}
Related Information
CheckRepairStatus FreezeStepNumber
Controller MembistPVerify
Diagnostic MembistVerify
FreezeStep

September 2017
CompareHardCodedSignature
The sections below provide detailed information on the following usage of the
CompareHardCodedSignature property:
• LogicbistVerify Usage
• MembistPVerify and MembistVerify Usage
LogicbistVerify Usage
The CompareHardCodedSignature property determines whether or not ETVerify compares
the observed signature of the logic block to the hardcoded signature in the strap module. This
property is useful for the case when the content in the logic block has changed, but the logic
BIST controller’s strap was not updated.
Note
This property is only for pre-5.0 logic BIST controllers.
Syntax

• On — specifies that the hardcoded signature will be compared.
• Off — specifies that the hardcoded signature will not be examined.
Default Value
Usage Conditions
This property is used in the LogicbistVerify: TestStep wrapper.
• The EndVector property must be set to LastDefaultVector if the
CompareHardCodedSignature property is turned off.
• The CompareHardCodedSignature property is ignored when the RunMode property is set
to HWDefaultInitTest.
Example
This example specifies that the hardcoded signature is not to be examined during logic BIST
test.

September 2017
etv (MyDesignA) {
LogicbistVerify (1) {
TestStep (0) {
CompareHardCodedSignature: Off;
}
}
}
Related Information
TestStep EndVector
LogicbistVerify RunMode
MembistPVerify and MembistVerify Usage

The CompareHardCodedSignature property can be used to enable comparing the signature of
the ROM that is hardcoded in the strap module. This property is useful for the case when the
ROM content has changed, but the straps module of the embedded test controller was not
updated.
Syntax

• On—specifies that the hardcoded signature to be used as the golden signature in
determining the pass/fail status.
• Off—specifies that the hardcoded signature would not be used as a golden signature. You
must specify the ExpectedROMSignature property to define the signature value to be
compared.
Default Value
Usage Conditions
• MembistPVerify
• MembistVerify
• When the ExpectedROMSignature property is defined, it forces the
CompareHardCodedSignature property to be set to Off.
• When this property is set to Off, the CompareMISR property must be set to On and the
ExpectedROMSignature property must be specified.
Example
This example specifies that the ROM signature is to be compared with a user-specified value.

September 2017
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
}
}
}
}
Related Information
CompareMISR MembistVerify
Controller ExpectedROMSignature

September 2017
CompareMISR
CompareMISR
The CompareMISR property specifies that the ROM MISRs are to be examined at the end of
the test, which enables you to identify which ROMs failed. If RomDiagnostic is enabled for this
controller, the CompareMISR property is used to extract the content of the ROM memory at a
specific address.
Syntax
CompareMISR: On | (Off);

• On—specifies that the ROM MISRs are to be examined at the end of the test. If running in
ROM diagnostic mode, it specifies that the content of a specific address is to be extracted
and compared externally.
• Off—specifies that the ROM MISRs are not to be examined at the end of the test.
Default Value
Usage Conditions
• MembistPVerify
• MembistVerify
• This property is meaningful only if one or more ROMs are tested by the Tessent
MemoryBIST controller.
• If you apply the ReadOnly library algorithm with a custom operation set, the computed
MISR signature may be incorrect. When multiple StrobeDataOut properties are specified in
an operation applied on one address, the ROM data is compressed multiple times into the
MISR circuit. In this case, you can determine the actual MISR signature from simulation
and use the ExpectedROMSignature property to provide the signature for comparison.
• When running in ROM diagnostic mode, the CompareGo property must be turned Off.
Example
This example specifies that the ROM MISRs are to be examined at the end of the test.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
CompareMISR: On;
}

September 2017
CompareMISR
}
}
}
This example specifies that the content of the ROM address 0x04 is to be extracted:
membistVerify(SAMPLE) {
TestStep ( RomDiag ) {
Controller ( BP1 ) {
CompareGo : Off;
CompareMISR : On;
FailureLimit : 5; // Diagnose Address +1
CompareHardCodedSignature : Off;
}
}
}
Related Information

September 2017
ComparisonToLimits
ComparisonToLimits
The ComparisonToLimits wrapper controls which of the LowerLimit and UpperLimit
properties of the MeasurementLimits wrapper will be compared at the end of a measurement, in
order to set the associated pass/fail bits.
Syntax
ComparisonToLimits: None | Both | LowerLimit |
UpperLimit
Default Value
Both
Usage Conditions
This property is valid only in the SerdesVerify: TestStep: Controller wrapper.
The MeasurementLimits wrapper is completely ignored when None is specified.
Example
The following will perform an Jitter test for controller BP1, and comparing the expected
measurement to only the upper limit.
etv (MyChip) {
SerdesVerify (Tests) {
TestStep (OnChipJitter) {
SerdesTest: Jitter;
Pattern: P1010;
Controller (BP1) {
//...
ComparisonToLimits: UpperLimit;
MeasurementLimits (ps) {
UpperLimit: 5.0;
}
}
}
}
}
Related Information
LowerLimit TestStep
MeasurementLimits UpperLimit

September 2017
CompareStrobeCount
CompareStrobeCount
When the programmable controller is executed in Go/NoGo mode and is equipped with Stop-
On-Nth-Error (SOE) diagnosis capability, the SOE counter is enabled to count the number of
compare events applied by the test algorithms.
The compare events are indicated by the StrobeDataOut property within the Tick wrapper of
the operation definition. In conjunction with the DONE status, the strobe count provides an
indication that the controller circuit is operating correctly. Any deviation would point to
undesired circuit behavior which could sometimes be observed during circuit characterization.
Use the CompareStrobeCount property if characterization results, generally presented in the
form of Shmoo plots, show isolated PASS regions outside the normal operating conditions of
supply voltage and temperature.
When CompareStrobeCount is On, the content of the SOE counter will be checked, at the end
of the test, against the expected value specified by the ExpectedStrobeCount property. The
SOE counter does not report the total number of compares. The SOE counter is a down-counter
and it is possible for the counter value to wrap around zero. Therefore, the expected counter
value must be computed as the two’s complement of the modulo (number of compares/counter
size). The counter value must be obtained from simulation. Setting ExpectedStrobeCount to the
correct value is necessary to obtain a PASS status when CompareStrobeCount is On.
Syntax
CompareStrobeCount: On | (Off);
where the valid values are as follows:
• On — Indicates the contents of the SOE counter will be checked against the expected value
specified by the ExpectedStrobeCount property.
• Off — Indicates the contents of the SOE counter will not be checked.
Default Value
Usage Conditions
This property is used in the TestStep:Controller wrapper of the following verification wrapper:
• MembistPVerify

September 2017
CompareStrobeCount
• SOE diagnosis must be enabled by setting the ETPlanner property StopOnErrorLimit to 2

or higher. However, a value of 8 or higher is recommended for more reliable results.
• The FailureLimit property must be 0.
• The DebugMode property must be Off.
• When generating a pattern for use in CDP, the CompareGoID property must be Off in the
.etManufacturing file. Setting CompareGOID to Off instructs SiliconInsight to omit
creating SOE diagnosis patterns.
Examples
This example enables counting the compare events of the default algorithm. At the end of the
test, the SOE counter is extracted and the content is compared to zeros.
MembistpVerify(P1) {
TestStep(1) {
Controller(BP0) {
CompareGO : On;
CompareGOID : On;
CompareStrobeCount : On;
}
}
}
This example enables counting the compare events of the custom algorithm. At the end of the
test, the SOE counter is extracted and the content is compared to binary value 110.
TestStep(1) {
Controller(BP0) {
CompareGO : On;
HardcodedAlgorithm : b2b_xy;
ExpectedStrobeCount : 6;
}
}
}
Related Topics
MembistPVerify FailureLimit
DebugMode ExpectedStrobeCount
StopOnErrorLimit in the ETPlanner Tool
Reference

September 2017
CompStatIDSelect
CompStatIDSelect
The CompStatIDSelect property specifies the individual comparator status to be routed to the
compare status controller port. The candidate test result signals include the following:
• Global comparator status signal
• Individual comparator status signal
• Constant logical 1 value
You can use this property:
• Within the Collar wrapper to select the comparator status for memories tested with the
ETPlanner property LocalComparators set to Yes. For more details, refer to “Collar Usage.”
• Within the Controller wrapper to select the comparator status for memories tested with the
ETPlanner property LocalComparators set to No. For more details, refer to “Controller
Usage.”
Collar Usage
Syntax
The following syntax specifies this property inside the Collar wrapper:
Collar (<RAMInstName>) {
}

• RAMInstName — is the name of the RAM to which the interface is associated.
RAMInstName must correspond to MemoryCollar in the ETPlanner configuration file.
• cpidNum — is an integer that specifies which test result signal to use. Setting this variable to
a value determines the test result signal as follows:
o Setting cpidNum to 0 selects the interface’s global comparator status signal.
o Setting cpidNum to a value between 1 and n selects the corresponding interface
comparator status, where n represents the total number of comparators.
o Setting cpidNum to n+1 selects a constant logical 1 value, where n represents the
total number of interface comparators. This is useful for diagnosis when other
MemoryCollars have the LocalComparators property set to Yes, and when there are
comparators in the memory BIST controller.
Default Value
The default is 0, which selects the interface’s global comparator status signal.
Usage Conditions
This property is used in TestStep: Controller: Collar of the following verification wrappers:

September 2017
CompStatIDSelect
• MembistPVerify
• MembistVerify
• This property is meaningful only when the property CompareCmpStat is set to On or the
ETPlanner property StopOnErrorLimit is not zero.
• At least one RAM must be tested with the ETPlanner property LocalComparators set to
Yes.
• You must have set the ETPlanner property LocalComparators to Yes when you generated
the controller.
• The memory collar (<RAMInstName>) in the ETPlanner configuration file must have
LocalComparators set to Yes.
• During diagnosis, you should only observe one interface comparator status signal at a time
and isolate all other comparator status signals. The Controller: CompStatIDSelect property
should be set to n + 1. For every interface other than this one that has LocalComparators set
to Yes, set their Collar: CompStatIDSelect property to n + 1.
Controller Usage
Syntax
The following syntax specifies this property the Controller wrapper:

• cpidNum — is an integer that specifies which test result signal to use. Setting this variable to
a value determines the test result signal as follows:
o Setting cpidNum to 0 selects the global controller comparator status signal.
o Setting cpidNum to a value between 1 and n selects the corresponding controller
comparator status, where n represents the total number of controller comparators.
o Setting cpidNum to n+1 selects a constant logical 1 value, where n represents the
total number of controller comparators. This is useful for diagnosis when other
MemoryCollars have the LocalComparators property set to Yes.
Default Value
The default is 0, which selects the global controller comparator status signal.
Usage Conditions
This property is used in the TestStep: Controller of the following verification wrappers:
• MembistPVerify
• MembistVerify

September 2017
CompStatIDSelect
• This property is meaningful only when the property CompareCmpStat is set to On or the
ETPlanner property StopOnErrorLimit is not zero.
• At least one RAM must be tested with the ETPlanner property LocalComparators set to No.
• You must have set the ETPlanner property CompStatMux to Yes when you generated the
controller.
• During diagnosis, you should only observe one controller comparator status signal at a time
and isolate all other comparator status signals. For interfaces that have LocalComparators
set to Yes, set their Collar: CompStatIDSelect property to n + 1.
Example
The following syntax specifies that the second individual comparator status signal from the
interface associated with memory MEM0 is routed to the controller’s compare status port.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
Collar (MEM0) {
CompStatIDSelect: 2;
}
}
}
}
}
Related Information
Collar MembistVerify
CompareCmpStat TestStep
Controller CompStatMux in the manual ETPlanner Tool
Reference
Diagnostic LocalComparators in the manual ETPlanner
Tool Reference
MembistPVerify MemoryCollar in the manual ETPlanner Tool
Reference

September 2017
ContactedPins
ContactedPins
The contents of the ContactedPins wrapper enables you to specify which design pins are
contacted to a tester channel during test pattern execution as well as the properties of each tester
channel.
Syntax
ContactedPins {
DesignPin (<pinName>){
Control: (None) | TwoStateWeak | TwoStateStrong |
}
}
Default Value
None
Usage Conditions
• The ContactedPins wrapper is optional. Note the following:
o The absence of this wrapper means that “all” device pins are contacted with all
capabilities.
o The presence of this wrapper without any DesignPin wrapper inside in it means that
“no” device pin is contacted. Contacted pins are then exclusively those for which a
DesignPin wrapper is specified.
o When ETVerify is executed with the -genConfigFile runtime option, the resulting
configuration file does not contain the ContactedPins wrapper so that, by default,
all pins are contacted with full capabilities.
• IO tests patterns depend on information provided by the ContactedPins wrapper. As an
example, an input pin that is not contacted to a tester channel is not tested during the INPUT
test, and an associated warning is issued at the time of generating the patterns.
• The ContactedPins wrapper can be specified in both ETVerify configuration file and -
genConfigFile.
Example
This example specifies that no device pin is contacted to a tester channels. More detailed
examples are provided in the following sections.
etv (MyDesignA)
JtagVerify (ETC) {

September 2017
ContactedPins
ContactedPins {
}
TestStep (1) {
}
}
}
Related Information
Control PullResistor
DesignPin -genConfigFile
JtagVerify
Observation

September 2017
Control
Control
The Control property enables you to specify the control capabilities of the tester channel
contacted to a design pin.
Syntax
Control: (None) | TwoStateWeak | TwoStateStrong |

• None — specifies that the tester channel has no control capabilities.
• TwoStateWeak — specifies that the tester channel can apply weak 0 or 1 on the design pin.
The tester drive can support contention with a driving output or bidirectional pin of the
design.
• TwoStateStrong — specifies that the tester channel can apply strong 0 or 1 on the design
pin.
• ThreeState — specifies that the tester channel can apply strong 0, strong 1, or HighZ on the
design pin.
• H — specifies that the tester channel ties the design pin to a constant strong 1.
• L — specifies that the tester channel ties the design pin to a constant strong 0.
• Z — specifies that the tester channel constantly applies HighZ on the design pin.
• X — specifies that the tester channel applies a signal on the design pin but its value is
unknown.
Default Value
The default value is None.
Usage Conditions
This property is used in the JtagVerify: DesignPin wrapper.
• If the Control property does not exist in the DesignPin wrapper, the tester channel is
considered to have no control capabilities.
• Typically, the X value is used when a signal that is not under the control of the tester is
applied on the design pin as an asynchronous clock.
Example
This example specifies that the pin Sync can be driven to strong 0 and 1, and bus DbusA
elements can be driven to strong 0 and 1, and HighZ by the tester.
etv (MyDesignA) {
JtagVerify (ETC) {
ContactedPins {

September 2017
Control
DesignPin (Sync){
Control: TwoState;
}
DesignPin (DBusA(0)){
}
DesignPin (DBusA(31)){
}
}
}
}
Related Information
ContactedPins Observation
DesignPin PullResistor
JtagVerify

September 2017
Controller
Controller
The sections below provide detailed information on the following usage of the Controller
wrapper:
• JtagVerify Usage
• MembistPVerify and MembistVerify Usage
• ScanVerify Usage
• SerdesVerify Usage
• WTAPVerify Usage
JtagVerify Usage
The Controller wrapper enables you to define a specific controller on which a register flush test
is to be performed.
Syntax
Figure A-8 presents the Controller wrapper in the JtagVerify wrapper.
Figure A-8. Controller Wrapper in the JtagVerify: TestStep Wrapper
Controller (<controllerName> | BPx | DPx | BPx.WBPy | DPx.WBPy) {

SetupChainRegister: <register to test>;
}
.// Repeat for all controllers to be run in
.// the same test step
.

• controllerName — is the embedded test controller’s module name.
• register to test — is the name of the controller register on which to run a flush test. You can
find all controller register names in your output .hsdl file.
• BPx — specifies the TAP BIST port to which the controller is connected.
• DPx — specifies the Direct Pin interface to which the controller is connected.
• BPx.WBPy — specifies the WTAP BIST port y to which the controller is connected and
TAP BIST port x to which WTAP is connected.
• DPx.WBPy — specifies the WTAP BIST port y to which the controller is connected, and
Direct Pin Interface x to which the WTAP is connected.
Mentor Graphics recommends that you use the controller’s module name unless multiple
instances of the same controller exist within the same chip. In the latter case, use the BIST port
or direct pin interface identifier to resolve which instance of the controller to run.
For the complete syntax of the Controller wrapper, refer to the TAP Verification Section.

September 2017
Controller
Usage Conditions
Only one Controller wrapper is allowed in a single test step.
This option allows you to run a simple controller’s register flush test without having to load a
series of controller-specific data files, making the test both faster to generate and stay immune
to older controller’s backward-compatibility problems.
The Controller wrapper is used to group all properties specific to a logic BIST controller. A
separate Controller wrapper is required for each logic BIST controller to be run in parallel
during the current test step.
Syntax
Figure A-9 presents the Controller wrapper in the LogicbistVerify wrapper.
Figure A-9. Controller Wrapper in the LogicbistVerify: TestStep Wrapper

...
}
.

Mentor Graphics recommends that you use the controller’s module name unless multiple
instances of the same controller exist within the same chip. In the latter case, use the BIST port
or direct pin interface identifier to resolve which instance of the controller to run.
For the complete syntax of the Controller wrapper, refer to the Logic BIST Verification
Section.
The Controller wrapper is used to group all properties specific to a memory BIST controller or
a BISR loader controller. A separate Controller wrapper is required for each memory BIST
controller to be run in parallel during the current test step. Memory BIST controllers and BISR
loader controllers cannot run in the same test step.

September 2017
Controller
Syntax
Figure A-10 presents the Controller wrapper in the MembistPVerify and MembistVerify
wrapper.
Figure A-10. Controller Wrapper in the MembistVerify: TestStep and

MembistVerify: TestStep Wrappers

...
}
.

Mentor Graphics recommends using the controller’s module name unless multiple instances of
the same controller exist within the same chip. In the latter case, use the BIST port or direct pin
identifier to resolve which controller instance to run.
For the complete syntax of the Controller wrapper, refer to the Memory BIST Verification
Section.
ScanVerify Usage
The Controller wrapper is used to identify either a target embedded logicTest controller, or a
chip-level logicTest controller, or a scannable module without logicTest controller.
Syntax
Figure A-11 presents the Controller wrapper in the ScanVerify wrapper.
Figure A-11. Controller Wrapper in the ScanVerify: TestStep Wrapper

...
}
.

September 2017
Controller

Mentor Graphics recommends using the controller’s module name unless multiple instances of
the same controller exist within the same chip. In the latter case, use the BIST port or direct pin
identifier to resolve which controller instance to run.
For the complete syntax of the Controller wrapper, refer to the Scan Verification Section.
SerdesVerify Usage
The Controller wrapper is used to group all properties specific to a ULTRA controller being
tested in the current TestStep in the SerdesVerify wrapper. More than one Controller wrapper
can be used in the TestStep wrapper—one wrapper per each ULTRA controller.
Syntax
The syntax for the Controller wrapper in the SerdesVerify wrapper is as follows:
Controller (<controllerIdentifier>) {// Repeatable
...
}
.
where controllerIdentifier specifies an ULTRA controller name.

Usage Conditions
This wrapper is used in the SerdesVerify: TestStep wrapper.
WTAPVerify Usage
The Controller wrapper is used to group all properties specific to a WTAP controller being
tested in the current TestStep in the WTAPVerify wrapper. Only one Controller wrapper can be
used in the TestStep wrapper, since only one WTAP can be tested in the TestStep. The
Controller wrapper can contain multiple RunTest properties that are used to specify the WTAP
tests to be executed.
Syntax
The syntax for the Controller wrapper in the WTAPVerify wrapper is as follows:

September 2017
Controller
Controller (<moduleName>| DP#| BP#) {// Not Repeatable

RunTest: TestLogicReset| InstReg| BypassReg|
IDReg;
.
.
}

• moduleName — is the WTAP controller’s module name. moduleName is used when there is
only one instance of WTAP in your design.
• BPx — specifies the WTAP port to which the controller is connected. BPx is used when
there are multiple WTAPs in your design.
Usage Conditions
This wrapper is used in the WTAPVerify: TestStep wrapper.

September 2017
CPUActionsFile
CPUActionsFile
The CPUActionsFile property specifies the name of the file that contains the CPU WriteRead
commands to execute actions. Such files contain a list of CPUWrite, CPURead,
CPUWaitCycles, and CPUComment commands which when executed in sequence perform
desired actions using the BIST or test engines controlled by the TAP.
When you run ETAssemble at the chip level, and you have requested that the TAP controller be
created with a CPUActionsFile, a directory called CPUInterfaceFiles will be created inside the
ETAssemble output directory. The directory will contain a file called
<designName>_TAPTest.cpuWR which exercises the access of the registers found within the
TAP controller through the CPU Interface. The action file is used to certify that your CPU
access mechanism properly interacts with the CPUInterface of the TAP and is capable of
operating in all its modes.
If you want to simulate an arbitrary BIST pattern through the CPUInterface, start by creating
an SVF file for the given pattern by invoking ETVerify with -svf on command line option. Then
you use the svf2cpu Utility to convert the SVF pattern into a CPUActionsFile which
implements the exact pattern found within the SVF file where the SIR/SDR commands have
been converted into CPUWrite and CPURead commands.
Syntax
CPUActionsFile: <fileName>;
where fileName is the name of the CPU Action file. You do not specify a directory name with
the file name. The location of CPUActionsFile is hardcoded to be in a directory called
CPUInterfaceFiles found in the directory where the TAP gtool_info file is described to be in the
.tcm file.
When running Early Verifications inside the ETAssemble directory of the lvWorkSpace, this
directory exists in the output directory of ETAssemble which defaults to outDir. During make
lvdb, the CPUInterfaceFiles directory is copied into the LVDB, and ETVerify later reads
CPUActionsFile from the LVDB.
Default Value
None
Usage Conditions
This property is used in the CPUVerify: TestStep wrapper.

September 2017
CPUActionsFile
• You point to a CPUActionsFile that exists within the CPUInterfaceFiles directory located
besides the TAP gtool_info file.
• If the CPU Actions file uses parameters, then you must define the value of the parameters
using the Variable wrapper, otherwise, you will get an undefined variable errors when you
try to simulate the generated test bench.
• You can simulate many CPU patterns in series by repeating the TestStep wrapper with each
CPUActionsFile property pointing to different CPU Actions files.
Example
This example specifies to ETVerify a CPU Actions file called myChip_TAPTest.cpuWR. The
location of the file is hardcoded and is inside a directory called CPUInterfaceFiles located in the
same directory where the TAP gtool_info exists.
CPUVerify (Test1) {
TestStep (0) {
CPUActionsFile: myChip_TAPTest.cpuWR;
}
}
Figure A-12 illustrates an example CPU Actions file that is created by ETAssemble to certify
the proper interaction between your CPU hardware and the CPU interface of the TAP. As you
can see, it uses tasks called CPUComment, CPUWrite, CPURead, and CPUWaitCycles. Those
tasks in turns call the task defined in CPUReadWriteSetupTasksFile.
Figure A-12. Example CPU Actions File Created by ETAssemble

CPUComment
("****************************************************************");
CPUComment (" This testbench exercises the TAP features through the CPU
");
CPUComment (" Interface. If you are able to simulate it with while using ");
CPUComment (" your real CPU interface, and you get no miscompares then ");
CPUComment (" your CPU interface is capable of accessing all embedded Test
");
CPUComment (" resources controllable by the MentorGraphics TAP.
");
CPUComment (" Be careful not to enable test modes that will affect the state");
CPUComment (" of your CPU controller. For example, don't start a logicBist ");
CPUComment (" controller which test the CPU controller itself. Also, don't ");
CPUComment (" raise SelectJtagInput nor SelectJtagOutput if you CPU pins ");
CPUComment (" have boundary scan cells. ");
CPUComment (" ");
CPUComment
("****************************************************************");
CPUComment (" Asynchronous Reset Test ");
CPUComment
("****************************************************************");
CPUComment ("");
CPUComment ( "* Verifying that the ByPass is selected after an asynchronous TAP
reset as there is no DevID");
CPUComment ( " Loading the Bypass register with 1");
CPUComment ( " data while expected scanout value is 0");
CPUComment (" This will be perform with 2 WriteReads. ");
CPUComment (" The tdi data will be preceded by this value: 1000000000000000001
");
CPUComment (" The padding value will be compared when it comes out ");
CPUComment (" after having shifted through the bypass register. ");
CPUComment (" ");
CPUComment (" ");

September 2017
CPUActionsFile
CPUComment (" - Write Read 1 ");

CPUComment (" Write Data = {toPauseDR, 10'b0000000001}");
CPUComment (" Expected Read Data = {2'bx1, 10'b0000000010}");
CPUWaitCycles (20);
CPURead ({2'bx1,10'b0000000010},
"TDI[8] on ReadData[9]",
"BYPASS[0] on ReadData[0]"
);
CPUComment (" Write Data = {toRTI, 10'b1100000000}");
CPUWaitCycles (20);
CPURead ({2'bx1,10'b1000000000},
"TDI[9] on ReadData[0]"
);
CPUComment (" ");

CPUComment
("****************************************************************");
CPUComment (" Internal DR register Test ");
CPUComment
("****************************************************************");
CPUComment ("");
CPUComment ( "* Verifying that the IntDR register is selected by the
INT_DR_SELECT");
CPUComment ( " opcode. ");
CPUComment ("");
CPUComment ( " Loading the IR register with 1...1101 while expecting ");
CPUComment ( " the first two bits of the IR to come out with the mandatory");
CPUComment ( " 01 code." );
CPUComment (" The tdi data will be proceeded by this value: 10 ");
CPUComment (" after having shifted through the instruction register. ");
CPUComment (" ");
CPUComment (" ");
CPUComment (" Write Data = {toPauseIR, 10'b1111110110}");
CPUComment (" Expected Read Data = {2'bx1, 10'bxxxxxxxx01}");
CPUWaitCycles (20);
"IR[9] on ReadData[9]",

September 2017
CPUActionsFile
"IR[0] on ReadData[0]"
);
CPUComment (" Expected Read Data = {2'bx1, 10'b10xxxxxxxx}");
CPUWaitCycles (20);
CPURead ({2'bx1,10'b10xxxxxxxx},
);
CPUComment ("");
CPUComment ( "* Performing a Flush test through the IntDR register");
CPUComment ( " Loading the Int DR register with all 0's");
CPUComment (" after having shifted through the IntDR register. ");
CPUComment (" ");
CPUComment (" Expected Read Data = {2'bx1, 10'bxxxxxxxxxx}");
CPUWaitCycles (20);
CPURead ({2'bx1,10'bxxxxxxxxxx},
"INT_DR[9] on ReadData[9]",
"INT_DR[0] on ReadData[0]"
);
CPUComment (" Expected Read Data = {2'bx1, 10'bxxxxxxxxxx}");
CPUWaitCycles (20);
CPURead ({2'bx1,10'bxxxxxxxxxx},
);
CPUComment (" Expected Read Data = {2'bx1, 10'b1001xxxxxx}");
CPUWaitCycles (20);
CPURead ({2'bx1,10'b1001xxxxxx},

September 2017
CPUActionsFile
);
CPUComment (" ");

CPUComment
("****************************************************************");
CPUComment (" Synchronous TAP Reset ");
CPUComment
("****************************************************************");
CPUComment (" ");
CPUComment ("* Resetting the TAP with a 5 TMS sequence");
CPUComment (" This is done with a two write commands");
CPUComment (" One to issues the toTestLogicReset command");
CPUComment (" and one to issue the toRunTestIdle command");
CPUComment ("");
CPUComment (" - Write 1 ");
CPUComment (" Write Data = {toTLR,0000000000}");
CPUWrite ({toTLR,10'b0});
CPUComment (" - Waiting 5 CPU interface clock cycles");
CPUWaitCycles (5);
CPUComment (" - Write 2 ");
CPUComment (" Write Data = {toRTI,0000000000}");
CPUComment (" ");
CPUWaitCycles (5);
CPUComment ( "* Verifying that the ByPass is selected after a synchronous TAP
reset as there is no DevID");
CPUComment ( " Loading the Bypass register with 1");
CPUComment (" The tdi data will be proceeded by this value: 1000000000000000001
");
CPUComment (" ");
CPUWaitCycles (20);
CPURead ({2'bx1,10'b0000000010},
);
CPUWaitCycles (20);
CPURead ({2'bx1,10'b1000000000},

September 2017
CPUActionsFile
);
CPUComment (" ");

CPUComment
("****************************************************************");
CPUComment ("Bypass Register ");
CPUComment
("****************************************************************");
CPUComment ("");
CPUComment ( "* Loading the Bypass Opcode into the Instruction");
CPUComment ( " Loading the IR register with all 0's expecting ");
CPUComment ( " the first two bits of the IR to come out with the mandatory");
CPUComment ( " 01 code." );
CPUComment (" after having shifted through the instruction register. ");
CPUComment (" ");
CPUComment (" Write Data = {toPauseIR, 10'b0000000010}");
CPUComment (" Expected Read Data = {2'bx1, 10'bxxxxxxxx01}");
CPUWaitCycles (20);
);
CPUComment (" Expected Read Data = {2'bx1, 10'b10xxxxxxxx}");
CPUWaitCycles (20);
CPURead ({2'bx1,10'b10xxxxxxxx},
);
CPUComment (" ");

CPUComment ("* Verifying that the ByPass is selected");
CPUComment ( " Loading the Bypass register with $BypassWriteValue");
CPUComment (" The tdi data will be proceeded by this value: 1000000000000000001
");
CPUComment (" ");

September 2017
CPUActionsFile

CPUWaitCycles (20);
CPURead ({2'bx1,10'b0000000010},
);
CPUComment (" Write Data = {toRTI, 10'b?100000000}");
CPUWrite ({toRTI,BypassWriteValue,9'b1100000000});
CPUWaitCycles (20);
CPURead ({2'bx1,10'b1000000000},
);
Related Information
CPUVerify -svf
TestStep svf2cpu Utility
CPUReadWriteSetupTasksFile CPUInterface in the manual ETPlanner Tool
Reference
Variable The CPU Interface in the manual Embedded
Test Hardware Reference

September 2017
CPUReadWriteSetupTasksFile
The CPUReadWriteSetupTasksFile property specifies the name of a file containing the
definitions of Verilog tasks which implement the CPU Read and Write commands as well as a
Setup Task that initializes the CPU interface.
When you run ETAssemble at the chip level, and you have requested that the TAP controller be
created with a CPUInterface, a directory called CPUInterfaceFiles will be created inside the
ETAssemble output directory. The directory will contain a file called
<designName>.LVExampleTasksFile which defines the Verilog task needed to operate the TAP
through the CPUInterface. The four defined tasks are CPUWriteMethod, CPUReadMethod,
CPUSetupMethod and CPUWaitCycles. The example tasks do not operate the TAP
CPUInterface through your real CPU hardware but instead simply use hierarchical force and
compare statements to drive the CPUInterface ports on the TAP module itself. This is just to
show you how the CPUInterface ports are to be operated by your real CPU interface hardware.
You have to create your own version of the task files that perform Read and Write operations
using your real CPU hardware.
You can use the default <designName>_TAPTest.cpuWR file created by ETAssemble to
validate and debug your custom tasks file.
Syntax
CPUReadWriteSetupTasksFile: <fileName>;
where fileName is a name of the file containing the CPUWriteMethod, CPUReadMethod,

CPUSetupMethod, and CPUWaitCycles tasks.
You do not specify a directory name with the file name. The location of the
CPUReadWriteSetupTasksFile is hardcoded to be in a directory called CPUInterfaceFiles
found in the directory where the TAP gtool_info file is described to be in the .tcm file.
When running Early Verifications inside the ETAssemble directory of the lvWorkSpace, this
directory exists in the output directory of ETAssemble which defaults to outDir. During make
lvdb, the CPUInterfaceFiles directory is copied into the LVDB, and ETVerify later reads
CPUActionsFile from the LVDB.

September 2017
Note
If you are editing your task files and want to simulate with them without having to
recreate the LVDB each time, you can run make testbench with the extra option
-useLVDB Off. This will instruct the makefile target to use the local files instead of the
ones copied into the LVDB.
You can also type setenv useLVDB off in your shell, and the local files will be used until
you undefine the variable.
This feature is only available in the ETAssemble directory when LogicTest is not used.
When LogicTest is used, then the makefile in ETAssemble directory already only uses
the local files.
Default Value
None
Usage Conditions
This property is used in the CPUVerify wrapper.
• You point to a CPUReadWriteTasksFile that exist within the CPUInterfaceFiles directory
located beside the TAP gtool_info file.
• You initially can use the example CPUReadWriteSetupTasksFile created by ETAssemble
but you eventually need to point to your own custom version that operates the TAP CPU
interface through your real CPU hardware.
Example
This example specifies to ETVerify a file called myChip.LVExampleTasksFile as the
CPUReadWriteTasksFile. The location of the file is hardcoded and is inside a directory called
CPUInterfaceFiles located in the same directory where the TAP gtool_info exists.
CPUVerify (Test1) {
CPUReadWriteSetupTasksFile: myChip.LVExampleTasksFile;
}
Figure A-13 illustrates the contents of the CPUReadWriteSetupTasksFile automatically

created by ETAssemble when the CPU DataRegWidth is specified as 12.
You will notice that the tasks are using hierarchical forces and compare on the CPUInterface
TAP pins. Notice how the CPUWriteMethod task provides the CPUInterface_DataIn values
one clock cycle prior to the rising edge of CPUInterface_WriteEnable and keeps
CPUInterface_WriteEn high for 3-clock cycles.

September 2017
Figure A-13. Content of Example CPUReadWriteTasksFile Created by

ETAssemble
task CPUWriteMethod;
input [11:0] WriteData;
begin
#50;
force TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_Clock = 1'b1;
force TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_DataIn =
WriteData;
#50;
#50;
force TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_WriteEnable = 1'b1;
#50;
#50;
#50;
#50;
#50;
#50;
#50;
end
endtask
task CPUReadMethod;
output [11:0] ReadData;
begin
ReadData = TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_DataOut;
end
endtask
task CPUSetupMethod;
begin
force TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_Enable = 1'b1;
force TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_ResetN = 1'b1;
#50;
#100;
#100;
#50;
#50;
end
endtask
task CPUWaitCyclesMethod;
input [31:0] Cycles;
begin
repeat (Cycles) begin
#50;
force TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_Clock =
1'b1;
#50;
force TB.DUT_inst.CHIP.LVISION_JTAP_INST.CPUInterface_Clock =
1'b0;
end
end
endtask

September 2017
Figure A-14 illustrates an example of a user-created CPUReadWriteSetupTasksFile which

describes the Read and Write methods through a 4-bit CPU bus. The example CPU bus protocol
consists of two 4-bit words comprising the 2-bit command and the 6-bit address followed by 3
4-bit words containing the 12-bit Read or Write data value. Notice how the CPUClk is not
generated by the tasks but instead how ‘always @ (negedge CPUClk)’ statements are used to
provide data that meets setup and holds with respect to the rising edge of CPUClk.
The CPUSetupTask resets the CPU bus hardware and writes to a CPU register to activate the
CPUInterface of the TAP.
Finally, note how the example CPUWaitCycles task multiplies the input cycles count by 8. This
is because in this example, the CPU clock operates at 150MHz, and the TAP CPUInterface
clock is operated by a divided by 8 version of the CPU clock in order to have the TAP operates
in the 20MHz range.
Note
Notice how the pin names referenced in the task file, such as cpuData, have a _BID
suffix. This is needed when you want to drive a bidirectional pin. You use
<pinName>_BID to set a bidirectional pin and <pinName> to observe it. If the pin was a
simple input pin instead of a bidirectional pin, then you would set it with <pinName>
without the _BID suffix.
Figure A-14. Content of Example CPUReadWriteTasksFile Created by a User

reg [5:0] TAPCPUAddress;
parameter cpuRead = 2'b01;
parameter cpuWrite = 2'b10;
parameter cpuIdle = 2'b00;
parameter cpuReset = 2'b11;
task CPUWriteMethod;
input [11:0] WriteData;
begin
@ (negedge DUT_inst.CHIP.cpuClk);
//issue Write comamnd at address 000011 which is the register connected to
the TAP
cpuData_BID = {TAPCPUAddress[1:0],cpuWrite};
cpuData_BID = TAPCPUAddress[5:2];
//Send the 3 4-bit packets of data
cpuData_BID = WriteData[3:0];
cpuData_BID = {2'b00,cpuIdle};
end
endtask
task CPUReadMethod;
output [11:0] ReadData;
begin
cpuData_BID = {TAPCPUAddress[1:0],cpuRead};
cpuData_BID = TAPCPUAddress[5:2];
//turn off external drivers to allow data to come out

September 2017
cpuData_BID = 4'bzzzz;
//Read the 3 4-bit packets of data
ReadData[3:0] = cpuData;
cpuData_BID = {2'b00,cpuIdle};
end
endtask
task CPUSetupMethod;
begin
cpuRstn_BID = 1'b1;
cpuRstn_BID = 1'b0;
cpuRstn_BID = 1'b1;
cpuData_BID = 4'b0;
// Set TAPCPUAddress to access pllControl config register

TAPCPUAddress = 6'b000000;
CPUComment("Setting PLL ratio to 7");
CPUWrite(12'b00111);
CPUComment("Enabling the PLL");
CPUWrite(12'b10111);
// Set TAPCPUAddress to access cpu2TAP config register
CPUComment("Enable the TAP access from the cpu and");
CPUComment("programme the cpu clock divider ratio to 1/8");
CPUWrite(12'b1011);
CPUComment("Wait 5 CPU interface clock cycles");
CPUWaitCycles(10);
//set TAPCPUAddress such that all next Read/Wriate are to/from the TAP itself
end
endtask
task CPUWaitCyclesMethod;
input [31:0] Cycles;
begin
repeat (8*Cycles) begin
end
end
endtask
Figure A-15 illustrates an example of the complete CPUVerify wrapper that would be used to
simulate a memory BIST pattern through a real CPU interface. Notice how the cpuClock and
the other system clock needed to operate the memory BIST controller are enabled using the
DefineClock property.
Figure A-15. Example CPUVerify Wrapper
CPUVerify (allMembist) {
PatternName: cpu_allMembist;
SimulationScript: lowerLevels_sim.script;
ClockPeriods {
cpuClk: 5ns;
clk: 20ns;
}
DefineClock (P): cpuClk;
DefineClock (P): clk;

September 2017
CPUReadWriteSetupTasksFile: chip.realTasksFile;
TestTimeMultiplier: 1.0;
TestStep (1) {
CPUActionsFile: allMembist.cpuWR;
}
}
Related Information
CPUVerify svf2cpu Utility
CPUActionsFile CPUInterface in the manual ETPlanner Tool
Reference
DefineClock CPUInterface in the manual Embedded Test
Hardware Reference
Variable

September 2017
CPUVerify
CPUVerify
The CPUVerify wrapper is one of the wrappers of the Specific Verification Sections in the
configuration file. This wrapper enables you to generate simulation test benches to verify the
proper access of the TAP and BIST circuitry through the TAP CPUInterface.
This wrapper introduces wrappers and properties for defining items such as the CPUActionsFile
name and the CPUReadWriteSetupTasksFile name.
Syntax
For the complete syntax of the wrapper, refer to the CPU Verification Section.
Related Information
CPUActionsFile CPUInterface in the manual ETPlanner Tool
Reference
CPUReadWriteSetupTasksFile TAP: Connection in the manual ETAssemble
Tool Reference
Variable The CPU Interface in the manual Embedded
Test Hardware Reference
svf2cpu Utility

September 2017
CustomVerify
CustomVerify
The CustomVerify wrapper is used for the following purposes:
• To test and debug your initialization sequence defined by the UserDefinedSequence
wrapper.
• To create a stand-alone pattern that can be run on a tester with a .pgsl_uds or .svf file.
There can be multiple CustomVerify wrappers; however, each wrapper must have a unique
name—each wrapper generates a test bench of its own.
Syntax
For the complete syntax for the wrapper, refer to the Custom Verification Section.
Example1
This example defines a CustomVerify wrapper named EnableTAP which creates a test bench
with the actions defined in UserDefineSequence named EnableTAP.
CustomVerify (EnableTAP) {
PatternName: customv_EnableTAP;
SimulationScript: chip_sim.script;
PreTAPUserDefinedSequence: EnableTAP;
}
Example2
This example defines a CustomVerify wrapper named EnableTAP_PLLX7 which creates a test
bench with the actions defined in UserDefineSequence named EnableTAP followed by the
actions defined in UserDefinedSequence PLLX7. An asynchronous free running clock called
clk is started with a period of 30ns. This clock serves as the reference to the PLL which is being
programmed with a multiplication factor of 7.
CustomVerify (EnableTAP_PLLX7) {
PatternName: customv_EnableTAP_PLLX7;
SimulationScript: chip_sim.script;
UseAsyncClocks: On;
DefineClock (P): clk;
ClockPeriods {
clk: 30ns;
}
TCKPeriod: 100ns;
PostTAPUserDefinedSequence: PLLX7;
}

September 2017
DataBitNo
DataBitNo
The DataBitNo property selects the last bit of the received data on which to perform the
MultiPhaseSamplingError test, as selected by the SerdesTest property.
Syntax
DataBitNo: <int>;
Default Value
Usage Conditions
For the following tests, the measurement is performed on the specific bit in receiver word
selected by DataBitNo: AverageSlewRate, AverageVoltage, DutyCycleDistortion,
JitterFromCDF, Jitter, LFJitterFromCDF, MeanSampleInstant,
TransitionDensityDependentDelay.
In case of MultiPhaseSamplingError test, the measurement is performed for every bit from #0
up to the bit selected by DataBitNo.
Example
The following will perform a MultiPhaseSamplingError test for controller BP1, measuring the
error from bit 0 up to bit 9.
etv (MyChip) {
SerdesVerify (MPSE) {
TestStep (MPSE_10) {
SerdesTest: MultiPhaseSamplingError;
Controller (BP1) {
...
DataBitNo: 9;
LowerLimit: -10.0;
UpperLimit: 10.0;
}
}
}
}
}
Related Information
Controller SerdesTest
SerdesVerify TestStep

September 2017
DataCompareTimeSlots
The DataCompareTimeSlots property is used to select the clock cycles in which the
StrobeDataOut is enabled during a read operation. This property should be used when running
Stop-on-Nth diagnostic on memories that have a StrobeDataOut on consecutive clock cycles
during a read operation. The Stop-on-Nth error diagnostic mode needs two clock cycles upon
detecting an error before freezing the state of the memoryBist controller and memory interfaces.
This property guarantees that the state of the controller is properly preserved when using
operation sets that have consecutive StrobeDataOut in the read operation.
Syntax
DataCompareTimeSlots: (All) | Odd | Even;
Default Value
The default value is All.
Usage Conditions
This property is valid only in the MembistPVerify: TestStep: Controller and
MembistVerify: TestStep: Controller wrappers.
• All — Used for Stop-on-Nth error diagnostic using an operation set that does not have
StrobeDataOut on consecutive or clock cycles.
• Odd — Used to enable the StrobeDataOut on the odd clock cycles during Stop-on-Nth
error diagnostic mode.
• Even — Used to enable the StrobeDataOut on the even clock cycles during Stop-on-Nth
error diagnostic mode.
FailureLimit must be set greater to 0.
Example
The following will perform a Stop-on-Nth error diagnostic test bench and will halt the
memoryBist controller on the 10th error that occurred on an odd clock cycle:
etv (MyChip) {
MembistPVerify (CLKA) {
TestStep (SOE_1) {
Controller (BP1_SOE_ODD) {
FailureLimit : 10;
DataCompareTimeSlots : Odd;
}
}
}
}

September 2017
Related Information

September 2017
DataGenerator
DataGenerator
The DataGenerator wrapper groups the properties of the data generator that require
initialization prior to execution of the MicroProgram. The specified values override the values
defined in the selected algorithm.
Syntax
The following syntax summarizes the contents of the DataGenerator wrapper:
DataGenerator {
InvertDataWithRowBit: (None) | r[<x>];
InvertDataWithColumnBit: (None) | c[<x>];
} //end of DataGenerator wrapper
Usage Conditions
This wrapper is used in the MembistPVerify: Controller wrapper.
This wrapper is applicable when the algorithm is selected using the HardCodedAlgorithm or
SelectLibraryAlgorithm property.
Related Information
Algorithm in the Tessent MemoryBIST User’s Controller
and Reference Manual
HardCodedAlgorithm InvertDataWithColumnBit
InvertDataWithRowBit LoadExpectData
LoadWriteData MembistPVerify
SelectLibraryAlgorithm

September 2017
DebugMode
DebugMode
The DebugMode property enables a mode on the Tessent MemoryBIST controller that allows
functional system debug. For more information, see the appendix Functional Debug Memory
Access in the Tessent MemoryBIST User’s and Reference Manual.
Syntax
DebugMode: On | (Off);
Default Value
Usage Conditions
The FunctionalDebugMode property must be enabled in ETPlanner.
Related Information
Manual
FunctionalDebugMode

September 2017
DefineClock
DefineClock
The DefineClock property enables you to specify pins on your design that you want to be
driven with a clock. Use this property for each clock you want to define. Use the DefineClock
(N) property immediately after its corresponding DefineClock (P) property to define the
negative pin of a differential clock pair.
• Clocks use the clock period defined by the ClockPeriod property when the UseAsyncClocks
property is set to Off.
• Clocks use the period defined in the ClockPeriods wrapper when the UseAsyncClocks
property is set to On. When UseAsyncClocks is On, the pinmap validation rules are relaxed
in SiliconInsight to allow any un-contacted pins that exist in the design to be declared as
custom asynchronous clocks in the etManufacturing file. You must list these pins in the
ClockPeriods wrapper and should also have DefineClock(P) (and also a “DefineClock(N)
for differential clocks) in the LogicBIST verify wrapper in the etManufacturing file.
Syntax
where pinName specifies the name of the pin on your design that you want to be driven with a
clock.
Default Value
None
Usage Conditions
• CPUVerify
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• SerdesVerify
• ScanVerify

September 2017
DefineClock
• The specified pin must be an input or inout port.

• The DefineClock (N) property must follow the DefineClock (P) property.
Example
This example defines a single ended clock on port CLKA and defines a differential clock on the
pair of pins CLKBP and CLKBN.
etv (MyDesignA) {
CustomVerify (1) {
DefineClock (P): CLKA;
DefineClock (P): CLKBP;
DefineClock (N): CLKBN;
}
}
The following example shows how to declare the clock periods and the clocks when the
UseAsyncClocks property is set to On:
ClockPeriods {
pad_lc_pll0_byp_clk25 : 20.0ns;
pad_core_pll_frefp : 20.0ns;
pad_core_pll_frefn : 20.0ns;
pad_lc_pll0_refclk_n : 20.0ns;
pad_lc_pll0_refclk_p : 20.0ns;
}
DefineClock(P) : pad_core_pll_frefp;
DefineClock(N) : pad_core_pll_frefn;
DefineClock(P) : pad_lc_pll2_refclk_p;
DefineClock(N) : pad_lc_pll2_refclk_n;
DefineClock(P) : pad_lc_pll0_byp_clk25;
Related Information
ClockPeriod UseAsyncClocks
ClockPeriods Summary of Specific Verification Sections

September 2017
DesignPin
DesignPin
The DesignPin wrapper enables you to specify for each design pin whether or not it is contacted
to a tester channel during test pattern execution. If a design pin is contacted to a tester channel,
you use the contents of this wrapper to specify the capabilities of this tester channel.
Syntax
DesignPin (<pinName>){
Control:(None) | TwoStateWeak | TwoStateStrong |
Observation:(None) | TwoState | ThreeState;
}
where pinName must be a top-level pin of the design, excluding TAP interface signals (tck, trst,
tdi, tms, and tdo).
Default Value
None
Usage Conditions
This wrapper is used in the JtagVerify: ContactedPins wrapper.
If a non-TAP top-level pin of the design does not have a DesignPin wrapper and the
ContactedPins wrapper exists, then the pin is considered not contacted. An empty DesignPin
wrapper has the same effect as the absence of the DesignPin wrapper for the specified pin.
Example
This example specifies the observation and control capabilities of the tester channels connected
to pins Read and Enable. All top-level design pins omitted are considered not contacted.
etv (MyDesignA)
JtagVerify (ETC) {
ContactedPins {
DesignPin (Read){
}
DesignPin (Enable){
}
}
TestStep(1) {
}
}
}

September 2017
DesignPin
Related Information
ContactedPins Observation
JtagVerify

September 2017
DeviceId
DeviceId
The DeviceId property is used for multi-chip modules that consist of two or more die packaged
into a single part. Each die will have an IEEE 1149.1 TAP module that is daisy-chained with the
next die. ETVerify will generate test patterns to address the die-under-test. The DeviceId is 32
bits wide and is made up of four parts:
• 4 bits are the RevisionCode, which is the version number defined in the TAP wrapper of
the .etassemble configuration file.
• 16 bits are the DeviceIdCode, which is the part number defined in the TAP wrapper of
the .etassemble configuration file.
• 11 bits are the ManufacturersIdCode that is defined in the TAP wrapper of the
.etassemble configuration file.
• First bit is always a 1, as defined by the IEEE 1149.1 standard.
Note
If you have a BSDL file that describes this TAP, you can find these 32 bits in the
IDCODE_REGISTER section.
Syntax
Default Value
None
Usage Conditions
This property is used, along with the BypassOpCode property, in the following wrappers inside
the Global Section:
• JTAPAccess:PreAmble:Tap
• JTAPAccess:PostAmble:Tap
The DeviceId property is mandatory only if the preamble or postamble TAP has a device ID
register. If you do not want to verify the device ID, you can specify 32’hXXXXXXXX.
Otherwise, the device ID is verified in the TestLogicReset test (refer to the JtagVerify Usage
section in the RunTest property description).
Example
Refer to Figure A-16 for an example of the DeviceId property.
Related Information
JTAPAccess Tap

September 2017
DeviceId
PreAmble PostAmble
BypassOpCode

September 2017
Diagnostic
Diagnostic
The sections below provide detailed information on the following usage of the Diagnostic
property:
• “MembistPVerify and MembistVerify Usage” on page 283
The Diagnostic property enables you to specify the type of simulation test bench to generate.
Syntax

• On — specifies the generation of a test bench with a diagnostic test step that freezes the state
of the circuit after the application of the last vector and serially scans out the contents of
each flip-flop.
• Off — specifies the generation of normal test bench.
Default Value
Usage Conditions
• For pre-5.0 logic BIST controllers, this option requires a chip-level clock prescaler with
built-in diagnostic capabilities.
• When you set Diagnostic to On, you can specify only one controller in the test step.
• This option cannot be used if the controller is accessed through the Direct Pin interfaCe.
• The RunMode property must be set to RunTimeProg when using diagnostic mode.
Example
The syntax below includes a diagnostic property:

September 2017
Diagnostic
etv (MyDesignA) {
LogicbistVerify (ETC_dignostic) {
PatternName: logivbistv_diagnostic_ETC;
SimulationScript: ETCPsim.script;
UseAsyncClocks: Off;
BurstCyclesWithShiftClock: On;
Diagnostic: On;
Controller (BP0) {// ETC_LVISION_LOGICTEST
ShiftClkSelect: TCK;
StartVector: 1;
EndVector: 2;
}
}
}
}
Related Information
TestStep RunMode
LogicbistVerify

The Diagnostic property configures the memory BIST controller for failure diagnostics.
If the controller was generated with the ETPlanner property CompStat set to SharedWithGo, the
compare status will be routed to the GO output port. The controller GO_ID registers, associated
with memories with the ETPlanner property LocalComparators set to No, will capture cycle-
by-cycle comparator status.
In addition, for memories with the ETPlanner property LocalComparators set to Yes, the
interface GO_ID registers will capture cycle-by-cycle comparator status.
Syntax

• On — configures the memory BIST controller for diagnostic mode.
• Off — configures the memory BIST controller for Go/NoGo tests.
Default Value
Usage Conditions
This property is used in the Controller wrapper of the following types of verification:

September 2017
Diagnostic
• MembistPVerify
• MembistVerify
• This property is meaningful only if the ETPlanner property CompStat set to Yes or
SharedWithGo when you generate the controller.
• When Diagnostic is set to On, you must also set the CompareCmpStat property to On.
• This property is meaningful only when one or more RAMs are tested by the memory BIST
controller.
Example
The following syntax enables the controller for CompStat diagnosis.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
Diagnostic: On;
}
}
}
}
Related Information
CompareCmpStat MembistVerify
Controller CompStat in the manual ETPlanner Tool
Reference
MembistPVerify LocalComparators in the manual ETPlanner
Tool Reference

September 2017
DisableCapture
DisableCapture
The DisableCapture property enables you to force ScanEnable in all ScanEnable controllers
high during the capture cycle. Using DisableCapture can help to diagnose the scan chains burst
rotation independently of the capture cycle.
Syntax

• On — disables the capture cycle of all flops.
• Off — does not disable the capture cycle of all flops.
Default Value
The default is Off.
Usage Conditions
• ScanVerify: TestStep: Controller
Example
The following example shows a LogicBIST diagnostic test that has the capture cycle disabled.
LogicbistVerify (top_diagnostic) {
...
Controller (BP0) {
DiasableCapture: On;
Diagnostic : On;
StartVector: 1;
EndVector : 1;
}
}
}
Related Information
ScanVerify TestStep

September 2017
DisableClocks
DisableClocks
The DisableClocks property specifies whether to disable or not the clocks of a specific core
through the WTAP settings. This property is used to reduce activity and power consumption of
inactive cores when running logic BIST tests on other cores.
Syntax

• On — disables the clocks of a specific core.
• Off — does not disable the clocks of a specific core.
Default Value
The default is Off.
Usage Conditions
This property is used in the LogicbistVerify and ScanVerify wrappers on the following two
levels:
• WTAPSettings
• TestStep: WTAPSettings
Example
This example specifies to ETVerify to disable clocks on WTAP controller BP3 for the whole
test and to disable the clocks on WTAP controller BP5 only for TestStep (Core1).
etv (MyDesignA) {
LogicBistVerify (1) {
DisableClocks: On;
}
TestStep (Core1) {
DisableClocks: On;
}
}
}
Related Information
LogicbistVerify TestStep
ScanVerify WTAPSettings

September 2017
DisableMemoryList
DisableMemoryList
The DisableMemoryList property allows you to disable one or more memories tested in parallel
within a controller step.
Syntax
DisableMemoryList: <MemIDList>;
where MemIDList is a comma-separated list of valid memory ID tested by the controller. The
memory ID name(s) must belong to the BIST controller step specified by the
FreezeStepNumber property.
For a list of memory ID names per controller step, refer to the .summary file in the LVDB.
Default Value
If DisableMemoryList is not specified, then all memories will be enabled.
Usage Conditions
This property is used in the MembistPVerify: TestStep: Controller wrapper.
• The controller must be generated with the ETPlanner property SelectiveParallelMemoryTest
set to Yes.
• The RunMode property must be set to RunTimeProg.
• The FreezeStep property must be set to On.
• The FreezeStepNumber property must specify a valid BIST step number.
Example
This example excludes memories MEM2 and MEM3 in BIST Step 0 from memory test.
TestStep (0) {
Controller (BP0) {
FreezeStep: On;
FreezeStepNumber: 1;
DisableMemoryList: MEM2, MEM3;
}
}
Related Information
Controller RunMode
FreezeStep TestStep
FreezeStepNumber SelectiveParallelMemoryTest in the manual

September 2017
DisableMemoryList
MembistPVerify

September 2017
DRStatus
DRStatus
The DRStatus property enables you to compare the captured value on the DRStatus port of the
TAP controller to an expected value.
Syntax
DRStatus (<index>): 1 | 0 | x;

• index — is an integer between 0 and L-1 where L is the maximum number of internal DR
bits.
• 1 — specifies the compared value on the DRStatus port of the TAP controller with an
expected value of 1.
• 0 — specifies the compared value on the DRStatus port of the TAP controller with an
• x — indicates to stop comparing a value on the DRStatus port of the TAP controller.
Default Value
None
Usage Conditions
The DRStatus property is used in the TestStep wrapper for the following types of verification:
Table A-2. DR Status Usage Conditions

Usage Conditions User-Defined Memory BIST SerdesTest
Sequence Verification Verification
Section Section Section
The length and composition of the ✓
INT_DR register can be found in the
HSDL file.
This property is only meaningful with the ✓ ✓
TAP protocol.
Example
This example instructs ETVerify to compare the captured value on the DRStatus port of the
TAP controller to an expected value of 0.
etv (MyDesignA) {
UserDefinedSequence (MySequence) {
TestStep (0) {
DRStatus(12): 0;
}
}
}

September 2017
DRStatus
Related Information
TestStep SerdesVerify
MembistPVerify UserDefinedSequence
MembistVerify

September 2017
DUTLoopBacks
DUTLoopBacks
The DUTLoopBacks wrapper specifies one or more signal loopbacks on the pins of the module
under test. This is meant to model any loopbacks that might be present on the DUT card such as
an off chip RC circuit. It can also be used to simulate sub-modules where a signal comes out of
the module and will be returned by a module above. An example of such a signal is a clock that
comes out of a module to go through a distribution network and then come back.
Syntax
DUTLoopBacks {
//Repeat for each loopback signal
}

• inputPinName — is a valid input or inout pin name on the module under test.
• outputPinName — is a valid output or inout pin name on the module under test.
Default Value
None
Usage Conditions
This wrapper is used in the following verification wrappers:
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• SerdesVerify
• ScanVerify
• WTAPVerify
• This wrapper is meant to model any loopbacks that might be present on the DUT card such
as an off-chip RC circuit. It can be used to simulate sub-modules where a signal comes out

September 2017
DUTLoopBacks
of the module and is returned by another module. An example of such a signal is a clock that
comes out of a module to go through a distribution network then returns.
• This wrapper is ignored unless the UseDUTLoopBacks property is set to On.
Example
This example specifies that the generated test bench uses a loopback signal from pin outd to pin
ina.
etv (MyDesignA) {
PinSettings {
IN1A: 0;
}
DUTLoopBacks {
ina <= outd;
}
}
}
}
Related Information
JtagVerify ScanVerify
LogicbistVerify UseDUTLoopBacks
MembistPVerify WTAPVerify
MembistVerify

September 2017
EffectiveSlowedDownFrequency
The EffectiveSlowedDownFrequency property enables you to specify the effective frequency
for the number of burst cycles you specified to be slowed down with the
SlowedDownBurstCycles property. Use this property in conjunction with
SlowedDownBurstCycles to create runtime adjustable Burst Clock waveforms.
Syntax
Default Value
None
Usage Conditions
This property can be used directly in the LogicbistVerify or ScanVerify wrapper, or in the
BurstClockController wrapper.
• Specifying EffectiveSlowedDownFrequency directly in the LogicbistVerify or ScanVerify
wrapper is equivalent to repeatedly specifying it in the BurstClockController wrapper for all
• EffectiveSlowedDownFrequency declared in the BurstClockController wrapper has
precedence over EffectiveSlowedDownFrequency declared in the LogicbistVerify or
ScanVerify wrapper.
Note
You can only specify a value of 1/8 for controllers generated with Tessent v9.0 software
or newer; you can only specify a value of 1/3 for controllers generated with versions older
than Tessent v9.0.
• When BurstCyclesWithShiftClock is set to Yes, then EffectiveSlowedDownFrequency is

not supported by the hardware and is ignored.
Example
This example specifies that during the burst phase all clocks will have 2 clock cycles slowed
down to an effective frequency of 1/4, except for BurstClockController (2) which will just
have 1 cycle slowed down at an effective frequency of 1/8.

September 2017
etv (MyDesignA) {
SlowedDownBurstCycles: 2;
EffectiveSlowedDownFrequency: 1/4;
TestStep (1) {
BurstClockController (2) {
EffectiveSlowedDownFrequency: 1/8;
}
}
}
}
}
Related Information
BurstClockController SlowedDownBurstCycles
LogicbistVerify ScanVerify

September 2017
EnableBiraCapture
EnableBiraCapture
The EnableBiraCapture property enables the BISR registers to capture the repair information
contained in corresponding BIRA register. This property is used when the RunMode:
BisrChainAccess is used. The BIRA values are captured in the BISR registers on the first BISR
clock cycle of the BisrChainAccess operation.
Syntax
EnableBiraCapture: On | (Off);
where the valid value is specified as follows:

• On —The BIRA values are captured in the BISR register before the BISR chain is scanned.
• Off—The BIRA values are not captured in the BISR register. The actual values of the BISR
are scanned out.
Default Value
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
This property is used in conjunction with the RunMode: BisrChainAccess. This property is used
with a BISR loader controller only.
Example
This example demonstrates how to capture the BIRA values into the BISR. The
BisrChainRotate is set to On in order to preserve the content of the BISR chain after the
BisrChainAccess operation completes.
TestStep (Step0) {
EnableBiraCapture: On;
}
}
}
Related Information
Controller TestStep

September 2017
EnableBiraCapture
MembistVerify BisrChainRotate

September 2017
EndVector
EndVector
The sections below provide detailed information on the following usage of the EndVector
property:
• “ScanVerify Usage” on page 298
The EndVector property enables you to specify the last logic BIST vector to apply.
Syntax
EndVector: <value> | LastVector | LastDefaultVector
where value is either an integer or an arithmetic expression consisting of integers and keywords
LastVector and LastDefaultVector. The arithmetic expression must be in double quotes.
Default Value
The default is the last available vector.
Usage Conditions
This property is used in the LogicbistVerify: Controller wrapper.
• When you set the EndVector property to a non-default value, the value you specify to the
RunMode property must be RunTimeProg.
• The EndVector property value should be greater than or equal to the StartVector property
value.
Example
This example specifies that the last logic BIST vector to be applied is four vectors after the first
one.
etv (MyDesignA) {
TestStep (1) {
StartVector: “LastVector -4”;
EndVector: LastVector;
}
}
}
}

September 2017
EndVector
Related Information
Controller StartVector
ScanVerify Usage
The EndVector property enables you to specify the last scan vector to apply.
Syntax
EndVector: <value>;
where value is an integer or an arithmetic expression consisting of integers and the keyword
LastVector. The arithmetic expression must be in double quotes.
You can also specify the following keywords for <value>:
• LastChainTestVector
• FirstScanTestVector
You use these keywords to distinguish chain test vectors from scan test vectors, and simulate a
given number of chain test patterns followed by a given number of scan test patterns. For
example:
Example A-1. LastChainTest Vector Example
etv (MyDesignA) {
ScanVerify (ETC) {
TestStep (1) {
StartVector: “LastChainTestVector-3”;
EndVector: “LastChainTestVector+8”;
}
}
}
}
The above example creates a testbench consisting of four last chain test vectors followed by
eight scan test vectors. Division and multiplication operations are supported as well.
Default Value
The default is the last available vector from the test pattern file created by the ETVerify tool.
Usage Conditions

September 2017
EndVector
• The EndVector and StartVector properties enable you to specify the exact number of
vectors that you want to include in the test bench or manufacturing test file.
• The EndVector and StartVector properties can also be used in the ScanVerify: TestStep
wrapper but only when the Mode property is set to Prepare. In this case, there is no
Controller wrapper.
Example
This example specifies that the last ControllerChain scan vector to be applied is 10.
etv (MyDesignA) {
ScanVerify (4) {
PatternName: controllerChain_1;
TCKRatio: 32;
TestStep (ControllerChain) {
ETATestGroupName: scanVerify;
Mode: ControllerChain;
Controller (BP0) { // TOP_LVISION_LOGICTEST
StartVector: 1;
EndVector: 20;
}
}
}
}
Related Information
Controller StartVector
ScanVerify TestStep
Mode

September 2017
ETACompareCmpStat
ETACompareCmpStat
The ETACompareCmpStat property instructs Silicon Insight to monitor the compare status
port of the memory BIST controller during the test.
Syntax
ETATCompareStat: On | (Off);

• On—indicates that the compare status port of the memory BIST controller is to be
monitored throughout the test.
• Off—indicates that the compare status port of the memory BIST controller is NOT to be
Default Value
Usage Conditions
This property is used in the TestStep: Controller wrapper:
• MembistPVerify
• MembistVerify
Example
This example specifies that the compare status port of the memory BIST controller is to be
etv (MyDesignA) {
MembistVerify (1) {
ETATestGroupName:
Multi_asyncTest_retentionTest_1;
ETATCompareStat: On;
}
}
}
Related Information

September 2017
ETATestGroupName
ETATestGroupName
The ETAGroupName property enables you to specify the name of the test group in Silicon
Insight.
Syntax
where testGroupName is a name of the test group in Silicon Insight.

Default Value
None
Usage Conditions
• CustomVerify
• JtagVerify: TestStep
• LogicbistVerify: TestStep
• MembistPVerify: TestStep
• MembistVerify: TestStep
• SerdesVerify: TestStep
• ScanVerify: TestStep
• WTAPVerify: TestStep
Example
This example specifies the name of the test group in Silicon Insight as
Multi_asyncTest_retentionTest_1.
etv (MyDesignA) {
ETATestGroupName: Multi_asyncTest_retentionTest_1;
}
}
}
Related Information
MembistVerify

September 2017
ExpectedROMSignature
The ExpectedROMSignature property can be used to provide the ETVerify tool with the value
of the ROM signature that needs to compared against, off-chip. This property is useful for the
case when the ROM content has changed and the strap module of the memory BIST controller
was not updated.
Syntax
ExpectedROMSignature: BitsValue;
where BitsValue is a hexadecimal number.

Default Value
No defaults are provided.
Usage Conditions
This property is used in the TestStep: Controller: Collar wrapper of the following verification
types:
• MembistPVerify
• MembistVerify
• This property must be defined when the CompareHardCodedSignature property is set to Off.
• You must specify CompareMISR On if you have the ExpectedROMSignature property
specified—CompareHardCodedSignature is automatically turned off (since it is no longer
applicable). If you do not specify CompareMISR On then the final MISR value will not be
compared.
Example
This example specifies the ROM signature for the interface associated with Rom0.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
CompareGoID: Off;
CompareGo: Off;
ReducedAddressCount: Off;
CompareCmpStat: Off;
CompareMISR: On;
Collar (MEM1) {
ExpectedROMSignature: 24’h1F2E3D;
}
}
}
}
}

September 2017
Related Information
Collar MembistPVerify
CompareHardCodedSignature MembistVerify
CompareMISR TestStep
Controller

September 2017
ExpectedStrobeCount
ExpectedStrobeCount
The ExpectedStrobeCount property specifies the value to be compared in the SOE counter
when CompareStrobeCount is On.
During Go/NoGo mode, the SOE counter is enabled to count the number of compare events
applied by the test algorithms. The expected counter value must be computed as the two’s
complement of the modulo (number of compares/counter size). The counter value must be
obtained from simulation or from known good circuits. Setting ExpectedStrobeCount to the
correct value is necessary to obtain a PASS status when CompareStrobeCount is On.
Syntax
ExpectedStrobeCount: <int>;
where the valid range for the integer int is from 0 to 2N-1, where N is the SOE counter bits.
Default Value
Usage Conditions
This property is used in the TestStep:Controller wrapper of the following verification wrapper:
• MembistPVerify
• The CompareStrobeCount property must be On.
• The FailureLimit property must be 0.
• The DebugMode property must be Off.
Examples
This example enables counting the compare events of the default algorithm. At the end of the
test, the SOE counter is extracted and the content is compared to zeros.
TestStep(1) {
Controller(BP0) {
CompareGO : On;
CompareGOID : On;
}
}
}
This example enables counting the compare events of the custom algorithm. At the end of the
test, the SOE counter is extracted and the content is compared to binary value 110.

September 2017
ExpectedStrobeCount
TestStep(1) {
Controller(BP0) {
CompareGO : On;
HardcodedAlgorithm : b2b_xy;
ExpectedStrobeCount : 6;
}
}
}
Related Topics
MembistPVerify FailureLimit
DebugMode CompareStrobeCount

September 2017
ExternalPullUps
ExternalPullUps
The ExternalPullUps property enables you to specify whether or not ETVerify attaches
external pull-ups and pull-downs to specific pins in the Verilog test benches.
Syntax
ExternalPullUps: On | (Off);

• On—instructs ETVerify to generate a test bench that instantiates pull-ups and pull-downs to
the pins with a disable result value set to WEAK1 and WEAK0 in the BSDL description.
• Off—instructs ETVerify not to generate pull-ups and pull-downs.
Default Value
Usage Conditions
This property affects only the Verilog test bench. The ETVerify tool automatically identifies the
pins requiring external pull-ups or pull-downs based on the BSDL description. An external pull-
down or pull-up is attached to all pins with boundary-scan cells that have the disable result field
set to WEAK0 or WEAK1. The test bench emulates the external pull-up and external pull-
downs that exist on the DUT card used on the logic tester.
Example
This example instructs ETVerify to attach pull-ups and pull-downs to pins with a disable value
set to WEAK1 and WEAK0 in the BSDL descriptions.
etv (MyDesignA) {
JtagVerify (1) {
ExternalPullUps: On;
}
}
Related Information
JtagVerify

September 2017
ExtractRepairFuseMap
The ExtractRepairFuseMap property specifies that the repair analysis fuse registers are to be
examined after the BIST run is completed. The fuse registers contain the repair information for
memories with built-in redundancy.
Syntax
ExtractRepairFuseMap: On| (Off);

• On — specifies that the repair analysis fuse registers are sampled and compared against the
zero (0) value.
• Off — specifies that the repair analysis fuse registers are not to be sampled.
Default Value
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
At least one memory tested by the controller must have repair analysis defined in the memory
library file.
Note
The content of the fuse registers are lost after performing this operation. This option
should be set to “Off” if you plan to perform a BIRA to BISR transfer.
Example
The following example specifies that the repair analysis status and fuse registers in controller
SAMPLE are to be examined:
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
ExtractRepairFuseMap: On;
}
}
}
}

September 2017
Related Information
CheckRepairStatus TestStep
MembistPVerify

September 2017
FailureLimit
FailureLimit
The FailureLimit property enables Stop-On-Nth-Error and specifies the number of failures that
the memory BIST controller detects before stopping. This property has three usage scenarios.
To learn more about how to use this property, refer to the “Stop-On-Nth-Error Approach”
section of the “Memory BIST Diagnostics” chapter in the Tessent MemoryBIST User’s and
Reference Manual.
Syntax
FailureLimit: <fCount>;
where fCount is either:

• an integer that specifies the number of failures that the controller detects before stopping.
The value is loaded in the stop-on-error counter and, if present, the failure limit counter.
• the value -1, which indicates that the stop-on-error counter is loaded with the value of the
optional failure limit counter.
• an integer that specifies the “DiagnoseAddress + 1” address where ROM memory is read
during RomDiagnostic operations with the CompareMISR property.
Default Value
The default is 0, which disables the stopping feature.
Usage Conditions
This property is used in TestStep: Controller of the following verification wrappers:
• MembistPVerify
• MembistVerify
• The ETPlanner property StopOnErrorLimit must be greater than 0.
• When you set FailureLimit to its non-default value, you must set the RunMode property to
RunTimeProg.
• When you set FailureLimit to its non-zero value, you should use CompareDiagDataToZero:
On.
Note
When the failure limit is reached and the test stops, it is normal for the Done bit to fail
because the test did not complete.
To run diagnosis on a single memory:
• Set the FreezeStep property to On.

September 2017
FailureLimit
• With the FreezeStepNumber property, specify the step number that corresponds to the
memory to diagnose.
• For a programmable controller, use the DisableMemoryList property to enable a single
memory.
• For a non-programmable controller, use the CompStatIDSelect property to enable a single
comparator.
Example 1
The following syntax specifies that the memory BIST controller stops after detecting six failures
in BIST controller step 2.
etv (MyDesign) {
MembistVerify (DiagPattern) {
TestStep (SOERun) {
Controller (CTRL1) {
FreezeStep: On;
FailureLimit: 6;
}
}
}
}
Example 2
The following syntax specifies that the memory BIST controller stops after detecting the
number of failures indicated by the failure limit counter. The failure limit counter is then
incremented. You can find all failures by iterating on the two test steps for creating a complete
bitmap.
etv (MyDesign) {
MembistVerify (DiagPattern) {
TestStep (SOERun) {
Controller (CTRL1) {
FreezeStep: On;
FailureLimit: -1;
}
}
TestStep (IncrementFL) {
IncrementFailureLimit: On;
}
}
}
Related Information
CompareDiagDataToZero RunMode
Controller TestStep

September 2017
FailureLimit
MembistPVerify StopOnErrorLimit in the manual ETPlanner

Tool Reference
MembistVerify FreezeStep
FreezeStepNumber DisableMemoryList
CompStatIDSelect IncrementFailureLimit
CompareMISR

September 2017
FastScanVerify
FastScanVerify
The FastScanVerify wrapper enables you to specify pattern name to the simulation script
making it easier to manage and run Tessent FastScan generated test benches in Tessent
SoCScan. This wrapper is generated in the .etSignOff file.
Syntax
FastScanVerify (<designName>) {
SimulationScript : <string>;
XXX
}
Usage Conditions
The specified PatternName must match the base name of the generated Tessent FastScan test
bench (without extension) and must be located within the ETVerify output directory.
Example
If Tessent FastScan generates two test benches, outDir/fastscan_ext_elt.v and
outDir/fastscan_parallel_ext_elt.v, then corresponding FastScanVerify wrappers will look as
follows:
etv ( MyDesignA) {
FastScanVerify (elt_parallel){
PatternName: fastscan_parallel_ext_elt;
SimulationScript: elt_sim.script;
}
FastScanVerify (elt_external){
PatternName: fastscan_ext_elt;
SimulationScript: elt_sim.script;
}
}
Related Information
PatternName SimulationScript
ExternalTestMode in the manual ETPlanner
Tool Reference

September 2017
FlattenLoops
FlattenLoops
The FlattenLoops property specifies whether the generated test bench or test vector set is
restricted in terms of any loops they contain.
Syntax

• All — specifies that the test bench or test vector set does not contain any loops. The
generated test bench contains only flat vectors.
• MultiVector — specifies that loops in the generated test bench or WGL output are
constrained to contain a single pattern.
• None — specifies that the test bench or test vector set can contain loops, and these loops can
contain any number of patterns.
Default Value
Usage Conditions
This property is used in the Tester-Related Data Section and all Specific Verification Sections
of the ETVerify configuration file.
This property should be needed only for WGL test vector files. Note that the specification of
this property does not affect CustomVerify.
Example
This example specifies that the test bench or test vector set does not contain any loops. The
generated test bench contains only flat vectors:
FlattenLoops: All;
}
Related Information
Tester-Related Data Section Summary of Specific Verification Sections

September 2017
FlushTest
FlushTest
The FlushTest property enables you to control the application of the flush test. The flush test
sequence applies a checker board pattern to test the contents of the scan chain.
Syntax

• On — turns on the flush test.
• Off — turns off the flush test.
Default Value
Usage Conditions
This property is used in the ScanVerify: TestStep: Controller wrapper.
• Use the FlushTest property to turn on or off the flush test, and set the StartVector and
EndVector properties to 0 such that only the specific flush test is performed.
• As soon as either AsyncSetResetTest, or FlushTest, or RetentionTime is present in the
ScanVerify: TestStep: Controller wrapper, these tests are the only ones that are generated
for the controller. Any other property, other than the AsyncSetResetTest, FlushTest, and
Example
This example specifies that the flush test is to be applied on scan chains controlled by logic
BIST controller BP5.WCP0.
etv (MyDesignA) {
ScanVerify (ETC) {
TestStep (3) {
Controller (BP5.WBP0) {
FlushTest: On;
StartVector: 0;
EndVector: 0;
}
}
}
}
Related Information
AsyncSetResetTest StartVector
Controller RetentionTime

September 2017
FlushTest
RetentionTime EndVector
ScanVerify

September 2017
ForceBidir
ForceBidir
The ForceBidir property enables you to force unused bidirectional pins to the given values after
forceDisable has been asserted in the TAP.
Syntax
ForceBidir: “0”,“1”,“X”,“Z”,“-”,
“00”,“10”,“X0”,“Z0”,“-0”,
“01”,“11”,“X1“,“Z1”,“-X”,
“0Z”,“1Z”,“XZ“,“ZZ”,“-Z”,
“0-”, “1-”,“X-”,“Z-”,“--”;
where valid values can be one (input column) or two (input and output columns) characters with
the value of “0”, “1”, “X”, “Z”, “-”, or any combinations of two of these characters.
Default Value
Default value of this property depends on the how the Type property is specified:
• If you set the Type property to Generic, the ForceBidir property defaults to 0X.
• If you set the Type property to LSI, the ForceBidir property defaults to 0Z.
Usage Conditions
This property is used in the WGL wrapper in Tester-Related Data Section.
If only an input column is specified, the output column defaults to X. This pattern will be
applied to all unused bidirectional pins when the IncludeAllPowerPins property is set to On.
Example
This example specifies that ETVerify forces unused bidirectional pins to the given values after
forceDisable has been asserted in the TAP:
WGL {
Type: LSI;
ForceBidir: 0Z;
}
Related Information
IncludeAllPowerPins WGL
Type

September 2017
ForceDisable
ForceDisable
The ForceDisable property is used to disable, for the entire pattern, all tri-statable output and
bidirectional pins that have boundary-scan cells with 3-state controls and that are not used
during the entire pattern.
When, this property is set to On, the Instruction register bit ForceDis of the TAP controller is
asserted at the beginning of the test pattern.
Syntax

• On — specifies that the TAP is to assert the disable value on the enable control cells
associated with tri-state and bidirectional pads. The disable value forces all IEEE 1149.1-
compliant output and bidirectional pins that are not used during the test to a Z state.
• Off — specifies that the TAP does not tri-state unused outputs during the test. Tri-state and
bidirectional drivers enabled are left under the functional control.
Default Value
The default value is On. This means that for all tests, except those in the JtagVerify and
WTAPVerify wrappers, if this property is not specified then the tri-statable outputs will be
disabled.
Usage Conditions
This property is used in all Specific Verification Sections, except JtagVerify, and WTAPVerify,
and the following usage conditions apply:
Table A-3. ForceDisable Usage Conditions

Usage Conditions Custom Logic BIST
Verification Verification Section
Section
Memory BIST
Verification Section
Scan Verification
Section
SerdesTest
Any pins that are used during the legacy core test will ✓
remain active even when you specify the ForceDisable
property to On.

September 2017
ForceDisable
Table A-3. ForceDisable Usage Conditions

Usage Conditions Custom Logic BIST
Verification Verification Section
Section
Memory BIST
Scan Verification
Section
SerdesTest
The ForceDisable property is ignored when the ✓

SVFName property is specified.
The ForceDisable property is ignored when the ✓
IncludeTapInit property is set to No.
The ForceDisable property is only meaningful when you ✓
are using an IEEE 1149.1 TAP controller. Because the
TAP is instantiated at the chip-level of your design, this
property is only useful for creating chip-level test
benches.
Example
This example specifies not to disable tri-statable pins during a LogicbistVerify test.
etv (TOP) {
LogicbistVerify (TOP) {
PatternName : logicbistv_TOP;
UseAsyncClocks : On;
TckPeriod : 100.0ns;
BurstCyclesWithShiftClock : Off;
ForceDisable : Off;
SlowedDownBurstCycles : 0;
//EffectiveSlowedDownFrequency : 1/2 | 1/3 | 1/4 | 1/8;
ClockPeriods {
CLK1 : 20.0ns;
}
TestStep (ParallelLoad) {
ParallelLoad : On;
Controller (BP0) {// TOP_LVISION_LOGICTEST
StartVector : 1;
EndVector : 256;
}
...
}
}

September 2017
ForceDisable
Related Information
Summary of Specific Verification Sections SVFName
IncludeTapInit

September 2017
ForceVoltage
ForceVoltage
The ForceVoltage property instructs ETVerify to create a new WGL pattern fragment for the
current test step. The new WGL fragment contains comments for the test program engineer to
set a specific voltage on the specified pin before executing the current test pattern.
Syntax
ForceVoltage (<PinName>): <Float Value>;
Default Value
There is no default value.
Usage Conditions
This property is used in the MembistPVerify: TestStep wrapper of the .etManufacturing file.
This property is repeatable. Use a ForceVoltage property for each pin that requires to be driven
to a specific voltage during manufacturing test.
This property is used with Programmable memory BIST controllers.
Example
This example specifies that the VDDQ pin must be set to 15.0 volts during the FuseBoxProgram
test step:
MembistpVerify (TOP_P1) {
TestStep (FuseBoxProgram) {
ForceVoltage (VDDQ): 15.0;
Controller (BP4) {
AutonomousOperation: SelfFuseBoxProgram;
}
}
}
Related Information

September 2017
FreezeStep
FreezeStep
The FreezeStep property specifies that the memory BIST controller is to apply only one of the
steps defined in the BIST configuration file.
Syntax
FreezeStep: On | (Off);

• On—specifies that the memory BIST controller is to only apply one step.
• Off—specifies that the memory BIST controller is to apply all steps.
Default Value
Usage Conditions
This property is used in TestStep: Controller of the following wrappers:
• MembistPVerify
• MembistVerify
• When FreezeStep is set to Off, the memory BIST controller executes all steps in the
memory BIST configuration file, and the results are accumulated. To diagnose specific
failures, set FreezeStep to On and cycle through each step using the FreezeStepNumber
property.
• When you set FreezeStep to its non-default value, you must set the RunMode property to
RunTimeProg.
Example
This example specifies that the memory BIST controller is to apply only the second step.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
FreezeStep: On;
}
}
}
}
Related Information
Controller FreezeStepNumber

September 2017
FreezeStep
MembistVerify RunMode

September 2017
FreezeStepNumber
FreezeStepNumber
The FreezeStepNumber property specifies the number of the single step that the memory BIST
controller is to apply. The controller steps are numbered sequentially starting from 0.
Syntax
FreezeStepNumber: stepNum;
where stepNum is an integer that specifies the number of the step to apply.
Default Value
The default value is 0 (first memory BIST step).
Usage Conditions
• MembistPVerify
• MembistVerify
• The value of stepNum must fall within the range of steps defined in the memory BIST
configuration file.
• This property is meaningful only if the FreezeStep property is set to On.
Example
This example specifies that the memory BIST controller is to apply only to the first step.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
FreezeStep: On;
}
}
}
}
Related Information
Controller FreezeStep
MembistPVerify

September 2017
FreezeTestPort
FreezeTestPort
The FreezeTestPort property specifies whether or not the memory BIST controller freezes on a
given test port. This property is used in combination with the FreezeStep property to run the test
on one of the ports in the memory. That port number can be selected using the
FreezeTestPortNumber property. The test port information per memory is described in the
log file generated by the ETAssemble tool.
Syntax
FreezeTestPort: On | (Off);

• On—specifies that the memory BIST controller freezes a test port.
• Off—specifies that the memory BIST controller does not freeze a test port.
Default Value
Usage Conditions
• MembistPVerify
• MembistVerify
• At least one memory in the TestStep wrapper must have multiple test ports.
• When the FreezeTestPort is set to Off, the memory BIST controller executes all steps for
all the ports in the memory BIST configuration file, and the results are accumulated. To
diagnose specific failures, set FreezeTestPort to On, and cycle through each test port using
the FreezeTestPortNumber property.
• When you set FreezeTestPort to its non-default value, you must set the RunMode property
to RunTimeProg.
Example
This example specifies that the memory BIST controller is to apply the test on the second test
port only.

September 2017
FreezeTestPort
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
FreezeTestPort: On;
FreezeTestPortNumber: 1;
}
}
}
}
Related Information
Controller FreezeTestPortNumber
MembistVerify RunMode
FreezeStep

September 2017
FreezeTestPortNumber
FreezeTestPortNumber
The FreezeTestPortNumber property specifies the number of the single test port that the
memory BIST controller is to apply. The test ports are numbered sequentially starting from 0.
Syntax
FreezeTestPortNumber: <testPortNum>;
where testPortNum is an integer that specifies the number of the test port to be selected.
Default Value
The default value is 0 (first test port).
Usage Conditions
• MembistPVerify
• MembistVerify
• This property is meaningful only if FreezeTestPort property is set to On.
• The value of testPortNum must not be larger than the number of test ports of memories
tested in the TestStep wrapper.
Example
This example specifies that the memory BIST controller is to apply the test on the first test port
only.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
FreezeTestPort: On;
FreezeTestPortNumber: 0;
}
}
}
}
Related Information
Controller FreezeTestPort
MembistPVerify

September 2017
FreqRatioRelToSource
The FreqRatioRelToSource property allows you to specify a new frequency ratio between a
clock source and a memory BIST controller, a Burst Clock controller, a Shift Clock controller,
or a clock input port on a sub-physical region.
Syntax
where real is greater than 0.

Default Value
The default value is 1.0.
Usage Conditions
• MembistPVerify: TestClockSource wrapper
• ClockInput wrapper
• When this property is used in the ClockInput wrapper, it describes the ratio from the clock
input port on the physical region to the top-level pin.
• When this property is used in the MemBistController: TestClockSource wrapper, the
BurstClockController wrapper and ShiftClockController: ShiftClockSource wrapper, it
describes the ratio from the respective controller to the ClockInput port on the physical
region.
Example
The following example shows that all MemBist controllers in the root physical region top with
module name and/or instance name containing the string .*F300.* will have their Functional
TestClockSource driven by the top-level pin clk2 with a frequency ratio of 4.0.

September 2017
PhysicalRegion (top) {
Pin: clk2;
}
}
}
}
...
}
Related Information
BurstClockController ShiftClockController
ClockInput ShiftClockSource
ClockSourceOverride TestClockSource
PhysicalRegion

September 2017
FuseBoxAccessOperation
FuseBoxAccessOperation
The FuseBoxAccessOperation property determines the type of access to perform on the fuse
box. The two types of fuse box access methods are Read and Program.
Syntax
FuseBoxAccessOperation: (Read) | Program;

• Read — The BISR loader controller executes a read operation on the fuse box.
• Program — The BISR loader controller executes a write operation on the fuse box. A logic
1 value is written to the addresses specified using the FuseBoxWriteAddress property.
Default Value
The default expected value is Read.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
This property is used in conjunction with the RunMode: FuseBoxAccess run mode.
Example
This example uses the FuseBoxAccess run mode in order to program the fuse box addresses
10’h0A and 10’h1F.
TestStep (Step0) {
RunMode: FuseBoxAccess;
FuseBoxAccessOperation: Program;
FuseBoxWriteAddress: 10’h0A;
FuseBoxWriteAddress: 10’h1F;
}
}
}
Related Information
FuseBoxWriteAddress RunMode

September 2017
FuseBoxReadAddress
FuseBoxReadAddress
The FuseBoxReadAddress property is used to extract and compare the content of the fuse box
at a specific address. This property is used when the FuseBoxAccess run mode is selected.
Syntax
FuseBoxReadAddress(<HexAddress>): <ExpValue>;

• HexAddress — is hex value of the starting fuse box read address.
• ExpValue — is expected value which is either 1, 0, or x.
Default Value
The default expected value is 0.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
• This property is repeatable.
• This property is used in conjunction with the RunMode: FuseBoxAccess, and when
FuseBoxAccessOperation: Read is specified.
Example
This example specifies that a value of 1 is expected at fuse box addresses 10’h0A, 10’h10, and
10’h1F, and a value of 0 is expected for all other addresses of the fuse box.
TestStep (Step0) {
FuseBoxAccessOperation: Read;
FuseBoxReadAddress(10’h0A): 1;
FuseBoxReadAddress(10’h10): 1;
FuseBoxReadAddress(10’h1F): 1;
}
}
}
Related Information
FuseBoxAccessOperation RunMode

September 2017
FuseBoxReadAddress

September 2017
FuseBoxReadAddressMax
The FuseBoxReadAddressMax property enables you to specify the last address when reading
the content of the fuse box. By default, the last fuse box address is equal to FuseBoxSize -1
where FuseBoxSize is specified in the MemBISR: FuseBoxAddressBits property of the
.etassemble file.
Syntax
FuseBoxReadAddressMax: <HexAddress>;
where HexAddress is hex value of the starting fuse box read address.
Default Value
The default value is computed as the last fuse box address. This value corresponds to the
MemBISR: FuseBoxSize property from the .etassemble file, minus 1, when it is specified.
Otherwise, the default value is 2^(MemBisr: FuseBoxAddressBits)-1 where the MemBISR:
FuseBoxAddressBits has been specified in the .etassemble file.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
This property is used in conjunction with the RunMode: FuseBoxAccess, and when
FuseBoxAccessOperation: Read is specified.
Example
This example specifies that fuse box read operation should end at fuse box address 10’h1F.
TestStep (Step0) {
FuseBoxReadAddressMax: 10’h1F;
}
}
}
Related Information
Controller RunMode
FuseBoxAccessOperation TestStep
MembistPVerify MemBISR: FuseBoxAddressBits of the
.etassemble file

September 2017
MembistVerify MemBISR: FuseBoxSize of the .etassemble

file

September 2017
FuseBoxReadAddressMin
FuseBoxReadAddressMin
The FuseBoxReadAddressMin property enables you to specify the first address when reading
the content of the fuse box. By default, the starting fuse box address is 0. This property is used
when RunMode: FuseBoxAccess is selected, and when the FuseBoxAccessOperation: Read is
specified.
Syntax
FuseBoxReadAddressMin: <HexAddress>;
where HexAddress is hex value of the starting fuse box read address.
Default Value
The default value is 8’h0.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
Example
This example specifies the fuse box read operation should start at address 10’h0A.
TestStep (Step0) {
FuseBoxReadAddressMin: 10’h0A;
}
}
}
Related Information

September 2017
FuseBoxWriteAddress
FuseBoxWriteAddress
The FuseBoxWriteAddress property is used to write a logic 1 to the specified address in the
fuse box. The BISR loader controller can only write logic 1’s into the fuse box. This property is
used to program the fuse box using the TAP interface.
Syntax
FuseBoxWriteAddress: <HexAddress>;
where HexAddress is hex value of the fuse box address to write.

Default Value
The default expected value is 0.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
• This property is repeatable.
• This property is used in conjunction with RunMode: FuseBoxAccess, and when the
FuseBoxAccessOperation: Program is specified.
Example
This example specifies that a logical 1 is written at fuse box addresses 10’h0A and 10’h1F:
TestStep (Step0) {
FuseBoxWriteAddress: 10’h0A;
FuseBoxWriteAddress: 10’h1F;
}
}
}
Related Information

September 2017
FuseBoxWriteDuration
FuseBoxWriteDuration
The FuseBoxWriteDuration property allows you to control the duration of the pause cycle
when the BISR controller is writing into the fuse box. Fuse box write duration delay should be
provided in the fuse box datasheet. This property overrides the default value specified in the
FuseBoxWriteDuration property of the .etassemble file.
Syntax
FuseBoxWriteDuration: <Duration>[ms | us | (ns)];
where Duration corresponds to the required fuse box write duration time.
Default Value
The default value is the FuseBoxWriteDuration value specified in the MemBISR:
FuseBoxWriteDuration property of the .etassemble file.
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
Example
This example specifies that BISR controller should pause for 8.2us for each value written to the
fuse box.
TestStep (Step0) {
FuseBoxWriteDuration: 8.2us;
}
}
}
Related Information
MembistVerify MemBISR: FuseBoxWriteDuration in the
manual ETAssemble Tool Reference

September 2017
GlobalPadDecayTime
GlobalPadDecayTime
The GlobalPadDecayTime property enables you to specify the default leakage decay time for
all pads in the design.
Syntax
GlobalPadDecayTime: <n>ns | us | ps;
where the valid values are as follows:

• n — specifies the number assigned as the default leakage global decay time for all pads in
the design.
• ns — specifies the default global decay time in nanoseconds.
• us — specifies the default global decay time in microseconds.
• ps — specifies the default global decay time in picoseconds.
Default Value
The default value is infinity.
Usage Conditions
This property is used in the JtagVerify: SimulationModel wrapper.
This property is used during the simulation of the patterns generated by ETVerify when the
RunTest property, located in the TestStep wrapper, is set to LeakageNC or TriStateEnableNC.
Example
In the following example, the default global decay time is 1us.
etv (MyDesignA) {
JtagVerify (ETC) {
SimulationModel {
GlobalPadDecayTime: 1us;
}
TestStep (1) {
}
}
}
Related Information
JtagVerify TriStateEnableNCOptions
LeakageNCOptions RunTest
SimulationModel

September 2017
HardCodedAlgorithm
HardCodedAlgorithm
The HardCodedAlgorithm property specifies a hardcoded algorithm to be used in the current
test step. This property is optional.
Syntax
HardCodedAlgorithm: <HardCodedAlgorithmName>;
Default Value
None
Usage Conditions
• The HardCodedAlgorithm property cannot be specified if the SelectLibraryAlgorithm
property is present
• When the CompareGoID property is set to On, the controller register specifying the
algorithm selection code is extracted and compared to the value that was shifted in before
the test. Normally, the comparison on the ALGO_SEL_REG register should pass. If
miscompares are reported when simulating the test bench or applying the pattern, you
should perform the setup chain integrity test. For more information about this test, refer to
the SetupChainRegister property.
Example
This example specifies that the hardcoded algorithm LVMARCHLA is executed.
MembistPVerify (MyDesign) {
.
.
.
TestStep (4) {
.
.
.
Controller (controller1) {
HardCodedAlgorithm: LVMARCHLA;
} //end of Controller wrapper
} //end of TestStep wrapper
} //end of MembistPVerify wrapper
Related Information
MembistPVerify: TestStep: Controller RunMode

September 2017
IgnoredVectorNum
IgnoredVectorNum
The IgnoredVectorNum property enables you to mask the first N vectors of a logic BIST
pattern to allow the voltage in the chip to stabilize. When specified, an 8-bit counter in the
logicTest controller is loaded with the desired value and then the MISR is seeded with the
StartVector + IgnoredVectorNum signature. The MISR will then hold the seeded value until
the counter reaches 0.
Syntax
IgnoredVectorNum: x;
where x is an integer from 0 to 255 that specifies how many logic BIST vectors should be
masked.
Default Value
The default is 0.
Usage Conditions
This property is used in the LogicbistVerify: TestStep: Controller wrapper.
• StartVector and IgnoredVectorNum must be less than or equal to EndVector.
• The MisrCompares must be less than or equal to EndVector minus StartVector and
IgnoredVectorNum.
Example
In this example, the first 128 vectors are masked in the logic BIST pattern.
LogicBistVerify (MyDesign1) {
TestStep (0) {
Controller (BP0) {
IgnoredVectorNum: 128;
}
}
}
Related Information
TestStep StartVector
Controller EndVector
LogicbistVerify

September 2017
IncludeAllNonPowerPins
IncludeAllNonPowerPins
The IncludeAllNonPowerPins property enables you to specify whether to include both used as
well as unused ports (analog or no-connect pins)—not power and ground—in the top-level port
list of the generated test bench.
Syntax
IncludeAllNonPowerPins: On | (Off);

• On — instructs ETVerify to include both used and unused ports in the top-level port list of
the generated test bench.
• Off — instructs ETVerify to not include both used and unused ports in the top-level port list
of the generated test bench.
Default Value
The default is Off.
Usage Conditions
This property is used in the Global Section.
Example
In this example, the syntax indicates that the test bench or WGL file ETVerify creates contain
all top-level pins.
etv (MyDesign1) {
IncludeAllNonPowerPins: On;
}
Related Information
Global Section

September 2017
IncludeAllPowerPins
IncludeAllPowerPins
The IncludeAllPowerPins property enables you to specify whether or not to include power and
ground pins to the top-level port list in a test bench or a WGL file when they have been
specified in the .pinorder file in the Top-Level Flow. Supply pins are added and asserted to their
correct values in the test bench.
Syntax
IncludeAllPowerPins: On | (Off);

• On—includes power and ground pins to the top-level port list in a test bench or a WGL file.
• Off—does not include power and ground pins to the top-level port list in a test bench or a
WGL file.
Default Value
The default is Off.
Usage Conditions
This property is used in the Global Section.
Example
This example instructs ETVerify to generate a test bench with power and ground pins in the port
list when they are present in the netlist.
etv (MyDesign1) {
IncludeAllPowerPins: On;
}
Related Information
Global Section IgnoredVectorNum

September 2017
IncludeTapInit
IncludeTapInit
The IncludeTapInit property specifies whether or not you want a pattern that does not access
the TAP controller at all and only performs PinSettings, PinCompares, and Pause.
Syntax
IncludeTapInit: (Yes) | No;

• Yes — generates the normal TAP pattern and performs the requested TAP access.
• No — generates a pattern that does not access the TAP controller at all. Set this property to
No if you want to create a User Defined Sequence (UDS) file that only performs
PinSettings, PinCompares, and Pause. If you want the TAP to be reset, you can use
PinSettings to assert the TRST pin or, if you do not have a TRST pin, you can use
PinSettings to set the TMS pin to logic high and toggle the TCK clock pin for 5 cycles.
Default Value
The default value is Yes.
Usage Conditions
This property is used in the CustomVerify wrapper.
• The following properties within the CustomVerify wrapper are ignored when the
IncludeTapInit property is set to No:
o UserDRBit
o UserIRBit
o UserBitAlias
o ForceDisable
o TestClockSource
Example
The following example instructs ETVerify to generate the normal TAP pattern and perform the
requested TAP access:
etv (MyDesignA) {
CustomVerify (ctrl1) {
IncludeTapInit: No;
}
}

September 2017
IncludeTapInit
Related Information
CustomVerify PinSettings
ForceDisable PinCompares
TestClockSource Pause
SVFName

September 2017
IncrementFailureLimit
IncrementFailureLimit
The IncrementFailureLimit property advances the optional failure limit counter. This property
is useful for creating Stop-On-Nth-Error test benches for bitmap applications. To learn more
about how to use this property, refer to the “Stop-On-Nth-Error Approach” section of the
“Memory BIST Diagnostics” chapter in the Tessent MemoryBIST User’s and Reference
Manual.
Syntax
IncrementFailureLimit: On | (Off);
Default Value
The default is Off.
Usage Conditions
This property is used in the TestStep wrapper of the MembistPVerify wrapper.
For more information, see the “Creating Stop-On-Nth-Error Test Benches for Bitmap
Applications” section in the “Memory BIST Diagnostics” chapter of the Tessent MemoryBIST
User’s and Reference Manual.
Example
For an example of an ETVerify configuration file using the IncrementFailureLimit property,
see the ETVerify Configuration File Example in the Tessent MemoryBIST User’s and Reference
Manual.
Related Information
TestStep FailureLimit
MembistPVerify “Creating Stop-On-Nth-Error Test Benches
for Bitmap Applications” in the Tessent

September 2017
InhibitFuseBoxProgramming
The InhibitFuseBoxProgramming property prevents the automatic programming of the fuse
values that are stored in the fuse box shift registers at the end of a SelfFuseBoxProgram or
FuseBoxAccess programming test step. If the InhibitFuseBoxProgramming property is set to
On inside a SelfFuseBoxProgram or FuseBoxAccess programming test step, the contents of the
buffer registers from the fuse box interface are transferred to the fuse box shift registers but the
actual fuse programming is not executed. This enables additional fuse values to be written to the
fuse box before final programming is executed.
Syntax
InhibitFuseBoxProgramming: (Off) | On;
Default Value
Usage Conditions
This property is used in the TestStep:Controller wrapper of the following verification wrappers:
• MembistPVerify
• MembistVerify
The InhibitFuseBoxProgramming property is applicable only when
FuseBoxProgrammingMethod in the ETAssemble configuration file is set to Buffered.
Example
The following example shows a test step sequence where the fuse programming is postponed
until after the second test step. The first test step executes the SelfFuseBoxProgram autonomous
operation with InhibitFuseBoxProgramming enabled. The second test step performs
FuseBoxAccess programming with InhibitFuseBoxProgramming disabled, which causes the
fuse box programming to be executed after the second test step.
TestStep (SelfFBProgram_InhibitFBProgram) {
Controller (BP0) {
InhibitFuseBoxProgramming: On;
}
}
TestStep (PgmFB_LastBit) {
Controller (BP0) {
FuseBoxWriteAddress: 8'hFF;
InhibitFuseBoxProgramming: Off;
}
}

September 2017
Related Information
Autonomous SelfFuseBoxProgram run mode MembistPVerify
TestStep FuseBoxProgrammingMethod
FuseBoxAccess in BISR Controller Run
Modes of the Tessent MemoryBIST User’s

September 2017
InitialWaitCycles
InitialWaitCycles
The InitialWaitCycles property enables you to specify a wait time before running the
embedded test controllers. The wait time is used, for example, to enable a PLL to lock before
executing the test.
Syntax
InitialWaitCycles: wCycles;
where wCycles is an integer that specifies the number of master clock cycles to wait before
running the embedded test controllers.
Default Value
This property defaults to 0.
Usage Conditions
The InitialWaitCycles property is used in the following types of verification:
Table A-4. InitialWaitCycle Usage Conditions

Usage Conditions User- Custom Logic BIST
Defined Verification Verification Section
Sequence Section
Memory BIST
Section
TAP Verification
Section
WTAP Verification
Section
Scan Verification
Section
SerdesTest
The actual wait time is the maximum of Pause ✓ ✓ ✓
in ns (if defined), or InitialWaitCycles
multiplied by the value of the ClockPeriod or
TCKPeriod property—whichever is defined.
Wait cycles are inserted after the contents of ✓ ✓ ✓
the PinSettings wrapper are applied and
before TestStep controllers are run.

September 2017
InitialWaitCycles
Table A-4. InitialWaitCycle Usage Conditions

Usage Conditions User- Custom Logic BIST
Defined Verification Verification Section
Sequence Section
Memory BIST
Section
TAP Verification
Section
WTAP Verification
Section
Scan Verification
Section
SerdesTest
You can use an alternative Pause property to ✓ ✓ ✓
specify a wait time. Note that the “Pause” on
page 437 property is specified in milliseconds
by default.
The InitialWaitCycles property is ignored ✓
when the SVFName property is specified.
The value of the InitialWaitCycles property ✓
will get multiplied by the value of the
ClockPeriod property used at the time of user-
defined sequence creation.
You can use this property in both the ✓
xxxVerify wrapper and in a TestStep wrapper.
In the xxxVerify wrapper, the property
instructs ETVerify to insert wait cycles at the
beginning of the test bench.
In a TestStep wrapper, the property instructs
ETVerify to insert wait cycles at the
beginning of the test step.
Example
This example specifies that 100 master clock cycles are allowed to elapse before running the
logic BIST controller.

September 2017
InitialWaitCycles
etv (MyDesignA) {
PinSettings {
IN1A: 0;
}
DUTLoopBacks {
ina <= outd;
}
InitialWaitCycles: 100;
}
}
Related Information
ClockPeriod PinSettings
LogicbistVerify SVFName
MembistVerify UserDefinedSequence
Pause WTAPVerify

September 2017
InhibitTapAsyncReset
InhibitTapAsyncReset
The InhibitTapAsyncReset property inhibits the asynchronous reset of the TAP normally
applied at the beginning of each test pattern. Suppressing the TAP reset allows you to preserve
results of a previous test pattern needed for execution of the current or subsequent test patterns.
An important application of this property is Built-In Self-Repair.
Syntax
InhibitTapAsyncReset: On | (Off);
Default Value
The default is Off, meaning that the TAP will be reset at the beginning of the current test pattern.
Usage Conditions
This property is used in the following verification wrappers:
• MembistPVerify
• MembistVerify
In order to make sure that the results of the previous test pattern are still valid at the beginning
of the current test pattern, the following conditions apply to the time period between the two test
patterns:
• The power supply is not cycled or interrupted.
• All input pins are maintained in a stable state or do not affect the test results.
• The TAP is in the Run-Test-Idle state.
Example
This example instructs ETVerify to inhibit the TAP reset at the beginning of the current test
pattern.
etv (MyDesignA) {
MembistVerify (<TestPatternName>) {
InhibitTapAsyncReset: On;
}
}
Related Information
MembistPVerify “Implementing and Verifying Memory
Repair” in the Tessent MemoryBIST User’s
MembistVerify

September 2017
InjectErrors
InjectErrors
The InjectErrors property allows the execution of a functional loopback test on a single
channel (lane) while injecting errors in the transmitted PRBS (Pseudo-Random Binary
Sequence).
Syntax
InjectErrors: On | (Off);
Default Value
Usage Conditions
This property is used in the SerdesVerify: “TestStep” on page 563 wrapper.
• This property is meaningful only when the SerdesTest property is set to
FunctionalLoopback, and the selected Pattern is PRBS.
• When the previous conditions are met, and the InjectErrors property is set to On, one bit of
the PRBS pattern transmitted by each TPG is toggled to induce an error every 127 words
transmitted.
• At least one pair of channels (lanes) must be selected using the TPGChannelEnable and
RPAChannelEnable properties. However, in that group, the number of errors received will
be counted only for the channel selected by the ChannelSelect property, and both the TPG
and RPA for that channel must be enabled.
• The test duration is set using the LoopbackDurationInWordClockCycles property.
• When the property InjectErrors is set to On, it changes the way the behavior of the test if
the SanityCheck property is set to On.
• When the SanityCheck property is set to Off, the test sequence is as follows:
o All the selected TPGs (Transmit Pattern Generator) are started.
o A lock time is elapsed, as set by the LockTimePause property.
o All the selected RPAs (Received Pattern Analyzer) are started in seed mode.
o Once two consecutive words match those of the PRBS sequence, the RPA switches
in error detection mode.
o As the duration set by the LoopbackDurationInWordClockCycles property is
elapsed by the tester, each word received is compared against the expected word in
the PRBS sequence and the error counter in the ULTRA controller is incremented by
one when errors are detected in that word.

September 2017
InjectErrors
o Finally, at the end of the test, the error counter can be compared to a lower and/or an
upper limit, thus, setting the pass/fail bits for that test.
Example
The following will perform a regular FunctionalLoopback test on channels 0 while injecting
errors. Only the lower limit is checked, as specified by the ComparisonToLimits property.
etv (MyChip) {
SerdesVerify (BERTTest) {
TestStep (Loopback) {
SerdesTest: FunctionalLoopback;
SanityCheck: Off;
InjectErrors: On;
Pattern: PRBS;
Controller (BP1) {
LockTimePause: 5us;
//...
ChannelSelect: 0;
// Default TPG/RPA enabled areChannelSelect
TPGChannelEnable: 0;
RPAChannelEnable: 0;
//...
LoopbackDurationInWordClockCycles: 100000;
ComparisonToLimits: UpperLimit;
MeasurementLimits ("") {
UpperLimit: 900;
}
}
}
}
}
Related Information
ChannelSelect SanityCheck
ComparisonToLimits SerdesVerify
LockTimePause SerdesTest
LoopbackDurationInWordClockCycles TPGChannelEnable
Pattern TestStep
RPAChannelEnable

September 2017
InternalCellSettings
In all ETVerify IO tests, the patterns load all internal boundary-scan cells with their SafeValue
attribute inside the BSDL file’s BOUNDARY_REGISTER attribute. To change those default
settings during a particular IO test, you can change it in the InternalCellSettings wrapper:
Syntax
<cellNumber1> | <cellLabel1>: 0 | 1;
[<cellNumberN> | <cellLabelN>: 0 | 1; ...]
}
where the above criteria represent the following:

• cellNumberN is the sequence number associated with the internal cell in the BSDL file.
• cellLabelN is the internal cell label, as documented by the BSDL file’s
LV_INTERNAL_CELL_LABELS attribute.
The loaded values are valid for all tests inside the test step where the InternalCellSettings
wrapper is specified.
Default
None
Usage
You can control your custom internal boundary-scan cells with this wrapper.
Example
JtagVerify (IOtests) {
TestStep (HighSlewRate) { // change slewRate
29: 1; // some other internal cell
slewRate1: 0;
myControl: 1;
}
RunTest: Output;
}
}
}
The three specified internal cells are loaded with the specified value every time the boundary-
scan register is accessed during the whole duration of the “output” IO test. Their output is then
stable during that test.
The slewRate1 and myControl internal cells are described in the.bsdl file of the
BSDL_EXTENSION attribute below:
attribute LV_INTERNAL_CELL_LABELS: BSDL_EXTENSION;
attribute LV_INTERNAL_CELL_LABELS of top: entity is
-- Label Cell

September 2017
"((SlewRate1 , 21 )," &

" (SlewRate0 , 20 )," &
" (myControl , 15 ))";
Internal Cell #29 of the BSDL file’s BOUNDARY_REGISTER attribute is loaded with a logic
one. Internal cell named slewRate1 is loaded with a zero, and cell myControl with a one.
Since internal cell slewRate1 has no InternalCellSettings specification, ETVerify will always
load it with its BOUNDARY_REGISTER documented safeValue.
Related Information
JtagVerify TestStep

September 2017
InvertDataWithColumnBit
The optional InvertDataWithColumnBit property enables you to specify a column address bit
that will invert the applied write and expect data registers. The applied write and expect data
registers are inverted when the specified column address bit is a 1 and not inverted when the
column address bit is a 0.
The specified value overrides the value defined in the selected algorithm.
Syntax
InvertDataWithColumnBit: (None) | c[<index>];

• None — specifies that no column bit is selected to invert the write and expect data registers.
• c[<index>] — selects one column address bit to invert the write and expect data registers.
Default Value
The default is None.
Usage Conditions
This property is used in the MembistPVerify: Controller: DataGenerator wrapper.
• This wrapper is applicable when the algorithm is selected using the HardCodedAlgorithm
or SelectLibraryAlgorithm property.
• The specified c[<index>] must select a valid column address bit where index is in the range
from zero to the number of column address bits minus one. The number of column address
bits is specified in the AddressCounter wrapper of the memory library file.
Example
The following is a sample InvertDataWithColumnBit value that selects column address bit 0 to
invert the write and expect data registers:
Controller (BP2) {
DataGenerator {
InvertDataWithColumnBit: c[0];
.
.
.
} // end of DataGenerator wrapper
} // end of Controller Wrapper
} // end of MembistPVerify wrapper

September 2017
Related Information
DataGenerator HardCodedAlgorithm
MembistPVerify SelectLibraryAlgorithm

September 2017
InvertDataWithRowBit
The optional InvertDataWithRowBit property enables you to specify a row address bit that will
invert the applied write and expect data registers. The applied write and expect data registers are
inverted when the specified row address bit is a 1 and not inverted when the row address bit is a
0.
Syntax
InvertDataWithRowBit: (None) | r[<index>];

• None — specifies that no row bit is selected to invert the write and expect data registers.
• r[<index>] — selects one row address bit to invert the write and expect data registers.
Default Value
The default is None.
Usage Conditions
• This wrapper is applicable when the algorithm is selected using the HardCodedAlgorithm
or SelectLibraryAlgorithm property.
• The specified r[<index>] must select a valid row address bit where index is in the range
from zero to the number of row address bits minus one. The number of row address bits is
specified in the AddressCounter wrapper of the memory library file.
Example
The following is a sample InvertDataWithRowBit value that selects row address bit 0 to invert
the write and expect data registers:
Controller (BP2) {
DataGenerator {
InvertDataWithRowBit: r[0];
.
.
.

September 2017
Related Information

September 2017
IRStatus
IRStatus
The IRStatus property enables you to compare the captured value on the IRStatus port of the
TAP (or WTAP) controller to an expected value.
Syntax
IRStatus (<index>): 1 | 0 | x;

• index — is an integer between 0 and L-1 where L is the maximum number of internal IR bits.
• 1 — specifies the compared value on the IRStatus port of the TAP controller with an
• 0 — specifies the compared value on the IRStatus port of the TAP controller with an
• x — indicates to stop comparing a value on the IRStatus port of the TAP controller.
Default Value
None
Usage Conditions
The IRStatus property is used in the following types of verification:
Table A-5. IRStatus Usage Conditions

Usage Conditions User- Memory WTAP SerdesTest
Defined BIST Verification Verification
Sequence Verification Section Section
Section Section
The length and composition of the INT_IR ✓ ✓
register can be found in the HSDL file.
This property is meaningful only with the ✓
TAP protocol.
Note
It is recommended to use the
UserDefinedSequence: TestStep:
IRStatus property instead of
IRStatus property in the
MembistVerify (or MembistVerify):
TestStep wrapper.

September 2017
IRStatus
Table A-5. IRStatus Usage Conditions

Usage Conditions User- Memory WTAP SerdesTest
Defined BIST Verification Verification
Sequence Verification Section Section
Section Section
This property is used in the WTAPSettings ✓ ✓
wrapper:
• This property is meaningful only with the
WTAP protocol.
• This property is intended to read the
status of the bistEn(n) port that connects a
third-party embedded test controller in
go/nogo mode.
Example
This example specifies that the expected value of IR status bits 0 and 1 are 0 in TestStep (0), and
1 in TestStep (1).
etv (MyDesignA) {
LogicBistVerify (MyDesignA) {
...
TestStep (0) {
WTAPSettings (core1) {
IRStatus(0): 0;
IRStatus(1): 0;
}
}
TestStep (1) {
WTAPSettings (core1) {
IRStatus(0): 0;
IRStatus(1): 0;
}
}
}
}
Related Information
SerdesVerify WTAPSettings

September 2017
JtagVerify
JtagVerify
The JtagVerify wrapper introduces wrappers and properties for setting test steps, controller
properties, and test algorithms. These settings vary depending on whether you are using
ETVerify with the Mentor Graphics capabilities— logic test or fault insertion.
Syntax
For complete syntax for the wrapper, refer to the TAP Verification Section.

September 2017
JTAPAccess
JTAPAccess
The JTAPAccess wrapper is used for multi-chip modules that consist of two or more die
chained with the next die. ETVerify will generate test patterns to address the die-under-test.
Syntax
JTAPAccess{
PreAmble {
}
}
PostAmble {
}
}
}
Usage Conditions
The JTAPAccess wrapper is used in the Global Section.
• This wrapper can only be specified in the ETVerify configuration file if the TAP is present.
• This wrapper cannot be specified when a ScanVerify wrapper has Mode set to Multi.
• Each PreAmble and PostAmble wrapper may contain multiple Tap wrappers. The first Tap
wrapper in the PreAmble wrapper describes the first TAP in the daisy chain.
• The DeviceId property is mandatory only if the preamble or postamble TAP has a device ID
register.
Note
This functionality assumes that all TAPs in the design are reset together. This can be done
with the TRST pin or, if that pin is not present, with 5 TCK pulses while holding TMS to
a logic 1 value.
Example
Figure A-16 shows an example of a multi-chip module and the BypassOpCode properties
needed to place the TAPs daisy-chained on the TDI and TDO of the die-under-test into Bypass
mode.

September 2017
JTAPAccess
Figure A-16. Multi-Chip-Module Example
Note
Each die with its TAP in Bypass mode behaves like a one-cell shift register.
Note
In Figure A-16, the TMS, TCK, and TRST signals are omitted to simplify showing the
daisy-chained TDI and TDO connections through the multiple TAPs.
Related Information
BypassOpCode PreAmble
Mode ScanVerify
PostAmble Tap
DeviceId

September 2017
LeakageNCOptions
LeakageNCOptions
The LeakageNCOptions wrapper enables you to specify properties for the LeakageNC test.
Syntax
LeakageNCOptions {
NumberofCycles: <n>;
LogicLevel: (Both) | IIH | IIL;
}
Default Value
None
Usage Conditions
Only use this wrapper and its associated properties when the RunTest property located in the
TestStep wrapper is set to LeakageNC.
Example
The following example specifies that TestStep(0) and TestStep(1) runs the LeakageNC test
with different parameters.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
RunTest: LeakageNC;
LeakageNCOptions {
NumberOfCycles: 7;
LogicLevel: IIH;
}
TestStep (1) {
RunTest: LeakageNC;
LeakageNCOptions {
NumberOfCycles: 6;
LogicLevel: IIL;
}
}
}
Related Information
TestStep TriStateEnableNCOptions
JtagVerify NumberOfCycles
RunTest SimulationModel

September 2017
LeakageNumberOfCycles
LeakageNumberOfCycles
The LeakageNumberOfCycles property enables you to specify the number of RunTest/Idle
(RTI) states between the UpdateDR state (when the pins are tri-stated) and the CaptureDR state
(when the pads’ logic value are latched) during the Leakage test.
LeakageNumberOfCycles: <n>;
where n is the number of TCK cycles in the RTI state between the UpDateDR state and the
CaptureDR state. The total number of TCK cycles between UpDateDR and CaptureDR is
n+2.5.
Default Value
Usage Conditions
This property is used in the JtagVerify: TestStep: LeakageNCOptions wrapper.
Only use this property when you specify the leakage test with the RunTest property set to
Leakage.
Example
This example specifies to run the leakage test waiting 7 TCK cycles in the RunTest/Idle state.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
RunTest: Leakage;
LeakageNumberOfCycles: 7;
}
}
}
Related Information
LeakageNCOptions JtagVerify
RunTest TestStep

September 2017
LeakageLogicLevel
LeakageLogicLevel
The LeakageLogicLevel property enables you to specify the logic levels, high and/or low, of
the Leakage test.
LeakageLogicLevel: (Both) | IIH | IIL;

• Both — specifies that the leakage test verifies both logic levels sequentially.
• IIH — specifies that the leakage test verifies only the logic level High.
• IIL — specifies that the leakage test verifies only the logic level Low.
Default Value
The default value is Both.
Usage Conditions
This property is used in the JtagVerify: TestStep: LeakageNCOptions wrapper.
Leakage.
Example
This example specifies that only the logic level High is verified during the leakage test.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
RunTest: Leakage;
LeakageNumberOfCycles: 7;
}
}
}
Related Information
LeakageNCOptions JtagVerify
RunTest TestStep

September 2017
LoadBankAddress
LoadBankAddress
The optional LoadBankAddress property specifies a binary value to be loaded into the
BankAddress for the named A or B AddressRegister. The value loaded into the BankAddress is
the initial value of the bank address prior to execution of the microprogram. The value set with
this property overrides the LoadBankAddress value in the Algorithm wrapper of the memory
library file and ETVerify configuration file.
Syntax
where BitsValue is the value specified in the format described in the BitsValue section of the
Preface.
Default Value
This property defaults to a BitsValue equivalent to the lowest starting bank address of all
memories tested in the controller step.
Usage Conditions
This property is used in the TestStep:Controller:AddressGenerator:AddressRegister wrapper
of MembistPVerify.
• The number of bank address bits specified in any AddressCounter wrapper of the memory
library file must be greater than zero.
• The width of BitsValue must be equivalent to the number of address bits specified in the
AddressCounter wrapper of the memory library file.
Example
For an example, see the appendix Functional Debug Memory Access in the Tessent
Related Information
Controller AddressGenerator
AddressRegister FunctionalDebugMode

September 2017
LoadBankAddress
DebugMode Functional Debug Memory Access in the

Manual

September 2017
LoadBoardInfoFile
LoadBoardInfoFile
The LoadBoardInfoFile property specifies the path to a loadboard information file that
describes your DUT card configuration and which ETVerify uses to create the IO tests pattern.
Syntax
loadBoardInfoFile <path to file>;
Default Value
When this property is not present, ETVerify assumes that all design pins are contacted. The
specified loadboard information file is used by all IO tests listed in the JtagVerify wrapper.
Usage Conditions
This property can be used in the JtagVerify wrapper in the .etEarlyVer, .etManufacturing, and
.etSignOff configuration files.
• You need to create a separate .loadboardInfo File (.loadboardInfo) only if your test
loadboard features special connections to your chip pins, such as:
o Un-contacted, tied-off, uncontrollable, or unobservable chip pins
o Loopbacks from output to input pins (directly coupled or ac-coupled, like in some
1149.6 implementations)
o Pull-up or pull-down resistors on selected output or bidirectional pins
• You might need loopbacks to functionally test your 1149.6 pads. You might have un-
contacted pins if you intend to run Minimum Pin Count (MPC) IO tests.
• When the LoadBoardInfoFile property is specified in the configuration file, it affects the
UseDUTLoopBacks property default value. The default value changes to On.
Example
The following syntax specifies the path to a loadboard information file named
my_chip.loadboard
etv (my_chip) {
JtagVerify (1) {
LoadBoardInfoFile: ./my_chip.loadboard;
}
}
Related Information
JtagVerify .loadboardInfo File
LoadBoardInfoFileForPinMap Application Note Support for 1149.6
Boundary Scan

September 2017
LoadBoardInfoFile
UseDUTLoopBacks

September 2017
LoadBoardInfoFileForPinMap
LoadBoardInfoFileForPinMap
The LoadBoardInfoFileForPinMap property specifies the path to a loadboard information file
that is used to generate the template for the .pinmap file while ETVerify creates the LVDB.
Syntax
LoadBoardInfoFileForPinMap <path to file>;
Default Value
When this property is not present, ETVerify generates a .pinmap template without any
information related to AC or DC loopbacks, pullup, pulldown, or IEEE 1149.6 test information.
Usage Conditions
This property can only be used in the JtagVerify wrapper of the .etManufacturing file.
• You need to create a separate .loadboardInfo File (.loadboardInfo) only if your test
loadboard features special connections to your chip pins, such as:
o Un-contacted, tied-off, uncontrollable, or unobservable chip pins
o Loopbacks from output to input pins (directly coupled or ac-coupled, like in some
1149.6 implementations)
o Pull-up or pull-down resistors on selected output or bidirectional pins
• You might need loopbacks to functionally test your 1149.6 pads. You might have un-
contacted pins if you intend to run Minimum Pin Count (MPC) IO tests.
Example
The following syntax specifies the path to a loadboard information file named
my_chip.loadboard
etv (my_chip) {
JtagVerify (1) {
loadBoardInfoFileForPinMap: ./my_chip.loadboard
}
}
Related Information
JtagVerify .loadboardInfo File
LoadBoardInfoFile Application Note Support for 1149.6
Boundary Scan
UseDUTLoopBacks

September 2017
LoadColumnAddress
LoadColumnAddress
The optional LoadColumnAddress property specifies a binary value to be loaded into the
ColumnAddress for the named A or B AddressRegister. The value loaded into the
ColumnAddress is the initial value of the column address prior to execution of the
microprogram. The value set with this property overrides the LoadColumnAddress value in the
Algorithm wrapper of the memory library file and ETVerify configuration file.
Syntax
Preface.
Default Value
This property defaults to a BitsValue equivalent to the lowRange of the
CountRange(ColumnAddress) specified in the AddressCounter wrapper of the memory library
file.
Usage Conditions
of MembistPVerify.
• The number of column address bits specified in any AddressCounter wrapper of the
memory library file must be greater than zero.
• The width of BitsValue must be equivalent to the number of column address bits specified in
the AddressCounter wrapper of the memory library file.
Example
Related Information

September 2017
LoadColumnAddress

Manual

September 2017
LoadCounterA_EndCount
LoadCounterA_EndCount
The optional LoadCounterA_EndCount property specifies the endcount value for the general
purpose module—CounterA. This endcount value is the target count value for CounterA. The
value set with this property overrides the LoadCounterA_EndCount value in the Algorithm
wrapper of the memory library file or ETVerify configuration file.
Syntax
LoadCounterA_EndCount: <integer>;
where integer is the decimal number specifying the endcount value.

Default Value
The default value is zero.
Usage Conditions
• The DebugMode property must be enabled.
• The ControllerType in the .etplan file or .ETDefaults file must be set to SoftProgrammable.
• The integer specified for LoadCounterA_EndCount must be in the range [0:2n-1]. n is the
number of bits in CounterA specified by the NumberOfCounterABits property of the
MemBistControllerOptions wrapper in the .etplan file.
Example
Related Information
Manual

September 2017
LoadCounterA_StartCount
LoadCounterA_StartCount
The optional LoadCounterA_StartCount property specifies the startcount value for the general
purpose module—CounterA. This startcount value is the starting count value for CounterA.
Syntax
LoadCounterA_StartCount: <integer>;
where integer is the decimal number specifying the startcount value.

Default Value
The default value is zero.
Usage Conditions
• The DebugMode property must be enabled.
• The integer specified for LoadCounterA_StartCount must be in the range [0:2n-1]. n is the
number of bits in CounterA specified by the NumberOfCounterABits property of the
MemBistControllerOptions wrapper in the .etplan file.
Example
Related Information
Manual

September 2017
LoadExpectData
LoadExpectData
The optional LoadExpectData property enables you to specify a binary value to load into the
ExpectData register. The value loaded into the ExpectData register is the initial value of the
expect data prior to the execution of the MicroProgram.
Syntax
where BitsValue is specified in the format described in the “Bits Value” section of the Preface.
Default Value
The default is a BitsValue of all zeros.
Usage Conditions
Example
The following example specifies a binary value, or alternatively a hexadecimal value, to load
into the ExpectData register:
Controller (BP2) {
DataGenerator {
LoadExpectData: 16’b1111000011110000;
.
.
.
or alternatively:
Controller (BP2) {
DataGenerator {
LoadExpectData: 16’hF0F0;
.
.
.

September 2017
LoadExpectData
Related Information

September 2017
LoadRowAddress
LoadRowAddress
The optional LoadRowAddress property specifies a binary value to be loaded into the
RowAddress for the named A or B AddressRegister. The value loaded into the RowAddress is
the initial value of the row address prior to execution of the microprogram. The value set with
this property overrides the LoadRowAddress value in the Algorithm wrapper of the memory
library file and ETVerify configuration file.
Syntax
Preface.
Default Value
This property defaults to a BitsValue equivalent to the lowest starting row address of all
memories tested in the controller step.
Usage Conditions
of MembistPVerify.
• The number of row address bits specified in any AddressCounter wrapper of the memory
library file must be greater than zero.
• The width of BitsValue must be equivalent to the number of address bits specified in the
AddressCounter wrapper of the memory library file.
Example
Related Information

September 2017
LoadRowAddress

Manual

September 2017
LoadWriteData
LoadWriteData
The optional LoadWriteData property enables you to specify a binary value to load into the
WriteData register. The value loaded into the WriteData register is the initial value of the
expect data prior to the execution of the MicroProgram.
Syntax
where BitsValue is specified in the format described in the “Bits Value” section of the Preface.
Default Value
The default is a BitsValue of all zeros.
Usage Conditions
Example
The following example specifies a binary value, or alternatively a hexadecimal value, to load
into the WriteData register:
Controller (BP2) {
DataGenerator {
LoadWriteData: 16’b1111000011110000;
.
.
.
or alternatively:
Controller (BP2) {
DataGenerator {
LoadWriteData: 16’hF0F0;
.
.
.

September 2017
LoadWriteData
Related Information

September 2017
LockTimePause
LockTimePause
The LockTimePause property allows a delay to be inserted between the start of a pattern
transmitted by the TPG (Transmitted Pattern Generator) and the later start of the RPA
(Received Pattern Analyzer). This allows any PLL or CDR (Clock/Data Recovery) module in
the receiver to have time settle or lock.
Syntax
LockTimePause: <time>;
Default Value
The default value is determined by the LockTime parameter specified for the SerDes-Under-
Test. This value is specified in the EST wrapper of the ETPlanner configuration file.
Usage Conditions
This property is can be used in the TestStep and/or TestStep: Controller wrappers of the
SerdesVerify wrapper.
• This property is considered for all allowed SerdesTest property values except BasicTests.
• When a value greater than 0 is specified in the ETVerify configuration file, it overrides the
default value for the SerDes under test.
• When a value greater than zero is entered in the TestStep wrapper, it applies to all
controllers tested in this test step (Controller wrapper). However, for any particular
controller, a different value can be entered by using the LockTimePause property in the
Controller wrapper.
Example
The following will perform a regular FunctionalLoopback test for controllers BP1 and BP2.
The LockTimePause is globally set for all controllers. However, the value for BP2 specified is
different than the global one.

September 2017
LockTimePause
etv (MyChip) {
SerdesVerify (BERTTest) {
SerDesTest: FunctionalLoopback;
//...
LockTimePause: 5us;
Controller (BP1) {
//...
}
Controller (BP2) {
//...
LockTimePause: 10us;
}
}
}
}
Related Information
Controller TestStep
SerdesVerify EST in the manual ETPlanner Tool Reference
SerdesTest

September 2017
LogicbistVerify
LogicbistVerify
The LogicbistVerify wrapper is one of the wrappers of the Specific Verification Section in the
configuration file. This wrapper enables you to tailor the generated test bench to run either the
chip-level logic BIST controller or an auxiliary logic BIST controller within an ELTCore. For
each controller you can specify separate wrapper.
This section describes the syntax and available wrappers and properties for the LogicbistVerify
wrapper. This wrapper introduces wrappers and properties for setting pin values, DUT
loopbacks, pauses, userDR and userIR bits, and test steps, to name a few.
Syntax
For the complete syntax of the wrapper, refer to the Logic BIST Verification Section.

September 2017
LogicLevel
LogicLevel
The LogicLevel property enables you to specify the logic levels at which the tested pads’
outputs are pre-charged during the TriStateEnableNC test.
Syntax
LogicLevel: (Both) | High | Low;

• Both — specifies that the TriStateEnableNC test verifies both logic levels sequentially.
• High — specifies that the TriStateEnableNC test verifies only the high logic level.
• Low — specifies that the TriStateEnableNC test verifies only the low logic level.
Default Value
Usage Conditions
This property is used in the JtagVerify: TestStep: TriStateEnableNCOptions wrapper.
Only use this property when you specify the TriStateEnableNC test with the RunTest property
set to TriStateEnableNC.
Example
This example specifies that logic level low is verified during the TriStateEnableNC test.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
RunTest: TriStateEnableNC;
LogicLevel: Low;
}
}
}
}
Related Information
JtagVerify TestPath
NumberOfCycles TestStep
RunTest TriStateEnableNCOptions

September 2017
LoopbackDurationInWordClockCycles
LoopbackDurationInWordClockCycles
The LoopbackDurationInWordClockCycles property specifies the duration of the LoopBack
test when measured in cycles of the clock applied to the SerDes during this test. For this test, all
selected TPGs (TPGChannelEnable) and RPAs (RPAChannelEnable) are started and then, after
the specified delay has expired, the GO bit returned to the TAP (or WTAP) for all TPG/RPA
pairs that were started are verified to see if the transmitted PRBS Pattern was correctly received.
Syntax
LoopbackDurationInWordClockCycles: <int>;
where int is an integer number greater than 0.

Default Value
None
Usage Conditions
Example
Related Information
Pattern TestStep
RPAChannelEnable TPGChannelEnable

September 2017
LowerELTIscanInitCycles
LowerELTIscanInitCycles
The LowerELTIscanInitCycles property specifies the number of TCK clock cycles used to
initialize an ELT’s internal scan chain with all 1’s. This property is useful to reduce power
consumption during first patterns. Indeed, pre-filling scan chains with the same value (1 in this
case) reduces toggling percentage during the first vector.
Syntax
LowerELTIscanInitCycles: <cycles>;
where cycles is an integer that specifies the number of TCK clock cycles.
Default Value
Usage Conditions
This property is used in the TestStep wrapper inside the following wrappers:
• LogicbistVerify
• ScanVerify
• The LowerELTIscanInitCycles property cannot be used if the controller is accessed
through the Direct Pin Interface.
• When you assign a value greater than 0 for the LowerELTIscanInitCycles property you can
specify only one controller in a TestStep wrapper.
Example
The example specifies that 1000 TCK clock cycles should elapse to enable the internal scan
chains of ELT controllers to load all 1’s:
etv (MyDesignA) {
TestStep (1) {
PinSettings {
IN1A: 0;
}
LowerELTIscanInitCycles: 1000;
}
}
}
Related Information
ScanVerify

September 2017
LowerLimit
LowerLimit
The MeasurementLimits wrapper, together with the LowerLimit and UpperLimit properties,
specifies the test limits for the measurement performed.
Syntax
MeasurementLimits (<unit>) {
LowerLimit: <real>;
UpperLimit: <real>;
}
Default Value
Usage Conditions
This property is valid only in the SerdesVerify: TestStep: Controller: MeasurementLimits
wrapper.
Example
The following will perform an DutyCycleDistortion test for controller BP1 and compare the
expected measurements to both lower an upper limits.
etv (MyChip) {
SerdesVerify (Distortion) {
TestStep (DistortionTS) {
SerdesTest: DutyCycleDistortion;
Pattern: P1010;
Controller (BP1) {
//...
MeasurementLimits (%) {
LowerLimit: -1.0;
UpperLimit: 1.0;
}
}
}
}
}
Related Information
Controller TestStep
MeasurementLimits UpperLimit
SerdesVerify

September 2017
LVBScanFile
LVBScanFile
The LVBScanFile property points to the location of an .lvbscan file that describes all boundary-
scan cells with the current block design.
Syntax
LVBScanFile: <path to .lvbscan>;
Default Value
None
Usage Conditions
Specifying this property is only valid when running ETVerify on a block or an ELTCore as
opposed to a top-level design. It is used only with the embedded boundary scan flow. The
.lvbscan file describes all
boundary-scan register inside the block, as well as their block-level control pins, such as
clockBscan, shiftBscan, SelectJtagOutput, etc.
Example
The example specifies that in the embedded boundary scan flow, the list of valid RunTests
obviously excludes all TAP tests such as bscanReg, DevID, etc. It also excludes the standard
CLAMP test.
JtagVerify (<designName>) {
PatternName: tapbistv_<designName>;
SimulationScript: <designName>_sim.script;
TCKPeriod: 100.0ns;
LVBScanFile: outDir/<designName>.lvbscan;
RunTest: BscanReg;
RunTest: Input;
RunTest: Sample;
RunTest: HighZ;
RunTest: Output;
}
}
}
Related Information
JtagVerify

September 2017
MaskedPins
MaskedPins
The MaskedPins wrapper enables you to specify one or more pins to be masked during the IO
tests. Any failure related to this pin or its associated boundary-scan cell(s) is not reported during
the execution of the test steps.
Syntax
MaskedPins {
<pinName>: Masked | Normal;
}

• pinName — is a valid pin name on the module under test.
• Masked — specifies that the pin is to be masked.
• Normal — specifies that the pin is not masked. The ETVerify tool ignores this pin in the
wrapper.
Default Value
None
Usage Conditions
Example
This example specifies to mask any test results related to the pin SYNC.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
MaskedPins {
SYNC: Masked;
}
}
}
}
Related Information
JtagVerify

September 2017
MaxLoopCount
MaxLoopCount
The MaxLoopCount property enables you to specify the maximum count for any loop.
Syntax
MaxLoopCount: <int>;
where x is an integer.
Default Value
The default value is 2^31-1.
Usage Conditions
This property is used in the Tester-Related Data Section.
• If the loop count you specify exceeds the maximum count for any loop, the loop will be split
into smaller loops.
• This property is used only in the .etManufacturing configuration file. The ETVerify tool
automatically adds this property when the .etManufacturing file is generated.
Example
The following example specifies that the maximum loop count.
etv (myTopDesign) {
MaxLoopCount: 5000;
}
Related Information

September 2017
MaxRepairCount
MaxRepairCount
The MaxRepairCount property specifies the maximum number of repairs your test bench will
perform. Typically, this property is used only for simulation when using Fault Insertion.
Because you know how many faults you injected and how many repairs this represents, you can
specify the MaxRepairCount property to reduce the runtime length calculation of the
controller. When not specified, the runtime calculation is instead computed by the time needed
to write 50% of the fuse box locations.
Syntax
MaxRepairCount: <int>;
where int is an integer.

Default Value
There is no default value. When not specified, the runtime calculation is not based on a
MaxRepairCount but on the size of the fuse box.
Usage Conditions
This property is used in the TestStep: Controller wrapper of the following xxxVerify wrappers:
• MembistPVerify
• MembistVerify
• Typically, you use the MaxRepairCount property in simulation mode when you know the
number of repairs needed based on the number of faults intentionally injected in the
memories for the purpose of design verification. The simulation time is optimized
accordingly.
• On real silicon, the runtime is calculated as the time needed to write 50% of the fuses
assuming the other 50% will be zeros.
Example
The following example specifies to adjust the run time calculation long enough to do a single
repair:
TestStep (SelfFuseBoxProgram) {
Controller (BP0) {
MaxRepairCount: 1;
}
}
Related Information

September 2017
MaxRepairCount

September 2017
MeasurementEdge
MeasurementEdge
The MeasurementEdge property allows you to specify which edge of the beat period to include
in the current measurement.
Syntax
MeasurementEdge: (Rise) | Fall | RiseFall;
Default Value
The default value is Rise.
Usage Conditions
Example
MeasurementEdge: Fall;
Related Information
Controller TestStep
SerdesVerify

September 2017
MeasurementLimits
MeasurementLimits
specifies the test limits for the measurement performed. The limits are specified in engineering
units.
Syntax
The following syntax specifies this wrapper and the associate properties:
MeasurementLimits (““ | kHz | ps | %) {
LowerLimit: <real>;
UpperLimit: <real>;
}
where units is one of the following values, each one applicable to a specific SerdesTest:
• ““ — This is an empty string and stands for a count. It applies only to the
FunctionalLoopback test when in non-sanity check mode.
• ps — This selects a measurement in picoseconds. It applies to the following tests:
AverageSlewRate, Jitter, MeanSamplingInstant, MultiPhaseSamplingError,
TransitionDensityDependentDelay.
• kHz — This selects a measurement in kilohertz. It applies only to the FrequencyOffset test.
• % — This selects a measurement reported in percent. It applies only to the
DutyCycleDistortion test.
Usage Conditions
• This wrapper is useless unless one or both of the LowerLimit and UpperLimit properties are
also specified, as required by the value of the ComparisonToLimits property being
LowerLimit, UpperLimit or Both. The default value of the ComparisonToLimits property
is Both.
• This wrapper is not required if the ComparisonToLimits property is None.
Example
The following will perform an OffsetFrequency test for controller BP1, and comparing the
expected measurement to both lower an upper limits.

September 2017
MeasurementLimits
etv (MyChip) {
SerdesVerify (OffsetFreq) {
TestStep (FrequncyOffset) {
SerDesTest: OffsetFrequency;
Controller (BP1) {
//...
ComparisonToLimits: Both;
MeasurementLimits (kHz) {
LowerLimit: 24.412;
UpperLimit: 24.416;
}
}
}
}
}
Related Information
ComparisonToLimits SerdesVerify
Controller TestStep
LowerLimit UpperLimit
SerdesTest

September 2017
MemBistController
MemBistController
The MemBistController wrapper allows you to identify which memory BIST controllers in a
physical region will have their clock source and frequency ratio changed when
UserDefinedSequence is used in a MembistPVerify or a MembistVerify wrapper.
Syntax
MemBistController(<RE>>) {//Repeatable
Pin: <string>;
PinInv: <string>;
where RE is a comma-separated list of regular expressions identifying a memory BIST

controller by its BistPort, controller module name or full hierarchical controller instance name.
Default Value
None
Usage Conditions
wrapper.
• The supplied regular expression must match at least one memory BIST controller BistPort,
module name, or full hierarchical instance name in the physical regions matched by the
PhysicalRegion wrapper.
Example
The following example shows how you can select all the memory BIST controllers which
module name and/or instance name contain the string .*F300.*.

September 2017
MemBistController
PhysicalRegion (.*) {
...
}
}
}
...
}
MemBistController wrapper.
Summary of MemBistController Matching

-------------------------------------
PhysicalRegion(top):MemBistController(.*F300.*) matched to:
BistPort Controller Name Instance Name
------------------------------------------------------------------
BP2 top_CK1_F300_MBIST1_cntrl tlb_inst/top_CK1_F300_MBIST1_MBIST_I1
PhysicalRegion(elt1):MemBistController(.*F300.*) matched to:

BistPort Controller Name Instance Name
----------------------------------------------------------------------
BP3.WBP2 elt1_CK1_F300_MBIST1_cntrl
tlb_inst/elt1_inst/elt1_CK1_F300_MBIST1_MBIST_I1
Related Information
ClockSourceOverride PhysicalRegion
MembistVerify

September 2017
MembistPVerify
MembistPVerify
The Memory BIST Programmable Verification Section is used for verification of the
Programmable memory BIST controllers in your design.
Syntax
For the complete syntax for this wrapper, refer to Figure 4-8 in Memory BIST Verification
Section.

September 2017
MembistVerify
MembistVerify
The MembistVerify wrapper in the configuration file enables you to customize the generated
setup test bench. A separate wrapper is created for each NonProgrammable memory BIST
controller.
The MembistVerify wrapper introduces wrappers and properties for setting pin values, wait
cycles, userDR and userIR bits, and test steps, to name a few.
Syntax
For the complete syntax for this wrapper, refer to Figure 4-8 in Memory BIST Verification
Section.

September 2017
MemoryReset
MemoryReset
The MemoryReset property specifies if the memory BIST controller is to only clear the
memories and to skip the remaining phases of the library algorithm. The controller clears the
memories by writing a value of 0 to all memory locations.
Syntax
MemoryReset: On | (Off);

• On — specifies that the memory BIST controller is to write 0s into the memories and skip
the remaining phases of the library algorithm.
• Off — specifies that the memory BIST controller is to test the memories.
Default Value
Usage Conditions
• MembistPVerify
• MembistVerify
• The ETPlanner property EnableMemoryReset must be Yes.
• The MemoryReset property can only be enabled for the following library algorithms:
o SMarch
o SMarchCHKB
o SMarchCHKBci
o SMarchCHKBcil
o SMarchCHKBvcd
Example
This example specifies that the memory BIST controller is to write 0s into the memories.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
Controller (<controllerName> | BPx | DPx) {
MemoryReset: On;
}

September 2017
MemoryReset
}
}
}
Related Information
Controller TestStep
MembistPVerify EnableMemoryReset in the manual
MembistVerify SMarch in the Tessent MemoryBIST User’s
SMarchCHKB in the Tessent MemoryBIST SMarchCHKBci in the Tessent MemoryBIST
User’s and Reference Manual User’s and Reference Manual
SMarchCHKBcil in the Tessent MemoryBIST SMarchCHKBvcd in the Tessent
User’s and Reference Manual MemoryBIST User’s and Reference Manual

September 2017
MISRCompares
MISRCompares
The MISRCompares property enables you to specify the number of times the MISR is
compared during the logic BIST run. This property enables multiple signatures to be examined
in a single test step.
Syntax
MISRCompares: <int>;
where int specifies the number of MISR compares for this test step.
Default Value
Usage Conditions
This property is used in the TestStep wrapper of the LogicbistVerify wrapper.
• When you set MISRCompares to a value greater than 1, you can specify only one controller
in the test step.
• When the RunMode property is set to HWDefault, then the MISRCompares property can
only be 0 or 1.
• When you set MISRCompares to 0, only the BIST_GO port will be checked. The BIST_GO
port reports the results of the comparison within the logic BIST controller of the hard-wired
default signature against the actual contents of the MISR.
• MISRCompares must be greater than 0 when the RunMode property is set to
RunTimeProg.
• When the Diagnostic property is set On, the MISRCompares property specifies the number
of times the contents of the scan chains will be scanned following the application of the
logic BIST. For example, MISRCompares 2 and Diagnostic On indicates that the test step
will be broken into two phases and scanned out following each phase.
• You cannot set the MISRCompares property to a value larger than 32 when the Diagnostic
property is On.
Example
This example specifies to ETverify to compare 5 times the MISR during the logic BIST run.
etv (MyDesignA) {
TestStep (1) {
MISRCompares: 5;
}
}
}

September 2017
MISRCompares
Related Information
Diagnostic RunMode

September 2017
Mode
Mode
The Mode property enables you to specify scan chain configuration of the circuit and,
consequently, the type of scan test to generate.
Syntax
Mode: Single | Multi | Prepare | ControllerChain | EDT |
EDT_ncapture | Single_ncapture |Multi_ncapture |
Prepare_Iddq | Single_Iddq | Multi_Iddq;

• Single — specifies the single-chain internal test configuration, in which ATPG patterns are
shifted through one scan chain (typically using TDI/TDO pins when at the TOP level).
• Multi — specifies the multi-chain internal test configuration in which ATPG patterns are
shifted through multiple scan chains in parallel.
• Prepare — specifies the external mode of peripheral scan chain test configuration in which
PrepareFlow ATPG patterns are shifted through the peripheral scan chains of the ELT or
the Block in external mode.
• ControllerChain — specifies the controller chain test configuration in which
ControllerChain ATPG Patterns are shifted through the only chain that lies inside the
controllers of the Core or the Block.
• EDT — (Embedded Deterministic Test) specifies the configuration in which ATPG patterns
generated with Tessent TestKompress, are shifted through internal scan chains.
• EDT_ncapture — specifies the configuration in which NCapture ATPG patterns generated
with Tessent TestKompress, are shifted through internal scan chains.
• Single_ncapture — specifies the single-chain internal test configuration in which Tessent
FastScan NCapture ATPG patterns are shifted through one chain (typically using TDI/TDO
pins when at the TOP level).
• Multi_ncapture — specifies the multiple chain internal test configuration in which Tessent
FastScan NCapture ATPG patterns are shifted through multiple scan chains in parallel.
• Prepare_Iddq — specifies IDDQ ATPG patterns are shifted through the peripheral and
internal chains of an ELT core.
• Single_Iddq — specifies a single-chain test configuration that provides access to all scan
chains in the design, in which IDDQ ATPG patterns are shifted through (typically, using
TDI/TDO pins at the TOP level).
• Multi_Iddq — specifies a multi-chain test configuration that provides access to all scan
chains in the design, in which IDDQ ATPG patterns are shifted through multiple scan
chains in parallel.

September 2017
Mode
Default Value
The default value of the Mode property depends on the Controller wrapper:
• If the Controller wrapper is not specified the Mode property defaults to Prepare.
• If the Controller wrapper is specified the Mode property defaults to Single.
Usage Conditions
This property is used in the TestStep wrapper of the ScanVerify wrapper.
• The Multi and Multi_ncapture values can only be used if the circuit contains more than one
scan chain, as specified in the .etplan configuration file using the
DedicatedMultiChainNumber property.
• The Single_ncapture, Multi_ncapture, EDT_ncapture, Single_Iddq, and Multi_Iddq values
can be specified only when the StilVectorFile property is specified with a non-empty value.
• The Multi and Multi_ncapture value cannot be specified when the properties inside the
JTAPAccess wrapper — PreAmble or PostAmble — are specified.
• The Prepare value can only be used for Cores or Blocks.
• The Prepare value can only be used when Controller is “not” specified. Indeed the Prepare
mode can only be used for the current level Core or Block.
• The Prepare_Iddq value can only be used for Cores.
• The Prepare_Iddq value can only be used when Controller is “not” specified. The
Prepare_Iddq mode can only be used for the current-level ELT core.
• When the Mode property is specified to Prepare_Iddq, the TestStep: StilVectorFile
property is required to create the IDDQ patterns. Refer to Example 2.
• When the .etSignOff or the .etManfacturing file is created at the Chip level, new ScanVerify
wrappers will be added for IDDQ pattern if the Multi_Iddq value or the Single_Iddq value
(In case of the DedicatedMultiChainNumber property in the .etplan file set to 0) are
specified in the Mode property. Refer to Example 3 and Example 4.
Example 1
This example specifies the multi-chain mode:
etv (MyDesignA) {
ScanVerify (ETC) {
TestStep (3) {
Mode: Multi;
}
}
}
Example 2
This example specifies to ETVerify to generate the IDDQ patterns for the ELT core named
ELT.

September 2017
Mode
etv (ELT) {
ScanVerify (ELT_parallel_fastscan_iddq) {
PatternName: parallel_fastscan_iddq_ELT;
TestStep (Iddq_ParallelLoad) {
Mode: Prepare_Iddq;
ParallelLoad: On;
StilVectorFile: ELT.fastscan_vectors_iddq_stil;
StartVector: 1;
EndVector: 64;
}
}
ScanVerify (ELT_fastscan_iddq) {
PatternName: fastscan_iddq_ELT;
SimulationScript: ELT_sim.script;
TestStep (Iddq) {
Mode: Prepare_Iddq;
StilVectorFile: ELT.fastscan_vectors_iddq_stil;
StartVector: 1;
EndVector: 2;
}
}
}
Example 3
This example of the .ETSignOff file instructs ETVerify to generate the IDDQ pattern applied
through the Auxiliary Scan Input/Output pins (Mulri_Iddq mode) and through the TAP
TDI/TDO pins (Single_Iddq mode) on the Chip level.
etv (MyDesignA) {
ScanVerify (TOP_parallel_fastscan_iddq_multi) {
PatternName: parallel_fastscan_iddq_multi_TOP;
TestStep (Multi_Iddq_ParallelLoad) {
Mode: Multi_Iddq;
ParallelLoad: On;
Controller (BP0) {
StilVectorFile: TOP.fastscan_vectors_iddq_multi_stil;
StartVector: 1;
EndVector:64;
}
}
}
ScanVerify (TOP_fastscan_iddq_single) {
PatternName: fastscan_iddq_single_ELT;
TestStep (Single_Iddq) {

September 2017
Mode
Mode: Single_Iddq;
Controller (BP0) {
StilVectorFile: TOP.fastscan_vectors_iddq_single_stil;
StartVector: 1;
EndVector: 2;
}
}
}
}
Example 4
This example of the .etManufacturing file instructs ETVerify to generate the IDDQ pattern on
the Chip level.
etv (MyDesignA) {
ScanVerify (fastscan_iddq) {
PatternName: fastscan_iddq;
TestStep (Iddq) {
ETATestGroupName: ScanVerify_fastscan;
Mode: Multi_Iddq;
Controller (BP0) {
StilVectorFile: TOP.fastscan_vectors_iddq_multi_stil;
StartVector: 1;
}
}
}
}
Related Information
Controller ScanVerify
JTAPAccess StilVectorFile
PostAmble TestStep
PreAmble DedicatedMultiChainNumber in the manual

September 2017
MonitorClocks
MonitorClocks
The MonitorClocks wrapper enables you to specify one or more cores/blocks on which input
clock pins will be monitored during the simulation of the test bench. In addition to monitoring
cores/blocks, this wrapper also allows you to specify any hierarchical clock port to verify that it
is operating at a specific period.
This feature is useful to verify that the core/block’s functional clocks are routed and
divided/multiplied as expected without having to simulate with complete core/block netlists.
You specify the cores and blocks on which clock pins should be monitored, top-level functional
clock pins, and period to drive. The ETVerify tool will automatically calculate the clock periods
that it should expect on the cores’ and blocks’ clock pins taking into account any internal clock
division or multiplication. The simulation will last enough cycles to measure the periods on
cores’ and blocks’ clock pins. Measured periods are then compared with expected values using
an error margin of 1%, and results are displayed during simulation.
Syntax
MonitorClocks {
}//End of MonitorClocks wrapper

• moduleNameN — specifies a valid module name of a core or a block at a lower level in the
test hierarchy.
• instanceNameN — specifies a valid instance name of the core or the block moduleNameN.
• hierarchicalPortN — specifies a valid hierarchical port.
• period — specifies the expected period on the hierarchical port.
If a core or a block is instantiated more than once in the design, then the hierarchicalPort will
be repeated for each instance along with the appropriate individual instanceName.
Usage Conditions
This wrapper is used only in the CustomVerify wrapper.

September 2017
MonitorClocks
• The use of this wrapper requires that you specify appropriate clock pins and periods at the
top level of the design using the properties DefineClock property and ClockPeriods
wrapper. It also requires the UseAsyncClocks property to be set to On.
• This feature is intended to be used for simulation only, therefore, CustomVerify patterns
generated (using the runtime options -wgl, -stil, or -svf) will not include the clock
monitoring. Typical use of this feature is with the -verilog runtime option.
• When specifying a hierarchical clock port, its expected period is specified in nanoseconds
(ns).
Example
The following example instructs ETVerify to monitor the functional clocks of instances U1 and
U2 of UNITA and U32 of UNITB feeding the top-level clock pins CLK1 and CLK2 with the
specific clock period. The clock CLK2 is multiplied by 4 with a PLL at top level. Two
hierarchical clock ports, CLKGEN.CLK1 and CLKGEN.CLK2, on a clock generator module are
also observed to verify they are running at 6.0ns and 12.0ns respectively.
etv (MyDesignA) {
CustomVerify (TOP_clock_monitoring) {
PatternName: clock_monitoring_TOP;
SimulationScript: TOP_sim.script;
TCKPeriod: 100.0ns;
UseAsyncClocks: On;
DefineClock(P): CLK1;
DefineClock(P): CLK2;
ClockPeriods {
CLK1: 10.0ns; // drives U1 + div 4
CLK2: 4.0ns; // drives U2 and U32 Clocks
}
MonitorClocks{
UNITA: U1;
UNITA: U2;
UNITB: U32;
CLKGEN1: 6.0; // ns
CLKGEN2: 12.0; // ns
}
}
}
The following sample of Verilog log file shows that the clock input CLKIN on instance U1 of
UNITA received a clock signal with a period of 10ns while it was expecting 40ns (internal
division by 4), and the two others cores and hierarchical clocks received the appropriate signal.
31000 Monitoring clocks on Cores and Blocks

35000000 Compare fail: U1.CLKIN Period expect = 40.000 ns actual = 10.000 ns
35000000 U2.CLKIN Period = 4.000 ns as expected (within 1.0% margin of 4.00 ns)
35000000 U32.CLKIN Period = 4.000 ns as expected (within 1.0% margin of 4.000 ns)
35000000 CLKGEN.CLK1 Period = 6.000 ns as expected (within 1.0% margin of 6.000 ns)
35000000 CLKGEN.CLK2 Period = 12.000 ns as expected (within 1.0% margin of 12.000
ns)
Simulation Results Summary

--------------------------
Log File: ./outDir/verilog.log_clock_monitoring_TOP

September 2017
MonitorClocks
Date = Feb 7 11:17

Number of Z Compare Events = 0
Number of 1/0 Compare Events = 7
Number of Compare Failures = 1
Related Information
ClockPeriods -stil
CustomVerify -verilog
DefineClock -wgl
UseAsyncClocks

September 2017
NoCheckerBoard
NoCheckerBoard
The NoCheckerBoard property enables you to apply boundary-scan load vectors made of all-
zeroes and all-ones, instead of checkerboard vectors, while running JtagVerify IO tests such as
Input, Output, or the different flavors of dot6 tests.
Checkerboard vectors alternate logic zeroes and logic ones from one pin to the next, following
the order of the boundary-scan register. This alternating increases chances to detect short-
circuits between two adjacent pins. That is why the default IO test vectors are checkerboard.
Applying all-zeroes and all-ones IO test vectors, on the other hand, leads to easier debugging
and simplifies the usability.
Syntax
NoCheckerBoard: On | (Off);
Default Value
Usage Conditions
This property is used in the JtagVerify: TestStep wrapper. The affected test patterns are: Input,
Output, Clamp, Sample, dot6DC/ACInput, dot6DC/ACOutput, and dot6ACSelectCells.
Individual boundary-scan load vectors are still named EVEN and ODD in the output test bench.
However, EVEN now means “0” for all IO pins, and ODD means “1” for all IO pins.
Example
This example specifies that NoCheckerBoard applies all-zeros patterns during all tests below,
instead of the standard ChecherBoard patterns.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
NoCheckerBoard: On;
RunTest: Input;
RunTest: HighZ;
RunTest: Clamp;
RunTest: Output;
}
}
}
Related Information
JtagVerify RunTest

September 2017
NumberOfCycles
NumberOfCycles
The NumberOfCycles property enables you to specify the number of RunTest/Idle (RTI) states
between the UpdateDR state (when the pins are tri-stated) and the CaptureDR state (when the
pads’ logic value are latched) during the TriStateEnableNC test.
Syntax
NumberOfcycles: <n>;
where n is the number of TCK cycles in the RTI state between the UpdateDR state and the
CaptureDR state. The total number of TCK cycles between UpdateDR and CaptureDR is n+2.5.
Default Value
Usage Conditions
This property is used in the JtagVerify: TriStateEnableNCOptions wrapper.
Only use this property when you specify the TrisStateEnableNC test with the RunTest property
set to TriStateEnableNC.
Example
This example specifies that during the TriStateEnableNC test, 3 TCK cycles will be spent in the
RunTest/Idle state. Typically, the number of cycles is left to its default value.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
TestPath: Local;
NumberOfCycles: 3;
}
}
}
}
Related Information
RunTest

September 2017
Observation
Observation
The Observation property enables you to specify the observation capability of the tester
channel contacted to a design pin.
Syntax

• None — specifies that the tester channel has no observation capability.
• TwoState — specifies that the tester channel can observe 0 or 1 on the design pin.
• ThreeState — specifies that the tester channel can observe 0, 1, or HighZ on the design pin.
Default Value
Usage Conditions
If the Observation property does not exist in the DesignPin wrapper, the tester channel is
considered to have no observation capabilities.
Example
This example specifies that the tester can observe 1 and 0 on the pin SyncOut, and 0, 1, and
HighZ on the bus DBusA.
etv (MyDesignA) {
JtagVerify (ETC) {
ContactedPins {
DesignPin (SyncOut){
Observation: TwoState;
}
DesignPin (DBus(0)){
}
DesignPin (DBus(31)){
}
}
}
}
Related Information
ContactedPins JtagVerify

September 2017
Observation
DesignPin

September 2017
OperationSet
OperationSet
The OperationSet property is used to specify the name of the operation set to be used in the test
step. This property will override any OperationSet assigned to the step.
Syntax
OperationSet: <OperationSetName>;
Default Value
None
Usage Conditions
• The OperationSetName must match either a Mentor Graphics library built-in operation set
name or one of the user-defined operation sets specified in Step 2 ETPlanner.
• OperationSet can only be used when HardCodedAlgorithm or SelectLibraryAlgorithm is
defined.
• When you define custom OperationSets and would like to select as well built-in
OperationSets using the OperationSet property, keep in mind that custom Operations in the
OperationSet wrapper must be listed in the following specific order to make sure that
respective operations would be properly mapped to the built-in OperationSets:
o NoOperation
o Write
o Read
o ReadModifyWrite
o WriteRead
Example
OperationSet: MySyntax;
Related Information
MembistPVerify: TestStep: Controller SelectLibraryAlgorithm
HardCodedAlgorithm OperationSet in the Tessent MemoryBIST
User’s and Reference Manual

September 2017
PadDecayTime
PadDecayTime
The PadDecayTime wrapper enables you to individually specify the leakage decay time of any
bidirectional and symmetrical pads in the design.
Syntax
PadDecayTime {
<pinName>: <n>ns | us | ps;
}

• pinName — specifies a top-level bidirectional port driven by a symmetrical pad.
• n — specifies the number assigned as the leakage decay time for individual bidirectional
and symmetrical pads in the design.
• ns — specifies the default leakage decay time in nanoseconds.
• us — specifies the default leakage decay time in microseconds.
• ps — specifies the default leakage decay time in picoseconds.
Default Value
The default value is as follows:
• If the GlobalPadDecayTime property is not defined, the default value is infinity.
• If the GlobalPadDecayTime property is defined, the default value is the same as this
property.
Usage Conditions
This property is used in the JtagVerify:SimulationModel wrapper.
This property is used during the simulation of the patterns generated by ETVerify when the
RunTest property in the TestStep wrapper is set to LeakageNC or TriStateEnableNC.
Example
The following example specifies a default pad decay time of 1us and a pad decay time of 2.5us
certain pads.

September 2017
PadDecayTime
etv (MyDesignA) {
JtagVerify (ETC) {
SimulationModel {
PadDecayTime {
D1(0): 2.5us;
D1(1): 2.5us;
D1(2): 2.5us;
D1(3): 2.5us;
D1(4): 2.5us;
D1(5): 2.5us;
D1(6): 2.5us;
D1(7): 2.5us;
D1(8): 2.5us;
}
TestStep (1) {
}
}
}
Related Information
RunTest JtagVerify
SimulationModel

September 2017
ParallelLoad
ParallelLoad
The ParallelLoad property enables you to control whether or not ETVerify generates a parallel-
loading simulation test bench. Parallel-loading test benches reduce simulation time by
eliminating most of the scan-shift clocks required to load a test vector.
Syntax

• On — specifies the generation of a parallel-loading simulation test bench.
• Off — specifies the generation of a serial-loading simulation test bench.
Default Value
Usage Conditions
The ParallelLoad property is used in the following types of verification:
Usage Conditions Scan Verification Logic BIST

Section Verification Section
Test bench simulation requires Mentor ✓ ✓
Graphics PLI code.
Only one controller can be included within a ✓
test step if the ParallelLoad property is set to
On.
The ParallelLoad property cannot be set to ✓
On, if the TestClockSource property in the
xxxVerify wrapper is set to TCK.
When the ParallelLoad property s set to On ✓
it must be used with the PowerLevel
property set to Full.
The ParallelLoad property cannot be set to ✓ ✓
On when generating any of the ATE
patterns:
-svf On
-wgl On
-stil-stil On
-tstl On

September 2017
ParallelLoad
Example
This generates a parallel-loading simulation test bench:
LogicbistVerify (TOP) {
PatternName: logicbistv_TOP;
SimulatitionScript: TOP_sim.script;
UseAsynClocks: On;
TCKPeriod: 100.0ns;
ClockPeriods {
CLK1: 13.333333ns;
CLK3: 83.333333ns;
}
ParallelLoad: On;
Controller (BP0) {//TOP_LVISION_LOGICTEST
StartVector: 1;
EndVector: 32;
}
}
}
Related Information
LogicbistVerify -stil
ParallelLoad -svf
PowerLevel -tstl
ScanVerify -verilog
TestClockSource -wgl

September 2017
ParallelRetentionGroup
The ParallelRetentionGroup property specifies the group number that the controller is
associated with. The group number is a numeric label for the controller group. Each controller
group consists of all controllers with the same ParallelRetentionGroup property value. When
performing parallel static retention test on controller groups, the controller groups are enabled
sequentially, and the same sequence applies for all algorithm sub-phases. The controller group
execution order is determined from the order of appearance of the group numbers.
Syntax
ParallelRetentionGroup: <groupNum>;
where groupNum is an integer value that is the controller group number.

Default Value
Usage Conditions
• MembistPVerify
• MembistVerify
• This property is valid only if you set the ETPlanner property ParallelRetentionTest to
PerGroup when you generated the controller.
• This property is meaningful only if the ParallelRetentionTest property is set to On.
• The retention pause between algorithm sub-phases is specified using the
ParallelRetentionTime property.
• When performing parallel static retention test on controller groups, all three algorithm sub-
phases (StartToPause, PauseToPause and PauseToEnd) are applied. Therefore, the
AlgorithmPhase property is ignored.
Example 1
Example 1 enables parallel static retention testing on two controller groups. Group 1 consists of
two controllers (A, B). Group 2 consists of two controllers (C, D). The retention time between
algorithm sub-phases is 2 milliseconds. In each algorithm sub-phase, Group 1 is enabled first,
followed by Group 2.

September 2017
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
ParallelRetentionTest: On;
ParallelRetentionTime: 2ms;
Controller (A) {
ParallelRetentionGroup: 1;
}
Controller (C) {
}
Controller (D) {
}
Controller (B) {
}
}
}
}
Example 2
Example 2 enables parallel static retention test on three controller groups with 1 controller each.
The retention time between algorithm sub-phases is 500 nanoseconds. In each algorithm sub-
phase, the order of execution is Group 3, Group 2, Group 1.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
ParallelRetentionTime: 500ns;
Controller (A) {
}
Controller (B) {
}
Controller (C) {
}
}
}
}
Related Information
AlgorithmPhase ParallelRetentionTest
Controller ParallelRetentionTime
MembistPVerify ParallelRetentionTest in the manual

September 2017
ParallelRetentionTest
The ParallelRetentionTest property enables parallel static retention testing for RAMs.
Memory BIST controllers that are executed in parallel apply each algorithm sub-phase
simultaneously. The ParallelRetentionTime property specifies the duration of the retention
pause between sub-phases. The generated test bench always applies all three sub-phases with
the same retention pause between sub-phases.
You can select controllers to be enabled in groups during each sub-phase. The controller groups
are executed sequentially, and the same sequence applies to all sub-phases.
Syntax
ParallelRetentionTest: On | (Off);

• On — enables parallel static retention testing. The selected memory BIST controllers might
run in parallel or in controller groups.
• Off — disables parallel static retention testing.
Default Value
The default is Off.
Usage Conditions
This property is used in the TestStep wrapper of the following wrappers:
• MembistPVerify
• MembistVerify
• This property is valid only if you set the ETPlanner property ParallelRetentionTest to Yes or
PerGroup.
• When this property is set to On, the AlgorithmPhase property is ignored.
• The RunMode property must be set to HWDefault.
Example
The following example enables a parallel static retention test with a retention time of 2
milliseconds between algorithm sub-phases:
etv (MyDesignA) {
MembistVerify (MyDesign) {
TestStep (4) {
...

September 2017

} //end of MembistVerify wrapper
} //end of etv wrapper
Related Information
AlgorithmPhase ParallelRetentionGroup
MembistPVerify ParallelRetentionTime
MembistVerify ParallelRetentionTest in the manual

September 2017
ParallelRetentionTime
The ParallelRetentionTime property specifies the retention pause between algorithm sub-
phases when performing parallel static retention testing.
Syntax
ParallelRetentionTime: rTime s | (ms) | us | ns | ps;
where rTime is a real number. Note that there is no space between the rTime value and the unit.
Valid values for specifying the units for rTime are as follows:
• s — specifies the retention time in seconds.
• ms — specifies the retention time in milliseconds.
• us — specifies the retention time in microseconds.
• ns — specifies the retention time in nanoseconds.
• ps — specifies the retention time in picoseconds.
Default Value
When no value is specified for ParallelRetentionTime, it defaults to 0ms in the .ETSignOff file.
However, it defaults to 32ms in the .etManufacturing file.
Usage Conditions
• This property is used in the TestStep wrapper:
• MembistPVerify
• MembistVerify
This property is meaningful only if the ParallelRetentionTest property is set to On.
Example
This example enables parallel static retention test with a retention time of 2 milliseconds
between algorithm sub-phases.
etv (MyDesignA) {
MembistVerify (MyDesign) {
TestStep (4) {
...
} //end of MembistVerify wrapper
} //end of etv wrapper
Related Information
AlgorithmPhase ParallelRetentionGroup

September 2017
MembistPVerify ParallelRetentionTest

September 2017
Pattern
Pattern
The Pattern property allows you to select which pattern will be produced by the Test Pattern
Generators (TPG) that will be enabled during the test. This property is common to all ULTRA
controllers attached to the same TAP (or WTAP) since the pattern selection lines are routed to
all TPGs.
When the FunctionalLoopback test is selected as well for the ULTRA controllers, then the
Receive Pattern Analyzer will test the correct reception of the selected Pattern. However, only
the PRBS pattern is supported for this test.
Syntax
Pattern: (P1010) | P1100 | PHalfOne | PV60 | PHalfIsoOne | PHalfWord |
PHalfPlusOne | P10J | PRBS | P0101 | P0011 | PHalfOneC | PHalfIsoOneC |
P01J | PRBSC;
where the patterns are described in the following tables, based on the serializer word size. For
word sizes of 40, 60, and 80 bits, the patterns generated are mere replication of 20 bits 2, 3, and
4 times respectively with one exception for the PHalfWord pattern. For the 40-, 60-, and
80-bit words, the PHalfWord pattern is composed of half the bits in the word at 1 followed by
half the bits in the word at 0. Of course, the PHalfWordC is the binary complement of the
PHalfWord.
Table A-6. Patterns Generated by the TPG for the 4-, 8-, and 16-bit Serializer
Word Size
Code ( Label ) 4-Bit Word 8-Bit Word 16 Bit Word
P1010 1010 10101010 1010101010101010
P1100) 1100 11001100 1100110011001100
PHalfOne 1111<->0000 11110000 1111111100000000
PV60 1111<->1000 11111000 1111111111000000
PHalfIsoOne 1110<->0100 11100100 1111111001000000
PHalfWord 1111<->0000 11110000 1111111100000000
P10J rrr1<->0rrrr rrr10rrr rrrrrrr10rrrrrrr
PRBS rrrr rrrrrrrr rrrrrrrrrrrrrrrr
P0101 0101 01010101 0101010101010101
P0011 0011 00110011 0011001100110011
PV40 0000<->0111 00000111 0000000000111111
PHalfIsoOneC 0001<->1011 00011011 0000000110111111
PHalfOneC 0000<->1111 00001111 0000000011111111

September 2017
Pattern
Table A-6. Patterns Generated by the TPG for the 4-, 8-, and 16-bit Serializer
Word Size (cont.)
Code ( Label ) 4-Bit Word 8-Bit Word 16 Bit Word
PHalfWordC 0000<->1111 00001111 0000000011111111
P01J rrr0<->1rrr rrr01rrr rrrrrrr01rrrrrrr
PRBSC rrrr rrrrrrrr rrrrrrrrrrrrrrrr
Table A-7. Patterns Generated by the TPG for the 10- and 20-bit Serializer
Word Size
Code ( Label ) 10 Bit Word 20 Bit Word (40, 60, 80)
P1010 1010101010 1010101010101010
P1100 1100110011<->0011001100 11001100110011001100
PHalfOne 1111100000 11111000001111100000
PV60 1111110000 11111100001111110000
PHalfIsoOne 1111001000 11110010001111001000
PHalfWord 1111100000 11111111110000000000
P10J 10rrrr10rr 10rrrr10rr10rrrr10rr
PRBS rrrrrrrrrr rrrrrrrrrrrrrrrrrrrr
P0101 0101010101 01010101010101010101
P0011 0011001100<->1100110011 00110011001100110011
PV40 0000001111 00000000000011111111
PHalfIsoOneC 0000110111 00000000000011111111
PHalfOneC 0000011111 00000111110000011111
PHalfWordC 0000011111 00000111110000011111
P01J 01rrrr01rr 01rrrr01rr01rrrr01rr
PRBSC rrrrrrrrrr rrrrrrrrrrrrrrrrrrrr
Default Value
The default value is P1010.
Usage Conditions
This property is used in the SerdesVerify: TestStep wrapper.
Example
Pattern: P1010;

September 2017
Pattern
Related Information

September 2017
PatternDBFile
PatternDBFile
The PatternDBFile property allows you to specify the Pattern Database file generated by
Tessent FastScan or TestKompress, that provides the vector data to be used in a ScanVerify
wrapper.
Syntax
PatternDBFile: <filename>;
where filename can be any identifier that is a valid operating system file name.
Default Value
None
Usage Conditions
• Note the following limitation — The Pattern DB cannot be used for the EDT patterns
because there is no file that can be used to map the channel “cells” to the scan cells.
• This property appears in the ScanVerify wrapper if the ETPlanner VectorFileFormat
property is specified to PatternDB. When VectorFileFormat is set to PatternDB, the
dofiles generated for Tessent FastScan/TestKompress will use the new -patdb option in
the write_patterns command, highlighted in Green in the example below:
write_pattern LV_WORKDIR/top.fastscan_vectors_lbist_patdb -replace
-scan_test -lbist -patdb
The PatternDBFile property StilVectorFile property inside the ScanVerify wrapper are
mutually exclusive.
• If you do not want to rerun ETPlanner and go through the LV flow, the dofiles can be
manually edited to write out the pattern DB vector files. The following shows what the
write_patterns command should look like in each dofile:
.fastscan_GenSimPatterns_lbist:
write_patterns LV_WORKDIR/xxx.fastscan_vectors_lbist_patdb -replace

-scan_test -lbist -patdb save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_lbist_patdb.UBOverrides
.fastscan_GenSimPatterns_edt:
write_patterns LV_WORKDIR/xxx.fastscan_vectors_edt_int_patdb -
scan_test -patdb -replace -edt_internal save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_edt_int_patdb.UBOverrides

September 2017
PatternDBFile
.fastscan_GenSimPatterns_multi:
write_patterns LV_WORKDIR/xxx.fastscan_vectors_multi_patdb -scan_test

-patdb -replace save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_multi_patdb.UBOverrides
.fastscan_GenSimPatterns_ncapture_edt:
write_patterns LV_WORKDIR/xxx.fastscan_vectors_ncapture_edt_int_patdb
-scan_test -patdb -replace -edt_internal save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_ncapture_edt_int_patdb.UBOverrides
write_patterns
LV_WORKDIR/xxx.fastscan_vectors_ncapture_edt_chain_test_int_patdb
-chain_test -patdb -replace -edt_internal
save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_ncapture_edt_chain_test_int
patdb.UBOverrides
.fastscan_GenSimPatterns_ncapture_multi:
write_patterns LV_WORKDIR/xxx.fastscan_vectors_ncapture_multi_patdb
-scan_test -patdb -replace save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_ncapture_multi_patdb.UBOverrides
write_patterns
LV_WORKDIR/xxx.fastscan_vectors_ncapture_multi_chain_test_patdb
-chain_test -patdb -replace save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_ncapture_multi_chain_test_
patdb.UBOverrides
.fastscan_GenSimPatterns_iddq (in ELT core):
write_patterns LV_WORKDIR/xxx.fastscan_vectors_iddq_patdb -scan_test

-patdb -replace
.fastscan_GenSimPatterns_iddq_multi (in Top):
write_patterns LV_WORKDIR/xxx.fastscan_vectors_iddq_multi_patdb
-scan_test -patdb -replace save_userbit_overrides
LV_WORKDIR/xxx.fastscan_vectors_iddq_multi_patdb.UBOverrides
.fastscan_GenFullPatterns_ccm:
write_patterns LV_WORKDIR/xxx.fastscan_stuck_ccm_patdb -scan_test

-patdb -replace save_userbit_overrides
LV_WORKDIR/xxx.fastscan_stuck_ccm_patdb.UBOverrides
.fastscan_GenFullPatterns_lbist:
write_patterns
LV_WORKDIR/xxx.fastscan_vectors_lbist${PatternSetID}_patdb -replace
-scan_test -lbist -patdb save_userbit_overrides
LV_WORKDIR/ELT.fastscan_vectors_lbist${PatternSetID}_patdb.UBOverrides
.fastscan_GenFullPatterns_multi:
write_patterns ${PatdbVectorFile} -replace -scan_test

-patdb save_userbit_overrides ${PatdbVectorFile}.UBOverrides

September 2017
PatternDBFile
.fastscan_GenFullPatterns_edt:
write_patterns ${EdtIntPatdbVectorFile} -scan_test -patdb

-replace -edt_internal save_userbit_overrides
${EdtIntPatdbVectorFile}.UBOverrides
Example
This example instructs ETVerify to use the PatternDB file —
TOP.fastscan_vector_multi_patDB.
etv (MyDesignA) {
ScanVerify (multi){
...
TestStep (Serial){
Mode: Multi;
Controller (BP0) {
PatternDBFile: Top.fastscan_vector_multi_patDB;
}
}
}
}
Related Information
ScanVerify: TestStep: Controller VectorFileFormat in the manual ETPlanner
Tool Reference
StilVectorFile

September 2017
PatternName
PatternName
The PatternName property enables you to specify the name of the pattern that ETVerify stores
in the directory identified by the runtime option -vif. The ETVerify tool also uses the specified
pattern name as the base name of the test bench or manufacturing test pattern files that it
generates.
Syntax
where patternName can be any identifier that is a valid operating system character string.
Default Value
None. You must specify a value for this property.
Usage Conditions
• CPUVerify
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• ScanVerify
• SerdesVerify
• WTAPVerify
• FastScanVerify
If there are multiple xxxVerify wrappers of the same type, their PatternName properties
should be unique.
Example
In this example, ETVerify creates the pattern pattern1 in the VIF database MyDesignA.vif and
generates a Verilog test bench in the file pattern1.v.
etv (MyDesignA) {
CustomVerify (1) {
PatternName: pattern1;
}
}

September 2017
PatternName
Related Information
-vif BondingOption

September 2017
PatternSetID
PatternSetID
When Tessent FastScan is used as the LogicTest fault simulator, it is possible to run Tessent
FastScan multiple times to generate many masking configurations that can be stored in the same
LVDB. During these multiple Tessent FastScan runs the Tcl variable PatternSetID is used to
add a suffix to the generated PRPG, MISR, and vector files so that they can all be stored in the
same directory—Redesigned Logic Test Dofiles architecture uses the value of pattern_id Tcl
variable, defined by user in input configuration file, or automatically generated by the tool, to
create a directory in LV_WORKDIR/pattern_sets/, where all relevant files are stored. See
“Using Redesigned Tessent Shell Dofiles” in the LV Flow User’s Manual for complete
information.
The PatternSetID property in the LogicbistVerify wrapper is used to select one of these
alternate configurations for a given logicBIST controller. The PatternSetID property in the
SerdesVerify wrapper is used to select one of the created pattern sets for a given scan
configuration's settings.
Syntax
PatternSetID: <string>;
where string matches the value used by the PatternSetID Tcl variable when Tessent FastScan
generates the LogicBIST signatures. When using Redesigned Logic Test Dofiles architecture,
“string” matches the value of pattern_id Tcl variable, defined by user in input configuration or
automatically generated by the tool.
Default Value
None. You must specify a value for this property. When using Redesigned Logic Test Dofiles
architecture, the default value of this property is "default".
Usage Conditions
The PatternSetID property is used in the LogicbistVerify: TestStep: Controller wrapper and in
SerdesVerify: TestStep: Controller wrapper.
This property can only be specified if the ETPlanner property LogicTestFaultSimulator is set to
FastScan.
Example
In the following example, TestStep (ParallelLoad) will use the masking configuration CM1,
while the TestStep (SerialLoad) will use configuration CM2.
LogicbistVerify (glchsmpar3) {
PatternName: logicbistv_engine;
SimulationScript: engine_sim.script;
UseAsyncClocks: On;
TckPeriod: 10.0ns;
BurstCyclesWithShiftClock: Off;

September 2017
PatternSetID
//EffectiveSlowedDownFrequency: 1/2 | 1/4 | 1/8;

ClockPeriods {
engine_clk: 2.5ns;
}
Controller (DP1.WBP0) { // engine_LVISION_LOGICTEST
ParallelLoad: On;
PatternSetID: CM1;
StartVector: 1;
EndVector: 256;
}
}
TestStep (SerialLoad) {
Controller (DP1.WBP0){ // engine_LVISION_LOGICTEST
PatternSetID: CM2;
ShiftClkSelect: SHIFTCLKSRC1/4;
StartVector: 1;
EndVector: 2;
}
}
}
Related Information
Controller TestStep
LogicbistVerify ScanVerify

September 2017
Pause
Pause
The Pause property enables you to specify a pause time before initializing the test. You can use
the pause time, for example, to enable a phase-locked loop (PLL) to lock before executing the
test.
Syntax
where pTime is a real number. Note that there is no space between the pTime value and the unit.
Valid values for specifying the units for pTime are as follows:
• s — specifies the pause time in seconds.
• ms — specifies the pause time in milliseconds.
• us — specifies the pause time in microseconds.
• ns — specifies the pause time in nanoseconds.
• ps — specifies the pause time in picoseconds.
Default Value
The default value is 0ms.

September 2017
Pause
Usage Conditions
The Pause property is used in the following types of verification.
Table A-8. The Pause Property Usage Conditions

Usage Conditions Custom Verification Logic BIST Verification
Section Section
Scan Verification SerdesTest Verification
Section Section
TAP Verification Memory BIST Verification
Section Section
User-Defined Sequence Scan Verification Section
Section
WTAP Verification
Section
Pause performs the same function ✓ ✓
as the InitialWaitCycles property.
The difference between Pause and
InitialWaitCycles is that Pause is
specified in absolute time, while
InitialWaitCycles is specified in
clock periods. The value of
InitialWaitCycles changes when
the value of the ClockPeriod
property changes.
The actual wait time is the ✓ ✓
maximum of Pause, in
nanoseconds, or the
InitialWaitCycles value multiplied
by the value in ClockPeriod.
Wait time = maximum of Pause ns ✓ ✓
(or InitialWaitCycles) *
ClockPeriod.
This property appears within the ✓
xxxVerify wrapper and within the
TestStep wrapper. In the xxxVerify
wrapper, the property specifies to
ETVerify to insert a pause time at
the beginning of the test bench or
manufacturing test pattern file. The
ETVerify tool includes the pause
time after the values of the
PinSettings wrapper are applied
and before the controllers are run.

September 2017
Pause
Example
This example specifies that a 10 millisecond wait time is to be inserted by ETVerify after
PinSettings are applied but before any setup commands are issued.
etv (MyDesignA) {
TestStep (0) {
PinSettings {
IN1A: 0;
}
Pause: 10ms;
}
}
}
Related Information
ClockPeriod PinSettings
InitialWaitCycles SerdesVerify
JtagVerify
“LogicbistVerify” on page 384 TestStep
MembistVerify WTAPVerify

September 2017
PersistentBISTInputs
The PersistentBISTInputs property specifies that the memory interface multiplexers will
select the BIST inputs for the duration of the TestStep. One application of this property is to
allow the memory to be refreshed with the TestEndRefresh module upon completion of all of
the algorithms in the test. Another application of this property is to maintain the BIST inputs to
the memory between TestSteps.
Syntax
PersistentBISTInputs: Yes | (No);

• Yes — specifies that the BIST inputs will remain selected for the duration of the TestStep.
• No — specifies that the memory interface multiplexers are enabled to change to the
functional inputs before and after the controller execution.
Default Value
The default value is No.
Usage Conditions
Example
This example specifies that the BIST inputs are to be selected while the controller is scanned
and at the end of the test:
TestStep (4) {
PersistentBISTInputs: Yes;
Related Information
Controller TestEndRefreshInterval
TestEndRefreshEnable

September 2017
PhysicalConstraintFile
The PhysicalConstraintFile property enables you to specify the use of the optional input file—
physical constraints file.
Syntax
PhysicalConstraintFile: <fileName>;
where filename can be any identifier that is a valid operating system file name.
Default Value
The default value is <chipDesignName>.jtag_phy, where chipDesignName specifies the
following:
• Default prefix for the input test connection map file (.tcm).
• Base name for the input configuration file unless you specify the configuration file with the
-configFile runtime option.
• Name of the top-level module or entity in your design.
Usage Conditions
• The physical constraints file is an optional file that enables you to specify the groups of
active enable cells during an output test and a port’s polarity, relative to other ports, when
ETVerify generates a checkerboard input/output pattern. This file gives you some control
over the patterns generated by ETVerify.
• The ETVerify tool generates a starter template for this file in the current working directory
when ETVerify is run with -genConfigFile On. You can edit this starter template to override
default values used for enable grouping and port polarity.
• If you do not specify a physical constraints file, ETVerify will create IO test patterns where:
o The number of enable cells groups will depend on the value of the activeControlCell
parameter.
o The checkerboard will arbitrary assign ODD and EVEN polarities to the IO pins.
Example
This example instructs ETVerify to use the physical constraints file top.phy2.
etv (MyDesignA) {
JtagVerify (1) {
PhysicalConstraintFile: top.phy2;
}
}

September 2017
Related Information
JtagVerify -genConfigFile
-configFile

September 2017
PhysicalRegion
PhysicalRegion
The PhysicalRegion wrapper allows you to identify on which physical regions
ClockSourceOverride is to be applied.
Syntax
Pin: <string>;
PinInv: <string>;
}//End of MemBistController wrapper
ClockInput(<RE> | new<portName>) {//Repeatable
Pin: <string>;
PinInv: <string>;
Pin: <string>;
PinInv: <string>;
Pin: <string>;
PinInv: <string>;
where RE is a comma-separated list of regular expressions identifying a physical region by its

module name or full hierarchical instance name.
Default Value
None
Usage Conditions
This wrapper is used in the UserDefinedSequence: ClockSourceOverride wrapper.

September 2017
PhysicalRegion

• This wrapper can only be specified for physical regions that have been generated with
Version 5.0 or newer.
• The regular expression must match a physical regions module name or instance name.
Example
In the following example, the first PhysicalRegion wrapper is used to match all regions that
have the module name and/or instance name that start with inter. The second PhysicalRegion
wrapper is used to match all regions that have the module name and/or instance name that
exactly match the string subCore.
PhysicalRegion (inter.*) {
...
}
...
}
}
...
}
PhysicalRegion wrappers.
Summary of Physical Region Matching
-----------------------------------
PhysicalRegion(inter.*) matched to:
Module Name Instance Name
-----------------------------------------
interface tlb_inst/interface_inst1
interface tlb_inst/interface_inst2
PhysicalRegion(subCore) matched to:

Module Name Instance Name
-----------------------------------------
subCore tlb_inst/subCore_inst
Related Information
ClockSourceOverride UserDefinedSequence

September 2017
Pin
Pin
If your UserDefinedSequence changes the top-level pin that is sourcing a clock in your design,
then the Pin property allows you to specify the clock pin on the root physical region that will be
now be sourcing MemBistController, BurstClockController, ShiftClockController in the root
physical region or a ClockInput port on a sub-physical region.
Syntax
Pin: <string>;
where string is a top-level pin name.

Default Value
None
Usage Conditions
• The Pin and ClockInput properties are mutually exclusive.
• This property can only be used in the MemBistController: TestClockSource,
ShiftClockController: ShiftClockSource, and BurstClockController wrappers when the
PhysicalRegion wrapper matches the root physical region. You use the ClockInput property,
then the MemBistController: TestClockSource, ShiftClockController: ShiftClockSource,
and BurstClockController wrappers are within a sub-physical region.
Example
The following example shows that the top-level pin clk2 will be sourcing the System_2 and
System_4 TestClockSource’s for all the memory BIST controllers in the root physical region
top with module name and/or instance name containing the string .*F300.*.
TestClockSource (System_.*) {
Pin: clk2;
}
}
}
}

September 2017
Pin
...
}
Related Information
BurstClockController ShiftClockController
ClockInput ShiftClockSource
ClockSourceOverride TestClockSource
MemBistController UserDefinedSequence
PhysicalRegion

September 2017
PinComments
PinComments
The PinComments property enables you to specify whether to include comments for every
compare in the generated test bench or test vector file.
Syntax
PinComments: (On) | Off;

• On—specifies that your simulator displays comments each time it compares a pin to a
specific value during simulation.
• Off—specifies that your simulator does not display comments each time it compares a pin to
a specific value during the test bench simulation.
Default Value
The default value is On. The default is to generate comments on each output comparison.
Usage Conditions
Adding comments for each output comparison increases the pattern storage size. If you want to
conserve pattern storage size, set PinComments to Off.
Example
In this example, your simulator does not display comments each time it compares a pin to a
specific value during simulation.
etv (MyDesignA) {
JtagVerify (ETC) {
PinComments: Off;
}
}
Related Information
JtagVerify

September 2017
PinCompares
PinCompares
The PinCompares wrapper specifies for ETVerify to compare a top-level port (primary output
or bidirectional) or internal pin to a given value.
Syntax
PinCompares {
<pinName>: 0 | 1 | X;
}

• pinName — specifies a valid name for a top-level port (primary output or bidirectional) or
internal pin. pinName can be any valid design port or pin name.
• 0 — indicates a logic 0 value is compared on the top-level port (primary output or
bidirectional) or internal pin.
• 1 — indicates a logic 1 value is compared on the top-level port (primary output or
bidirectional) or internal pin.
• X — indicates to stop comparing a value.
Default Value
None
Usage Conditions
The PinCompares wrapper is used in the following types of verification:
Table A-9. PinCompares Usage Conditions

Usage Conditions User- Custom TAP Memory SerdesTest
Defined Verification Verification BIST Verification
Sequence Section Section Verification Section
Section Section
pinName must be a X X X X X
top-level port
(primary output or
bidirectional) or an
internal pin.1 For
bidirectional ports,
the input path
should also be set to
a constant value
with the PinSettings
wrapper.

September 2017
PinCompares
Table A-9. PinCompares Usage Conditions

Usage Conditions User- Custom TAP Memory SerdesTest
Defined Verification Verification BIST Verification
Sequence Section Section Verification Section
Section Section
You can use this X X
wrapper in the
xxxVerify wrapper.
This enables you to
specify constant
values to be
compared during all
test steps.
You can use this X X X X
wrapper in the
TestStep wrapper.
This enables you to
specify constant
values to be
compared during a
specific test step.
1. Internal pins are supported only when generating a Verilog test bench; the -verilog runtime option must
be On.
Example 1
The syntax below requests the pin OUT1A to be compared to a logic 0 value until a new
PinCompares wrapper in a subsequent step requests the pin to be compared to either X or 1.
etv (MyDesignA) {
CustomVerify (1) {
PinCompares {
OUT1A: 0;
}
}
}
Example 2
The syntax below requests that the internal pin tlb_inst/data_mux/Y be compared to 1 in the
RunTimeProg TestStep.
etv (MyDesignA) {
membistPVerify(top_P1) {
TestStep (RunTimeProg) {
PinCompares {
tlb_inst/data_mux/Y: 1;
}
}
}

September 2017
PinCompares
Related Information
JtagVerify TestStep
MembistVerify

September 2017
PinInv
PinInv
If the specified Pin in your UserDefinedSequence: ClockSourceOverride wrapper is the positive
clock pin of a differential clock pair then you must use the PinInv to declare the negative
differential clock pin.
Syntax
PinInv: <string>;
where string is a top-level pin name.

Default Value
None
Usage Conditions
Example
The following example shows that the top-level differential clock pins clk2_P and clk2_N will
be sourcing the System_2 and System_4 TestClockSource’s for all the memory BIST controllers
in the root physical region top which module name and/or instance name contain the string
.*F300.*.
UserDefinedSequence(1) {
Pin: clk2_P;
PinInv: clk2_N;
}
}
}
}
...
}
Related Information
BurstClockController PhysicalRegion
ClockInput ShiftClockController

September 2017
PinInv
ClockSourceOverride ShiftClockSource
MemBistController TestClockSource
Pin UserDefinedSequence

September 2017
PinSettings
PinSettings
The PinSettings wrapper enables you to specify constant values for input pins.
Syntax
PinSettings {
<pinName>: 0 | 1 | Z;
}
• pinName — specifies a valid name for a primary input or bidirectional pin. pinName can be
any valid design pin name.
• 0 — indicates a logic 0 value is forced on the primary input pin.
• 1 — indicates a logic 1 value is forced on the primary input pin.
• Z — indicates a Z value is forced on the primary input pin.
Default Value
None

September 2017
PinSettings
Usage Conditions
The PinSettings property is used in the following types of verification:
Table A-10. PinSettings Usage Conditions

Usage Conditions User- Custom Logic BIST SerdesTest
Defined Verification Verification Verificatio
Sequence Section Section n Section
Section
Memory
BIST
Verification
Section
TAP
Verification
Section
WTAP
Verification
Section
Scan
Verification
Section
pinName must be a top-level port (primary X X X X
output or bidirectional). For bidirectional
ports, the output path should also be set to a
constant value with the CellSettings
wrapper.
You can use the PinSettings wrapper in an X X X
xxxVerify wrapper outside of the
TestStep wrapper. This global setting
enables you to specify constant values to be
applied during all test steps. This value will
remain active until changed by new
PinSettings on the same pin.
You can use the PinSettings wrapper within X X X
the TestStep wrapper. This enables you to
specify constant values to be applied only
during a specific test step.
You can use the InitialWaitCycles or Pause X
property to set a delay between application
of PinSettings and the start of the test.
Example 1
The syntax below forces a logic 0 value on the pin named IN1A during this test step.

September 2017
PinSettings
etv (MyDesignA) {
TestStep (0) {
PinSettings {
IN1A: 0;
}
}
}
}

September 2017
PinSettings
Example 2
The syntax below forces a logic 0 value on the pin named IN1A at the beginning of the pattern
during this test step.
etv (MyDesignA) {
CustomVerify (MySequence) {
PinSettings {
IN1A: 0;
}
}
}
Related Information
CustomVerify Pause
InitialWaitCycles TestStep
LogicbistVerify UserDefinedSequence
MembistVerify

September 2017
PostAmble
PostAmble
The PostAmble wrapper is used for multi-chip modules that consist of two or more die
chained with the next die. ETVerify will generate test patterns to address the die-under-test. The
PostAmble wrapper is used to place all the TAPs daisy-chained on the TDO of the die-under-
test in Bypass mode.
Syntax
PostAmble {
}
}
Example
Refer to Figure A-16 for an example of the PostAmble wrapper.
Usage Conditions
This property is used in the JTAPAccess wrapper inside the Global Section.
Related Information
JTAPAccess PreAmble
BypassOpCode Tap
DeviceId

September 2017
PostTAPUserDefinedSequence
The PostTAPUserDefinedSequence property enables you to specify the name of the user-
defined sequence to be included in a pattern after the Mentor Graphics TAP has been
reset/accessed. The UDS name must correspond to sequenceName of a UserDefinedSequence
wrapper in the current configuration file or to the name of a user-defined sequence that already
exists.
If you want a UDS pattern to be applied before the TAP is accessed you use the
PreTAPUserDefinedSequence property that points to a .pgsl_uds file that only performs
PinSettings, PinCompares, Pauses and ApplyTCKClockCycles.
An .pgsl_uds file used by the PostTapUserDefinedSequence property will be applied after the
TAP has been reset.
Syntax
When the PostTAPUserDefinedSequence property is specified, ETVerify looks for the

following UDS files:
• <UserDefinedSequenceDir>/<sequenceName>.pgsl_uds when the ETVerify runtime
option -inputLVDBName is not specified. If -userDefinedSequenceDir is not explicitly
specified, <UserDefinedSequenceDir> defaults to <outDir>/UserDefinedSequences.
• <inputLVDBName>/UserDefinedSequences/<sequenceName>.pgsl_uds when the
ETVerify runtime option -inputLVDBName is specified
When LVDB is created, all UDS files found in the directory pointed to by -
userDefinedSequenceDir are automatically copied into the UserDefinedSequences directory
inside the LVDB directory.
Default Value
None
Usage Conditions

September 2017
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• SerdesVerify
• ScanVerify
• WTAPVerify
This usage condition applies:
• When an SVF file is used in PostTAPUserDefinedSequence, you must ensure that the
Mentor Graphics TAP controller is placed in the Run Test Idle state after the SVF sequence
is applied.
Example
This example specifies that a user-defined initialization sequence, MyPostTapSequence, is to be
used for the verification of the ETC functionality.
etv (MyDesignA) {
PinSettings {
IN1A: 0;
}
Pause: 10ms;
MISRCompares: 4;
UserDRBit(14): On;
PostTAPUserDefinedSequence: MyPostTapSequence;
}
}
Related Information
ApplyTCKClockCycles WTAPVerify
CustomVerify Pause
JtagVerify PinCompares
LogicbistVerify PinSettings
MembistPVerify PreTAPUserDefinedSequence
ScanVerify -inputLVDBName
SerdesVerify -userDefinedSequenceDir

September 2017
PostTestUserDefinedSequence
The PostTestUserDefinedSequence property enables you to specify the name of the user-
defined sequence to be included in a pattern which will be applied at the very end of the test.
The UDS name must correspond to sequenceName of a UserDefinedSequence wrapper in the
current configuration file or to the name of a user-defined sequence that already exists.
Syntax
When the PostTestUserDefinedSequence property is specified, ETVerify looks for the

ETVerify runtime option
-inputLVDBName is specified
Default Value
None
Usage Conditions
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• ScanVerify
• SerdesVerify
• WTAPVerify
Example
This example specifies that a user-defined sequence, disable_lv_tap, is to be applied after
TestStep(1) has completed.

September 2017
etv (MyDesignA) {
PinSettings {
IN1A: 0;
}
Pause: 10ms;
MISRCompares: 4;
UserDRBit(14): On;
PostTestUserDefinedSequence: disable_lv_tap;
TestStep (0) {
...
}
TestStep (1) {
...
}
}
}
Related Information
ApplyTCKClockCycles Pause
CustomVerify PinCompares
JtagVerify PinSettings
LogicbistVerify PreTAPUserDefinedSequence
MembistPVerify PostTAPUserDefinedSequence
ScanVerify -inputLVDBName
SerdesVerify -userDefinedSequenceDir
WTAPVerify

September 2017
PowerDomainGroupLabels
The PowerDomainGroupLabels property enables you to specify which power domain group
or groups you want the operation to be performed on.
Syntax
PowerDomainGroupLabels: <listOfLabels>;
where listOfLabels is a list of power domain group labels. Memories that were not associated
with a label in ETChecker are associated with a label called “-”.
Default Value
The default value is * that means the operation is to be applied to all power domain groups.
Usage Conditions
This property is used in the TestStep: Controller wrapper of the following xxxVerify wrappers:
• MembistPVerify
• MembistVerify
• This property can only specify one PowerDomainGroupLabel or “*” when RunMode is
BisrChainAccess.
• This property can be a list of PowerDomainGroupLabels or “*” when RunMode is
Autonomous, and AutonomousOperation is VerifyFuseBox or PowerUpEmulation.
• This property can only be “*” when RunMode is Autonomous, and AutonomousOperation is
ClearBisrChain or SelfFuseBoxProgram.
Example
This example specifies that the VerifyFuseBox operation is to be applied to
PowerDomainGroup A and “-”
etv (MyDesign) {
MembistVerify (ETC) {
Controller (BP0) {
AutonomousOperation: VerifyFuseBox;
PowerDomainGroupLabel: A, -;
}
}
}
Related Information
AutonomousOperation MembistPVerify

September 2017
RunMode TestStep

September 2017
PowerLevel
PowerLevel
The PowerLevel property enables you to reduce power consumption during test. The ETVerify
tool generates setup instructions to the prescaler block to reduce the shift frequency when
loading a logic BIST vector. The last few shift clocks and the capture clock are run at the full
test clock frequency.
• No at-speed test coverage is lost through the use of this scheme.
• The capture speed is not affected.
Note
This property is only applicable for pre-5.0 logic BIST controllers.
Syntax
PowerLevel: (Full) | P7_8 | P3_4 | P5_8 |
P1_2 | P3_8 | P1_4 | P1_8;
• Full — indicates shift frequency at full speed.
• P7_8 — indicates shift frequency at 7/8 of full speed.
Default Value
The default value is Full.
Usage Conditions
This property is used in the TestStep wrapper of the following xxxVerify wrappers:
• LogicbistVerify
• ScanVerify
• This option requires the following:
a. IEEE 1149.1 TAP controller
b. Chip-level clock prescaler with low power mode capabilities

September 2017
PowerLevel
• When you specify a shift frequency that is less than full speed, power is reduced but test
time is approximately increased by the multiplier 1/ratio. Ratio is the fractional value
specified (from the available values shown in the syntax). For example, if you specify the
value P1_8, the test time is increased by an approximately factor of 8.
Example
This example specifies that the logic BIST controller is programmed to run with a shift
frequency of 1/2 of full speed.
etv (MyDesignA) {
TestStep (1) {
PinSettings {
IN1A: 0;
}
Pause: 10ms;
MISRCompares: 4;
UserDRBit(14): On;
PowerLevel: P1_2;
}
}
}
Related Information
ScanVerify

September 2017
PreserveFuseRegisterValues
The PreserveFuseRegisterValues property specifies whether the repair analysis registers
preserve their values from a previous test step. This inhibits the loading of the BISR register
values into the repair analysis registers when a new test step begins. In the incremental repair
flow, this property also inhibits the transfer of the BISR register content into the BIRA registers.
Syntax
PreserveFuseRegisterValues: On | (Off);

• On — specifies that the fuse registers values are to be preserved.
• Off — specifies that the fuse registers values are reset during the multi-cycle initialization of
the execution algorithm.
Default Value
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
These usage conditions apply when this property is set to On:
• At least one memory tested by repair analysis must be specified in the memory library file.
• To maintain register contents, the BIST controller must remain powered up and the TAP
must not be reset between BIRA controller runs.
• For programmable controllers generated before v2014.3, the RunMode property should be
set to RunTimeProg.
• For non-programmable controllers generated before v2012.4, one of the following methods
must be used to determine whether repair is needed in order to avoid test escapes:
o Perform a BIRA-to-BISR transfer and scan out the BISR registers at the end of all
BIRA controller runs as shown in the BISR Manufacturing Flow Example figure in
the Tessent MemoryBIST User’s and Reference Manual. This is the recommended
method when BISR is present.
o Set the ETVerify property ExtractRepairFuseMap to On only for the last BIRA
controller run and check whether the content of the BIRA registers is different from
0. This is the recommended method when BISR is not present.

September 2017
o Set the ETVerify property CheckRepairStatus to On for all BIRA controller runs and
check whether RepairStatus[0] is different from 0 for any of the runs. This method
requires a more complex test program.
Example
The following example shows a portion of a repair flow in which memories are tested at two
different voltages. The PreserveFuseRegisterValues property is set to On in the third TestStep
to preserve the state of the BIRA registers obtained in the second TestStep and calculate the
final repair solution covering both voltage conditions.
etv (MyDesignA) {
MembistPVerify (MBIST_repair_flow) {
TestStep (1_BISR_Power_Up) {
Controller (BISR_top_ctrl) {
AutonomousOperation: PowerUpEmulation;
}
}
TestStep (2_MBIST_pre-repair_LowVcc) {
Controller (MBIST_ctrl1) {
CheckRepairStatus: NonRepairable;
CompareGo: On;
PreserveFuseRegisterValues: Off; // BIRA registers initialized
// with BISR register content
}
}
TestStep (3_MBIST_pre-repair_HighVcc) {
Controller (MBIST_ctrl1) {
CheckRepairStatus: NonRepairable;
CompareGo: On;
PreserveFuseRegisterValues: On; // BIRA registers are not
// initialized
}
}
TestStep (4_Check_repair_needed) {
CheckRepairNeeded: On;
}
}
}
Related Information
Controller RunMode
MembistVerify

September 2017
PreAmble
PreAmble
The PreAmble wrapper is used for multi-chip modules that consist of two or more die packaged
into a single part. Each die will have an IEEE 1149.1 TAP module that is daisy-chained with the
next die. ETVerify will generate test patterns to address the die-under-test. The PreAmble
wrapper is used to place all the TAPs daisy-chained on the TDI of the die-under-test in Bypass
mode.
Syntax
PreAmble {
}
}
Example
Refer to Figure A-16 for an example of the PreAmble wrapper.
Usage Conditions
This wrapper is used in the JTAPAccess wrapper inside the Global Section.
Each PreAmble wrapper can have multiple Tap wrappers; the first Tap wrapper describes the
first TAP in the daisy chain.
Related Information
JTAPAccess PostAmble
BypassOpCode Tap
DeviceId

September 2017
PreTAPUserDefinedSequence
The PreTAPUserDefinedSequence property enables you to specify the name of the user-
defined sequence (UDS) to be included in a pattern before the Mentor Graphics TAP is
reset/accessed. The UDS name must correspond to a sequenceName of a UserDefinedSequence
wrapper in the current configuration file or to the name of a user-defined sequence that already
exists.
If you want a UDS pattern to be applied after the TAP is accessed, use the
PostTAPUserDefinedSequence property.
Syntax
When the PreTapUserDefinedSequence property is specified, ETVerify looks for the

When LVDB is created, all UDS files found in the directory pointed to by
-userDefinedSequenceDir are automatically copied into the UserDefinedSequences directory
Default Value
None
Usage Conditions
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• ScanVerify
• SerdesVerify
• WTAPVerify

September 2017

• When an SVF file is used in PreTAPUserDefinedSequence it is assumed that the Mentor
Graphics TAP controller has been reset in the SVF. So, after the SVF sequence is applied,
you must ensure that the Mentor Graphics TAP controller is placed in the Run Test Idle
state.
• If you need a clock to toggle during the PreTAPUserDefinedSequence, you must do the
following:
o If the BIST controller uses the clock and, therefore, the clock must remain active
during the BIST operation, start the clock with the following syntax:
DefineClock(P|N): <pinName>;
o If the BIST controllers do not use the clock, toggle the clock with the
PreTAPUserDefinedSequence property so that the clock stops after the UDS and
does not burn power needlessly during the BIST operation.
Example 1
The following example specifies that a user-defined initialization sequence,
MyPreTapSequence, is to be used for the verification of the ETC functionality.
etv (MyDesignA) {
UserDefinedSequence (MyPreTapSequence) {
}
PinSettings {
IN1A: 0;
}
Pause: 10ms;
MISRCompares: 4;
UserDRBit(14): On;
PreTAPUserDefinedSequence: MyPreTapSequence;
}
}
Example 2
The following example shows a memory BIST pattern whose clock, clk, is also used in the
PreTAPUserDefinedSequence EnableTAP. To start the memory BIST clock at time 0 for the
PreTAPUserDefinedSequence, the DefineClock property is used.
MembistPVerify(block1_P1) {
PatternName: membistpv_P1_block1;
TestClockSource: Functional; // clk
ClockPeriod: 5.0ns;
TCKRatio: 8;
PostTAPUserDefinedSequence: PLLX7;
DefineClock(P): clk;
TestStep (MyRunProg) {

September 2017
Controller (BP1.WBP0) { //block1_clk_MBIST1_LVISION_MBISTPG_CTRL
CompareGoID: On;
CompareGo: On;
ReducedAddressCount: On;
}
}
}
Related Information
ApplyTCKClockCycles WTAPVerify
CustomVerify Pause
JtagVerify PinCompares
LogicbistVerify PinSettings
MembistPVerify PostTAPUserDefinedSequence
MembistVerify PostTestUserDefinedSequence
ScanVerify UserDefinedSequence
SerdesVerify -inputLVDBName
DefineClock -userDefinedSequenceDir

September 2017
PullResistor
PullResistor
The PullResistor property enables you to specify the presence of an external pull resistor on a
design pins.
Syntax
• None — specifies that no pull resistor is attached to the design pin.
• Up — specifies that a pull-up resistor is attached to the design pin.
• Down — specifies that a pull-down resistor is attached to the design pin.
Default Value
Usage Conditions
If the PullResistor property does not exist in the DesignPin wrapper, the tester channel is
considered having no attached pull resistor.
Example
This example specifies that pull resistors are attached on the pins OutOC1 and OutCC1.
etv (MyDesignA) {
JtagVerify (ETC) {
ContactedPins {
DesignPin (OutOC1){
PullResistor: Up;
}
DesignPin (OutOCC1){
Observation: TwoState;
PullResistor: Down;
}
}
}
}
Related Information
ContactedPins JtagVerify
DesignPin

September 2017
ReducedAddressCount
ReducedAddressCount
The ReducedAddressCount property enables the memory BIST controller to be run on the
four corners of the common memory address space. This is useful to check the proper
functionality of the BIST controller without having to simulate the test of the entire memory
space. Static timing analysis is required in the full chip context to verify that the timing between
the controllers and the memories is valid. Note that the full address space should be simulated
on the assembly module before it is merged into the chip.
When ReducedAddressCount is On, and your memory BIST controller contains a step with
multiple memories, the controller runs all algorithm phases of the test only on the following
four addresses that must be common to all memories in that step:
• RowMin, ColMin
• RowMax, ColMin
• RowMin, ColMax
• RowMax, ColMax
If the memory has only Row address bits then the reduced address range would be the two
locations:
• RowMin
• RowMax
Note
The new port must be connected to a user IR bit if there is a need to run ETVerify with
ReducedAddressCount: On in the HWDefault mode. However, it is always possible to
run ETVerify with ReducedAddressCount: On in the RunTimeProg mode even if the port
is tied off.
Syntax
ReducedAddressCount: On | (Off);

• On—specifies that the generated ETVerify test bench would be for a reduced address count
simulation.
• Off—specifies that ETVerify should generate a test bench with a full address counting.
Default Value
Usage Conditions

September 2017
ReducedAddressCount
• MembistPVerify
• MembistVerify
Ensure that you performed complete gate-level verification of the memory BIST assembly
module after you generated it before you take advantage of the reduced address count operation
to reduce verification time of the memory BIST at the top-level of the chip.
Example
This example specifies that the test bench generated by ETVerify would verify the controller for
a reduced address count
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
ReducedAddressCount: On;
}
}
}
}
Related Information

September 2017
RetentionTime
RetentionTime
The RetentionTime property enables you to control the duration of the flop retention test
performed during the flop flush test. Test sequence performs the retention test of flip-flops with
the clock frozen high and low.
Syntax
RetentionTime: <time>;
where time specifies the duration of the retention test.

Default Value
The default value is 1ms.
Usage Conditions
• This property is meaningful only when the FlushTest property is turned on.
• As soon as either AsyncSetResetTest, or FlushTest, or RetentionTime is present in the
ScanVerify: Controller wrapper, these tests are the only ones that are generated for the
controller. Any other property, other than the AsyncSetResetTest, FlushTest, and
Example
This example specifies that the flush test is to be applied on the scan chains controller by the
logic BIST controller BP5.WBP0, and that the flops in these chains will be tested for retention
after 2ms.
etv (MyDesignA) {
ScanVerify (ETC) {
TestStep (3) {
FlushTest: On;
RetentionTime: 2ms;
}
}
}
}
Related Information
AsyncSetResetTest ScanVerify
Controller FlushTest

September 2017
RPAChannelEnable
RPAChannelEnable
The RPAChannelEnable property enables the Receive Pattern Analyzer (RPA) for one
channel. Given that this property is repeatable, many RPAs can be started during the course of
one test. In the case of the FunctionalLoopback test, when a specific channel is selected with the
ChannelSelect property, the RPA associated with this channel is automatically started. For any
other test, the pattern matching portion of the RPA is never asked to recognize a pattern, since
the receiver is not locked to the data for any other test.
For the case of the FunctionalLoopback test, the success of the test will be verified for all those
TPGs and RPAs that are started at the beginning of the test.
Syntax
RPAChannelEnable: <int>;

Default Value
The default value depends on the ChannelSelect value.
Usage Conditions
generated. The ETVerify tool will automatically validate this value and reject invalid ones.
Example
TestSelect: FunctionalLoopback;
Related Information
ChannelSelect TestStep
Controller TPGChannelEnable
SerdesVerify Channel in the manual ETPlanner Tool
Reference

September 2017
RunLength
RunLength
The optional RunLength property is used to specify the number of clock cycles required to
execute the algorithm.
Syntax
RunLength: <integer>;
where integer specifies the number of BIST clock cycles required to execute the algorithm.
Default Value
The default value for RunLength can be calculated. In most cases, RunLength is sufficient.
The ability to define RunLength provides you with flexibility to accommodate extreme cases
where the calculated RunLength is not accurate.
Usage Conditions
• When the RunLength is specified a detailed summary of the algorithm is not displayed.
• The default value for RunLength is automatically calculated, and the algorithm execution
time will be sufficient in most cases.
Example
The following syntax specifies that the algorithm run length is 10880 BIST Clock cycles:
MembistpVerify (MyDesign) {
TestStep (4) {
RunLength: 10880;
} //end of MembistpVerify wrapper
Related Information
Controller TestStep
MembistPVerify

September 2017
RunMode
RunMode
The sections below provide detailed information on the following usage of the RunMode
property:
• “MembistPVerify and MembistVerify Usage” on page 481
The RunMode property enables you to specify whether or not the test bench or test vector set
created by ETVerify runs the logic BIST controller with its default settings or with scanned-in
settings. Scanned-in settings are used to run the logic BIST at starting and ending vectors with
signatures other than the one hard-coded into the logic BIST controller.
Syntax
The following syntax specifies this property in the LogicbistVerify wrapper:
RunMode: HWDefault | (RunTimeProg) |
HWDefaultInitTest | HWDefaultTest |
SingleCompressedATPG;

• HWDefault — specifies that the logic BIST controller uses its default settings.
• RunTimeProg — specifies that the logic BIST controller settings are scanned in.
Only applicable for pre-5.0 logic BIST controllers
• HWDefaultInitTest — specifies that the logic BIST controller starts and loads its default
values into the MISR and PRPG, and then shifts out these values for validation.
Only applicable for pre-5.0 logic BIST controllers
• HWDefaultTest — specifies that the logicBIST controller starts and loads its default values
into the MISR and PRPG, and then shifts out these values for validation. Then, the last
default vector is loaded into the logicBIST controller to verify that the MISR strap produces
a correct signature.
• SingleCompressedATPG — specifies that the logic BIST controller will load the new PRPG
seed from the TAP/WTAP at the beginning of each vector. Each new PRPG is shifted in the
Seed register in the TAP/WTAP using a single scan chain accessed by the TDI and TDO
pins. The new PRPG seed is decompressed in the circuit by the logic BIST controller.
Default Value
The default value is RunTimeProg.
Usage Conditions

September 2017
RunMode
• HWDefaultInitTest and HWDefaultTest values are only applicable for pre-5.0 logic BIST
controllers.
• When you set RunMode to HWDefault, you must set the MISRCompares property to 0 or
1. The StartVector property must be 1 (the default value). The EndVector property must be
the last available vector (the default value).
• Use scanned-in settings to reduce or increase the number of vectors that a controller
executes. Typically, you specify the value RunTimeProg when you are using ETVerify for
one of the following tasks:
o Creating test benches that include the first few vectors and last few vectors to verify
your embedded test.
o Creating test vector sets for diagnosis of failing devices.
Refer to Example 1.
• When you set the RunMode property to HWDefaultInitTest, note the following:
o The UseAsyncClocks property should be set to On.
o The PowerLevel and Diagnostic properties must be set to their default values.
o Multiple controllers can be tested in parallel by repeating the Controller wrapper.
Refer to “Example 2” on page 480.
• Setting the RunMode property to HWDefaultTest results in the creation of two TestStep
wrappers:
o The first TestStep wrapper runs with RunMode set to HWDefaultInitTest.
o The second TestStep wrapper sets the RunMode property to RunTimeProg. The
StartVector and EndVector properties are set to the last default vector.
This test step just loads in the last vector and then checks the MISR strap to verify
that it produces the correct signature.
• When you set the RunMode property to HWDefaultTest, note the following:
o The UseAsyncClocks properties should be set to On.
o The PowerLevel and Diagnostic properties must be set to their default values.
o The user-specified values for StartVector and EndVector are ignored.
Example 1
This example specifies that the logic BIST controller is run based on scanned-in settings.

September 2017
RunMode
etv (MyDesignA) {
TestStep (1) {
PinSettings {
IN1A: 0;
}
Pause: 10ms;
MISRCompares: 4;
}
}
}
Example 2
This example specifies that the logic BIST controller starts and loads its default values into the
MISR and PRPG, and then shifts out these values for validation.
etv (MyDesignA) {
TestStep (HWDefaultInitTest) {
InitialWaitCycles: 0ms;// Optional
Pause: 0ms;// Optional
RunMode: HWDefaultInitTest;
Controller (BPX) {
}
}
}
}
Example 3
This example specifies that the logic BIST controller and MISR strap are quickly tested.
etv (MyDesignA) {
TestStep (HWDefaulTest) {
InitialWaitCycles: 0ms;
Pause: 0ms;
RunMode: HWDefaultInitTest;
Controller (BPX) {
}
}
TestStep (HWDefaultTest_Strap) {
Controller (BPX) {
StartVector: LastDefaultVector;
EndVector: LastDefaultVector;
}
}
}
}

September 2017
RunMode
Related Information
Controller ParallelLoad
LogicbistVerify PowerLevel
Diagnostic StartVector
EndVector TestStep
RunMode LogicbistVerify
MISRCompares UseAsyncClocks

The RunMode property specifies if the memory BIST controllers should be run using their
default settings or based on scanned-in settings.
Syntax
The following syntax specifies this property when used with a memory BIST controller:
RunMode: (HWDefault) | RunTimeProg;
The following syntax specifies this property when used with a BISR loader controller:
RunMode: Autonomous | BisrChainAccess | FuseBoxAccess;
Valid values are as follows:

• HWDefault — specifies that the memory BIST controller uses its default settings.
• RunTimeProg — specifies that the memory BIST controller settings are scanned in.
• Autonomous — specifies that the BISR loader runs in autonomous mode.
• BisrChainAccess — specifies that the BISR loader enables access to the BISR chain using
the TDI and TDO top-level TAP ports.
• FuseBoxAccess — specifies that the BISR loader enables access to the fuse box using the
TDI and TDO top-level JTAP ports.
Default Value
The default value is HWDefault.
Usage Conditions
This property is used in the MembistPVerify: TestStep and MembistVerify: TestStep wrappers.
• You must set RunMode to RunTimeProg when any of the following properties are set to a
non-default value:
o FailureLimit
o FreezeStep
o FreezeTestPort

September 2017
RunMode
o HardCodedAlgorithm
o SelectLibraryAlgorithm
• The HWDefault and RunTimeProg values can only be used with a memory BIST controller.
• The Autonomous, BisrChainAccess, and FuseBoxAccess values can only be used with a
BISR loader controller.
Example
This example specifies that the BIST controllers is run based on scanned-in settings.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
}
}
}
Related Information
FailureLimit MembistPVerify
FreezeStep MembistVerify
FreezeTestPort SelectLibraryAlgorithm
HardCodedAlgorithm TestStep

September 2017
RunTest
RunTest
The sections below provide detailed information on the following usage of the RunTest
property:
JtagVerify Usage
The RunTest property enables you to specify the type of tests (algorithms) to run in the
verification test bench that ETVerify creates. These algorithms enable you to customize the
generated patterns to reduce simulation time and ensure high manufacturing test coverage.
Syntax
RunTest: BScanReg | BypassReg | Clamp |
Controlr | DisabledOutputs | HighZ |
HighzMode | IDReg | IIH | IIL | Input |
InstReg | Output | OutputClamp | Sample |
TAPIntDR | TestLogicReset | VOH | VOL |
LeakageNC | TristateEnableNC | None;

• BScanReg — ensures the boundary scan data register responds properly to the TAP state
machine and that the test bench can load the boundary scan register. This algorithm uses the
SAMPLE instruction, shifting data through the boundary scan chain only. Testing whether
the boundary scan chain can actually capture and update data to the pins is performed as part
of the InputTest and OutputTest algorithms, and is therefore not included as part of the
BscanRegTest algorithm.
• BypassReg — ensures that the data register state machine is functioning properly and that
the test bench can load the bypass register. This algorithm scans through the bypass register
each time, comparing the bypass register capture value to 0. The algorithm also steps
through all possible state transitions associated with a data register scan operation.
If the TAP does not track states of the FSM (finite state machine) properly, a 1-bit delay
does not appear in subsequent data register scan operations. The test bench performs a final
check of the bypass operation codes by scanning a 11111 pattern through the bypass register
using every operation code.
• Clamp — includes a clamp test in the generated pattern to verify the CLAMP instruction.
The clamp test consists of creating various clamp states and verifying that the output and the
bidirectional pins are in the correct states. The clamp test exercises each boundary scan cell

September 2017
RunTest
with each pin driven in the high and the low state. In addition, the clamp test performs a
scan-through test of the bypass register.
• Controlr — tests whether all controlr cells are reset to their disable state after a TAP
controller reset. Execution is conditional upon the presence of at least in one controlr cell.
• DisabledOutputs — disables all pads in EXTEST mode by scanning a disabling value in all
their enable cells. Tests the output for high impedance. Execution is conditional to the
presence of at least one controlr or opendrain/source pad.
• HighZ — includes a highz (high-impedance) test in the generated pattern set to verify the
operation of the HIGHZ instruction. The test bench loads the HIGHZ opcode into the TAP,
driving all output and bidirectional pins into high-impedance states. Note that this test
actually executes the following three tests: DisabledOutputs, HighzMode, and Controlr.
• HighzMode — disable all pads via the TAP HIGHZ instruction. Tests all outputs for high
impedance. Execution is conditional to the existence of a TAP HIGHZ instruction.
• IDReg — ensures that the ID register is responding properly to the TAP data register state
machine. This algorithm compares the capture values of the device ID and status registers
whenever a data register scan operation is performed. The algorithm steps through all
possible state transitions associated with a data register scan operation.
If the device ID register does not track the state machine states properly, the idcode value
scanned out does not appear in subsequent data register scan operations. This algorithm
performs a final check of the idcode operation codes using every opcode.
• IIH — presets input pins so that the tester can drive the pins to their high values and measure
the current of these pins. The tester stops the test to measure current, then resumes the test.
• IIL — presets input pins so that the tester can drive the pins to their low values and measure
the current of these pins. The tester stops the test to measure current, then resumes the test.
• Input — includes an input test for all pins in the generated test bench, using standard IEEE-
1149.1 timing. An input test checks that the boundary-scan cells perform a proper capture of
input data.
This algorithm tests all input, observe-only, and clock boundary-scan cells when the TAP IR
is loaded with the EXTEST instruction. In addition, it also tests the INPUT direction of all
bidirectional cells. The test bench turns off all pad drivers, including the bidirectional ones.
The test bench applies alternate EVEN and ODD checkerboard patterns to all input and
bidirectional contacted pins that have tester control capabilities. Cells are pre-loaded with
their pin state opposite value. All non-X cell captured values are compared at TDO,
including the ones resulting from the following:
o Cells capturing themselves or a constant value in EXTEST mode.
o When a pin is tied to a constant value by the DUT card.
o The presence of an internal or external pullup or pulldown resistor at the output of an
uncontrollable bidirectional pin.
• InstReg — ensures that the test bench can load the instruction register. The 2 least
significant bits are checked on every instruction register scan operation. This algorithm

September 2017
RunTest
steps through all possible state transitions associated with an instruction register scan
operation.
If the TAP does not track states of the FSM (finite state machine) properly, the standard 01
bits of the instruction register do not appear in a subsequent IR operation.
• Output — includes an output test for all pins in the generated test bench, using standard
IEEE 1149.1 timing. An output test checks that the boundary scan cells perform a proper
capture of output data. This test verifies the preload functionality of the
SAMPLE/PRELOAD instruction.
This algorithm tests output and bidirectional boundary-scan cells when the TAP IR is loaded
with the EXTEST instruction. Output and bidirectional pad drivers are turned on
sequentially on a per enableGroup basis. All enabled output and bidirectional cells are
loaded alternatively with EVEN and ODD checkerboard patterns. The output and
bidirectional pins are strobed if they are both contacted and observable. All non-X values
captured by the boundary-scan cells are compared at TDO, including the ones from the
following:
o Cells capturing themselves or a constant value in EXTEST mode.
o Enabled bidirectional boundary-scan cells that capture the pin state in EXTEST
mode.
o Disabled bidirectional boundary-scan cells that have an internal or external
pullup/pulldown resistor.
o Input pins driven by a DUT loopback from an output or bidirectional pin.
o Input cell captured value for all enabled bidirectional pads controlled by the
combination of one output and one input or sample boundary-scan cell.
• OutputClamp — adds a short clamp test part to the output test. During the output test, after
each load of the boundary-scan register and each strobing of the enabled output and input
pins, the following is performed:
o TAP IR is re-programmed with the CLAMP instruction.
o Test bench verifies whether the BYPASS register is selected.
o Output pins are strobed again to verify that they are to retain the initial OUTPUT
state value in CLAMP mode.
o TAP IR is re-programmed with the EXTEST instruction, and the OUTPUT test
resumes from there.
• LeakageNC — tests the input leakage current that causes a pad voltage floating at logic 0 to
charge to a logic 1 or a pad voltage floating at logic 1 to discharge to logic 0.
• Sample — checks that the boundary-scan cells perform a proper capture of input data, like
the InputTest algorithm, with the exception that the test bench does not include bidirectional

September 2017
RunTest
pins in the test. This algorithm uses the SAMPLE instruction instead of the EXTEST
instruction.
This algorithm tests all input, observe-only, and clock cells when the TAP IR is loaded with
the SAMPLE instruction. This test is similar to the Input test, except the tester never forces
the pin state of any bidirectional pins because their pad driver cannot be turned off by the
boundary-scan in SAMPLE mode.
• TAPIntDR — performs a flush test on the internal INT_DR register if it is present. Note that
this test cannot verify neither the captured nor the updated values since those come from a
circuit which is external to the TAP controller.
• TestLogicReset — verifies that the TAP is being reset properly. Note that the boundary scan
chain contains safe data values, and that either the EXTEST or SAMPLE instruction is active.
• TriStateEnableNC — initializes all output drivers of a pin to a logic 1 or logic 0 and tests the
global forceDisable signal from the TAP and the local enable signal supplied by an enable
cell for a group of pins.
• VOH — presets output pins so that the tester can drive the pins to their high values and
measure the voltage of these pins. The tester stops the test to measure voltage, then resumes
the test.
• VOL — presets output pins so that the tester can drive the pins to their low values and
measure the voltage of these pins. The tester stops the test to measure voltage, then resumes
the test.
• None — enables you to intentionally specify that no test is performed in this step. This can
be required when the intent is to set up IR or DR bits or fault insertion. Omitting the
RunTest property in the test step results in the issuing of a warning.
Additional Specific Syntax for 1149.6
Additional tests are available if your hardware supports 1149.6 boundary-scan. You can
specify:
RunTest: Dot6ACInput | Dot6ACOutput |
Dot6DCInput | Dot6DCOutput | Dot6ACSelectCells |
Dot6DC00/01/10/11 | Dot6AC00/01/10/11;
All 1149.6 tests names start with Dot6. All tests that set the TAP instruction register to
EXTEST have the DC identifier, and all those loading the .6 EXTEST_PULSE or
EXTEST_TRAIN instructions have the AC identifier.
Tests Dot6ACInput, Dot6ACOutput, Dot6DCInput, Dot6DCOutput, and Dot6ACSelectCells
target structural manufacturing faults in the dot6 pads and boundary-scan hardware. They
assume that the tester is set to apply valid voltages to all D ot6 input pins, i.e. voltages outside of
the range between a logic 1 and a logic 0.
Tests Dot6DC00, Dot6DC01, Dot6DC10, and Dot6DC11 are designed to simplify measuring
AC and DC parameters on contacted Dot6 input pins, such as Vthreshold, Vhyst_level, or
Vhyst_edge. Some tests assume an invalid DC level is applied to the pin, forcing the 1149.6
interface boundary-scan cell to capture itself. All AC pad drivers are disabled. Dot6DC<i><c>
applies logic level <i> to the input pin and expects the cell to capture a <c>. For example,

September 2017
RunTest
• Dot6DC00—Pin logic level is 0, test receiver captures a zero.

• Dot6DC01—Pin state is zero DC, test receiver captures a one.
Parametric tests are used in conjunction with the Dot6 structural tests in order to fully cover all
aspects of the Dot6 test receivers. For details, refer to Application Note Support for 1149.6
Boundary Scan.
Default Value
A default value to this property does not exist. To run any test in the test bench generated by
ETVerify, you must specify the RunTest property and a value indicating the name of the test to
run. If you do not specify the RunTest property, ETVerify returns the following warning:
-- STEP <testStepName> -- No test was specified.
Usage Conditions
This property is used in the JtagVerify:TestStep wrapper.
• If you do not specify this property, the test bench does not include any tests.
• The generated test bench automatically executes a SETUP algorithm at the beginning of a
TestStep wrapper to assert compliance-enable pins. This algorithm indicates that all test
steps can assume that a boundary-scan chain is set to its safe value.
• To run multiple tests in the generated test bench, you must repeat the following syntax for
each test to run:
RunTest: <TestName>;
where TestName refers to one of the valid values listed in this section.
• You can run the tests defined by this property in one test step or across many test steps.
• When you specify both the CLAMP and OUTPUT tests, ETVerify combines these tests into
one test called OUTPUT_CLAMP.
• Each test in the test bench is run independently of any other tests. However, the default
configuration file runs the following tests in the order they are listed:
o TestLogicReset
o InstReg
o IDReg
o BypassReg
o BScanReg
o Input
o Sample
o HighZ
o Clamp

September 2017
RunTest
o Output
Example
The following syntax runs the TestLogicReset, BypassReg, and Sample tests in the generated
test bench.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
RunTest: TestLogicReset;
RunTest: BypassReg;
RunTest: Sample;
}
}
}
Related Information
TestStep -svfDir
JtagVerify
WTAPVerify Usage
The RunTest property enables you to specify the type of tests (algorithms) to run on specific
WTAP controller in the verification test bench that ETVerify creates. These algorithms enable
you to customize the generated patterns to reduce simulation time and ensure high
manufacturing test coverage.
Syntax
RunTest: TestLogicReset | InstReg |
BypassReg| IDReg;
• TestLogicReset — verifies that the WTAP is being reset properly. It consists of the
following three phases:
o Phase A — shifts a non-default instruction in the Instruction Register and resets the
WTAP forcing the JTAP to the state Test-Logic-reset
o Phase B — verifies if the IDCode Register is present in the WTAP, that it is the Data
Register selected after a reset
o Phase C — resets the WTAP and verifies the content of the Instruction Register
• InstReg — verifies the functionality of the Instruction Register of the WTAP. It consists of
the following three phases:
o Phase A — verifies that the captured values by the 2 lsb of the Instruction register
are “01”

September 2017
RunTest
o Phase B — verifies the functionality of the Shift Register inside the Instruction
Register
o Phase C — verifies the update flops inside the Instruction Register capturing their
values by de-asserting the Instruction Register enableStatus bit
• BypassReg — verifies the functionality of the Bypass Register of the WTAP controller. It
consists of the following two phases:
o Phase A — verifies that the captured values of the Bypass Register is “0”
o Phase B — verifies operations of the Bypass Register by scanning a 111000 pattern
through the Bypass Register and comparing with 011100
• IDReg — ensures that the ID register of the WTAP is responding properly and that it is
automatically selected after a reset of the WTAP. It consists of the following two phases:
o Phase A — verifies that the IDCode captured and shifted out by the WTAP
controller is the one specified in its BSDL description
o Phase B — verifies that the Shift Register inside the IDCode Register works
properly.
Default Value
A default value for this property does not exist. To run any test in the test bench generated by
ETVerify, you must specify the RunTest property and a value indicating the name of the test to
run. If you do not specify the RunTest property, ETVerify issues the following warning:
Warning [PPHW01]: No RunTest property specified for controller BP0 in the
test step Default.
Usage Conditions
This property is used in the WTAPVerify: Controller wrapper.
• If you do not specify this property, the test bench does not include any tests.
• To run multiple tests in the generated test bench, you must repeat the following syntax for
each test to run:
RunTest: <TestName>;
where testName refers to one of the valid values listed in this section.
• You can run the tests defined by this property in one test step or across several test steps.
• You cannot use the RunTest property when you set the runtime option -svf to On. If you do,
ETVerify terminates tests without generating SVF.
• The WTAPSettings wrapper on the controller being tested is ignored, and a warning is
issued:
Warning [PPHW01-01601262]: Ignoring UserIRBit(0)
setting applied on WTAP BP0 in TestStep(wtapTest1a)
because this WTAP controller is being tested in
this TestStep.

September 2017
RunTest
• Each test in the test bench is run independently of any other tests. However, the default
configuration file runs the following tests in the order they are listed:
o TestLogicReset
o InstReg
o IDReg
o BypassReg
• The test IDReg might only specified if the WTAP controller tested was created with an ID
register as specified in .etassemble (Refer to the DeviceIdCode property).
• BypassReg might only be specified if the WTAP controller tested was created with Bypass
register as specified in the .etassemble configuration file (Refer to the Bypass property).
Example
The following syntax runs the four tests in the generated test bench.
etv (MyDesignA) {
WTAPVerify (ETC) {
TestStep (0) {
Controller (BP0) {
RunTest: InstReg;
RunTest: BypassReg;
RunTest: IDReg;
}
}
}
}
The Verilog simulation trace resulting from this example would look like this:
70000 Pausing for 75000 ns, (750 clock cycles)
----- 5% -----
----- 10% -----
----- 15% -----
----- 20% -----
----- 25% -----
----- 30% -----
----- 35% -----
----- 40% -----
----- 45% -----
----- 50% -----
----- 55% -----
----- 60% -----
----- 65% -----
----- 71% -----
----- 76% -----
----- 81% -----
----- 86% -----
----- 91% -----
----- 96% -----
----- 100% -----
824000

September 2017
RunTest
824000 ******* TestStep Default *******

824000
824000
824000 ****************************************************************
824000 INSTREG Test on WTAP BP0
824000 ****************************************************************
824000 * Phase A : Testing the two LSB captured values (01) when
824000 accessing the WTAP instruction register
824000 * Loading TAP Instruction BP0_WIR_SEL to access the IR of WTAP BP0
849000 * Loading WTAP BP0 Instruction shift register with 000...000 (without
update)
849000 while expecting pattern XXX...XXX01 being shifted out.
884000 * Phase B : Testing the Instruction shift register functionality
update)
884000 while expecting pattern 000...000 being shifted out (without
capture).
update)
922000 while expecting pattern 000...001 being shifted out (without
capture).
960000 * Loading WTAP BP0 Instruction shift register with

000...[statusEnable=0]...000
960000 while expecting pattern 111...110 being shifted out.
1003000 * Phase C : Testing the instruction register latch . This is done by

capturing
1003000 the inverted values of the latch in the shift register by setting
the bit statusEnable
1003000 of the instruction register to 0 .
1003000 Loading WTAP BP0 Instruction register with

1003000 while expecting inverted previously updated pattern
111...[statusEnable=1]...1[01] being shifted out.
1043000 * Loading WTAP BP0 Instruction register with

1043000 while expecting inverted previously updated pattern
000...[statusEnable=1]...0[01] being shifted out.
1084000
1084000 End of the WTAP INSTREG Test
1084000 ****************************************************************
1084000 BYPASSREG Test on WTAP BP0
1084000 ****************************************************************
1084000 * Phase A : Testing 0 captured by the BYPASS register.
1108000 * Loading WTAP BP0 Instruction BYPASS
1149000 * Loading TAP Instruction BP0_WDR_SEL to access DR of WTAP BP0
1173000 * Shifting a bit logic 1 data into the BYPASS register

1173000 while expecting a bit logic 0 data being shifted out.
1180000 * Phase B : Testing the BYPASS shift register functionality
1180000 * Shifting the pattern 11100 into the BYPASS register

1180000 while expecting pattern 01110 being shifted out.

September 2017
RunTest
1207000
1207000 End of the WTAP BYPASSREG Test
1207000 ****************************************************************
1207000 IDREG Test on WTAP BP0
1207000 ****************************************************************
1207000 * Phase A : Testing captured IDCode value
1231000 * Loading WTAP BP0 Instruction IDCODE
1297000 * Shifting 000...001 into the IDCODE register and

1297000 expecting the ID Code 00010101010000110010000011101101 being scanned
out.
1329000 * Phase B : Testing the IDCode shift register functionality

1332000 expecting 000...001 data being scanned out (without capture).

1367000 expecting 111...110 data being scanned out (without capture).
1405000
1405000 End of the WTAP IDREG Test
1405000 ****************************************************************
1405000 TESTLOGICRESET Test on WTAP BP0
1405000 ****************************************************************
1405000 * Phase A : Loading WTAP BP0 Instruction register with
1405000 a non-reset instruction ( WBP0_SHORT_SETUP) and resetting
the TAP and WTAPs
1430000 * Loading WTAP BP0 Instruction WBP0_SHORT_SETUP
1466000 * Resetting the TAP and WTAPs with the signal TRST
1473000 * Phase B : Testing that the proper data register (IDCODE) is selected
and functional after a WTAP reset

1473000 assuming that the data register IDCODE is selected by default after
a Reset

1497000 expecting the ID Code 00010101010000110010000011101101 being
scanned out.
1531000 * Phase C : Resetting the TAP and WTAPs and testing the WTAP
1531000 instruction latch content after a WTAP reset
1531000 * Resetting the TAP and WTAPs with the signal TRST
1562000 * Shifting Instruction register and expecting inverted default

1562000 Instruction after a reset 111...[statusEnable=1]...1[01] being
shifted out .
1599000
1599000 End of the WTAP TESTLOGICRESET Test

September 2017
RunTest
Related Information
Controller -svf
WTAPVerify Bypass in the manual ETAssemble Tool
Reference
WTAPSettings DeviceIdCode in the manual ETAssemble
Tool Reference

September 2017
RunTimeRefreshEnable
The RunTimeRefreshEnable property enables you to specify if AutoRefresh operations are to
be automatically performed on a DRAM during the execution of the algorithm. The default
duration between AutoRefresh operations is determined when the controller is generated. You
can override the default duration by setting RunMode to RunTimeProg and specifying the
RunTimeRefreshInterval property.
Syntax
RunTimeRefreshEnable: On | (Off);

• On — specifies that AutoRefresh operations are to be automatically performed during the
execution of the algorithm.
• Off — specifies that AutoRefresh operations are not to be performed automatically during
the execution of the algorithm.
Default Value
Usage Conditions
• The memory library file property RetentionTimeMax determines the default refresh
interval.
• When this property is set to On and RunMode is set to HWDefault, the default refresh
interval will be used.
• When this property is set to On and RunMode is set to RunTimeProg, you can override the
default refresh interval using the RunTimeRefreshInterval property.
Example
This example specifies that AutoRefresh operations are to be performed by the programmable
memory BIST controller during execution of the algorithm.
TestStep (4) {
RunTimeRefreshEnable: On;

September 2017
Related Information
MembistPVerify RetentionTimeMax in the manual
ETAssemble Tool Reference
RunMode RunTimeRefreshInterval

September 2017
RunTimeRefreshInterval
The RunTimeRefreshInterval property enables you to specify the refresh interval that
overrides the default value determined by the RetentionTimeMax property of the memory
library file. The RunTimeRefreshInterval value is scanned into the programmable memory
BIST controller and is used for counting the time between two consecutive AutoRefresh
operations applied to a DRAM during test.
Syntax
RunTimeRefreshInterval: time[s | ms | us | (ns) | ps];
where time is a real number. Valid values for specifying the units for time are as follows:
• s — specifies the refresh interval in seconds.
• ms — specifies the refresh interval in milliseconds.
• us — specifies the refresh interval in microseconds.
• ns — specifies the refresh interval in nanoseconds.
• ps — specifies the refresh interval in picoseconds.
Default Value
If this property value is not specified, it defaults to the lowest value of all RetentionTimeMax
properties in the memory library files divided by the maximum number of memory rows.
Usage Conditions
• RunTimeRefreshEnable must be set to On.
• RunMode must be set to RunTimeProg; otherwise, this property is ignored.
• The specified value of RunTimeRefreshInterval must be greater than zero.
• Note that consecutive AutoRefresh operations cannot be applied one after another; they must
alternate with at least one non-AutoRefresh operation. Therefore, if the specified value of
RunTimeRefreshInterval is shorter than the total duration of the AutoRefresh operation and
the longest non-AutoRefresh operation of a particular operation set, then applying the
AutoRefresh every second operation may take more time than specified with the property
and violate the memory retention time.
• The delay counter is used to load the requested refresh interval and cannot be used in the
algorithm. Given the MembistPVerify:ClockPeriod, the specified value must, therefore, fit
the size of the delay counter, which is automatically verified during the test bench
generation.

September 2017
Example
This example specifies an elapsed time of 250 milliseconds between two successive
AutoRefresh operations during execution of the algorithm.
TestStep (4) {
RunTimeRefreshEnable: On;
RunTimeRefreshInterval: 250ms;
Related Information
MembistPVerify RetentionTimeMax in the manual ETAssemble
Tool Reference
RunMode RunTimeRefreshInterval in the manual

September 2017
SanityCheck
SanityCheck
The SanityCheck property allows the execution of a functional loopback test with many
channels running in parallel and only checking which of the selected channels have failed the
test.
Syntax
SanityCheck: (On) | Off;
Default Value
The default is On.
Usage Conditions
This property is used only in the TestStep wrapper of the SerdesVerify wrapper.
• At least one pair of channel (lane) must be selected using the TPGChannelEnable and
RPAChannelEnable properties and the test will be performed in parallel on all the selected
channels. There is a pass/fail bit for each selected channel (GO bit).
• This property is meaningful only when the SerdesTest property is set to
FunctionalLoopback, and the selected Pattern is PRBS.
• The test duration is set using the LoopbackDurationInWordClockCycles property.
• When the InjectErrors property is set to Off, the test will pass on a channel only if the
following conditions are met and will fail otherwise:
o The RPA (Received Pattern Analyzer) associated with the receiver could seed itself
correctly to the transmitted pseudo-random data.
o All pseudo-random data was received correctly.
• When the InjectErrors property is set to On, the test will pass on a channel only if the
following conditions are met and will fail otherwise:
o The RPA (Received Pattern Analyzer) associated with the receiver could seed itself
correctly to the transmitted
pseudo-random data.
o At least one error was detected in the received pseudo-random data.
• The test sequence is as follows:
o All selected TPGs (Transmit Pattern Generator) are started.
o A lock time is elapsed, as set by the LockTimePause property.
o All selected RPAs (Received Pattern Analyzer) are started in seed mode.

September 2017
SanityCheck
o Once two consecutive words match those of the PRBS sequence, the GO bit for that
receiver is set, and the RPA switches in error detection mode.
o As the duration set by the LoopbackDurationInWordClockCycles property is
elapsed by the tester, each word received is compared against the expected word in
the PRBS sequence and the GO bit is reset if an error is detected in the word.
o Finally, at the end of the test, the GO bits are checked against the expected value and
a compare failure is generated. The expected value is one when the InjectErrors
property is set to Off and zero when set to On.
Example
The following will perform a sanity type of FunctionalLoopback test on channels 0 and 1
without injecting errors.
etv (MyChip) {
SerdesVerify (QuickBERT) {
SerdesTest: FunctionalLoopback;
SanityCheck: On;
InjectErrors: Off;
LockTimePause: 10us;
Pattern: PRBS;
Controller (BP1) {
//...
//...
}
}
}
}
Related Information
InjectErrors SerdesVerify
LockTimePause SerdesTest
LoopbackDurationInWordClockCycles TestStep
Pattern TPGChannelEnable
RPAChannelEnable

September 2017
ScanVerify
ScanVerify
The ScanVerify wrapper enables you to generate a test bench or manufacturing test data file
that exercises the scan operation. The vectors are applied to the scan chains and the results are
captured and compared with the expected data.
The ScanVerify wrapper enables you to tailor the generated test bench or manufacturing test
data file for any of the following:
• ELT core modules
• Scan-inserted Block modules
• Chip-level design
Syntax
For the complete syntax of the wrapper, refer to the Scan Verification Section.

September 2017
SdfAnnotate
SdfAnnotate
The SdfAnnotate property allows you to enable SDF back annotation for specific patterns.
Syntax
Default Value
Usage Conditions
This property is used in the following Specific Verification Sections of the ETVerify
configuration file:
• CustomVerify
• FastScanVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• ScanVerify
• SerdesVerify
• JtagVerify
• WTAPVerify
In case of SDF back annotation using a full chip SDF file (pre- or post-layout), the SdfFiles
wrapper is located outside of all specific xxxVerify wrapper at the top of the etVerify
configuration file. In this case, it is assumed that the scope of the back annotation file content is
the full chip.
To enable SDF back annotation for a specific pattern, set the SdfAnnotate property to On in the
top portion of a xxxVerify wrapper.
Related Information
SdfFiles Summary of Specific Verification Sections

September 2017
SdfFiles
SdfFiles
The SdfFiles wrapper comprises one or more SDF (Standard Delay Format) files to be loaded
sequentially before effectively starting simulation. SDF files are typically extracted from
designs at pre- or post-layout stage by synthesis, P&R, or specialized extraction tools. Running
simulations with these annotation files makes results more accurate as delay extracted from the
design are taken into account. Note that simulations are generally much longer to run when SDF
files are loaded.
As a result of executing etVerify with the configuration file that includes SDF files specified
using the SdfFiles wrapper’s syntax, the following files are generated:
• _sim.script — A simulation script that can enable SDF back annotation for this controller.
• .sdf_annotate — A Verilog source file that is capable of loading the files listed in the above
SdfFiles sub-wrapper. To load these files, you have to define the LVS_SDF_ANNOTATE
parameter on the command line that invokes the Verilog simulator.
Figure A-17 displays the contents of the sample TOP.sdf_annotate Verilog source file.
Figure A-17. Contents of TOP.sdf_annotate File
module TOP_sdf_annotate;
ìfdef LVS_SDF_ANNOTATE
initial begin
ìfdef logicbistv_TOP
$sdf_annotate("../ETAssemble/outDir/ ...
DPLL_LVISION_LOGICTEST.sdf",TB.CHIP.PLL);
$sdf_annotate("../ETAssemble/outDir/ ...
DPLL_LVISION_LOGICTEST.sdf.extra",TB.CHIP.PLL);
èndif
end
èndif
endmodule
You have to define the LVS_SDF_ANNOTATE symbol that will enable the back annotation.
This is done by adding +define+LVS_SDF_ANNOTATE on the command line that invokes
the Verilog simulator. In the above code, the TOP_sim.script is instructed of which pattern is
simulated, and will automatically define the pattern-related logicbistv_TOP symbol when
invoking the Verilog simulator. Note that the LVS_SDF_ANNOTATE symbol is automatically
defined in the simulation targets of the LV Flow environment.
In cases where many controllers are instrumented with the SdfFiles wrapper, the above
TOP.sdf_annotate source file will simply add the ifdef and endif sections required for
each pattern.
Note the following in the TOP.sdf_annotate file:
• The order of the $sdf_annotate lines is the same as in the SdfFiles wrapper of the etVerify
configuration file.
• The full hierarchical path to the controller in the chip is included as part of the $sdf_annotate
statement. This hierarchy can change in case the UseAsyncClocks property is set to Off, and

September 2017
SdfFiles
a DUT card source file is required for the simulation of this specific pattern. This is
automatically taken care of by etVerify during the generation of these simulation objects.
Note that does not apply to the ULTRA controller.
• The generated simulation script includes the REQUIRED symbol definition when calling
simScript for each module, such as +define+logicbistv_TOP for logic BIST simulation.
• The simulation script is also included as part of the objects being loaded into memory during
simulation. The symbol +define+LVS_SDF_ANNOTATE needs to be defined for ANY
back annotation to occur.
Syntax
SdfFiles {
<sdfFileName>;// Repeatable
}
Default Value
None
Usage Conditions
This property is used in all Specific Verification Sections (Refer for details to Summary of
Specific Verification Sections) and the Global Section of the ETVerify configuration file.
• In case of SDF back annotation using a full chip SDF file (pre- or post-layout), the SdfFiles
wrapper is located in the Global Section at the top of the ETVerify configuration file. In this
case, it is assumed that the scope of the back annotation file content is the full chip.
• However, it is possible to enable SDF back annotation only for the specific patterns by
setting the SdfAnnotate property to On in the top portion of any specific xxxVerify wrapper.
Example
Figure A-18 provides an example ETVerify configuration file—TOP.etSignOff.
Figure A-18. Example etVerify Configuration File
etv (TOP){
SdfFiles{
../CHIP/GATE/CHIP.sdf;
../CHIP.sdf.extra;
}
//...

September 2017
SdfFiles
MembistVerify (TOP_P1){
PatternName: membistv_P1_TOP;
SdfAnnotate: Off;
//...
}
//...
SerdesVerify (TOP_P2){
PatternName: ultrav_P2_TOP;
SdfAnnotate: On;
}
}
In Figure A-18, a couple of full-chip SDF back annotation files are listed in the SdfFiles
wrapper that resides outside of all xxxVerify wrappers. For these SdfFiles to work properly, the
delays they contain must be generated for the whole chip. This means that the reference to the
components to which these delays apply must be specified from the top of the chip.
This configuration file instructs etVerify to generate a TOP.sdf_annotate Verilog script. Given
that as single simulation script is generated, TOP_sim.script, it is the one that is going to be
instrumented for back annotation.
However, since only the SerdesVerify wrapper has the SdfAnnotate property set to On (default
value is Off), the TOP.sdf_annotate file only includes the required ifdef and endif sections for
enabling back annotation for the ultrav_P2_TOP pattern.
Related Information
Controller Global Section
SdfAnnotate Summary of Specific Verification Sections
TestStep UseAsyncClocks

September 2017
The SelectLibraryAlgorithm property enables you to select a custom algorithm defined in the
Tessent MemoryBIST Algorithm file, or an algorithm from Mentor Graphics library of
algorithms, even though the algorithms were not hard-coded into the controller at generation
time.
Syntax
SelectLibraryAlgorithm: <algorithmName>;
where algorithmName must match an algorithm name specified in the Tessent MemoryBIST
Algorithm file or one of the Mentor Graphics library algorithms.
Default Value
None
Usage Conditions
• This property cannot be specified if HardCodedAlgorithm property is present.
• The ETPlanner property BitSliceWidth must be set to 1 for the selected BIST step.
• The selected algorithm must have the number of instructions less than or equal to the value
defined in the NumberofInstructions property in the ETPlanner configuration file.
Example
This example specifies the custom algorithm SMarchX will be scanned into the controller and
executed in TestStep(4).
MembistpVerify (MyDesign) {
TestStep (4) {
Controller (BP1) {
SelectLibraryAlgorithm: SMarchX;
} //end of MembistpVerify wrapper
Related Information
Controller TestStep
HardCodedAlgorithm Tessent MemoryBIST Algorithm File
BitSliceWidth in the manual ETPlanner Tool
Reference

September 2017
MembistPVerify NumberofInstructions in the manual

RunMode

September 2017
SerdesVerify
SerdesVerify
The SerdesVerify wrapper introduces wrappers and properties for setting the SerDes test
controller properties, test algorithms, and test steps. The controller itself is named the ULTRA
controller, which stands for UnLimited Time Resolution Analysis. This controller implements
general algorithms to measure and diagnose jitter and timing problems in SerDes and other
mixed-signal components. For each test sequence, you create one or more TestStep wrappers in
the SerdesVerify wrapper of an ETVerify configuration file. In each TestStep wrapper, you
specify properties that apply the test to the targeted ULTRA controller(s). The test conditions
you want ETVerify to apply to each controller are specified in separate Controller wrappers.
Syntax
For the complete syntax for the wrapper, refer to the SerdesTest Verification Section.
Example
Figure A-19 provides a sample of the SerdesVerify wrapper.

September 2017
SerdesVerify
Figure A-19. Sample SerdesVerify Wrapper
etv (myDesign) {
SerdesVerify (myTestSequence) {
PatternName: ultrav_P2_I0_CH0_EST_SERDES;
SimulationScript: EST_sim.script;
TCKPeriod: 100.0ns;
UseAsyncClocks: On;
ForceDisable: Off;
DefineClock(P): TXBCLK;
DefineClock(P): RXBCLK;
ClockPeriods {
TXBCLK: 6.43;
RXBCLK: 25.729545;
}
UseDutLoopBacks: On;
DUTLoopBacks {
RXSD[0] <= TXSD[0];
}
TestStep (LoopBack) {
Pattern: PLFSR10;
Controller (BP0) {
}
}
TestStep (RmsJitter) {
Pattern: P0101;
Controller (BP0) {
TestDurationInBeatCycles: 2;
ChannelSelect: 0;
}
}
}
}

September 2017
SerdesTest
SerdesTest
The SerdesTest property specifies which specific test to perform on the SerDes.
Syntax
SerdesTest: <serdesTestName>;
where valid values for <serdesTestName> are as follows:

• AverageSlewRate — This test measures the average slew rate of the serialized data by
transmitting a 50% duty cycle pattern (P1010), with the tester forcing a current at the input
of the receiver, and measuring the duty cycle seen by the receiver.
• AverageVoltage — This test instructs the Serializer (transmitter) to serially transmit a
selected waveform which allows an appropriate test program on a tester to measure the
average voltage on each leg of the transmitter using a PMU.
• BasicTests — This test verifies correct access to the ULTRA controller main setup register.
• DutyCycleDistortion — This test measures the error on the duty cycle on the data received
by the Deserializer (receiver). The error is always relative to an ideal value of 50%.
• FunctionalLoopback — For this test, a pseudo-random binary sequence (PRBS, standard 7-
bit polynomial) is transmitted for a set duration and it is verified that the data is received
without errors. The test can also be used to measure the BER (Bit error rate), one channel at
a time.
• JitterFromCDF — This characterization-only-test accumulates an on-chip CDF
(Cumulative Distribution Function) of the jitter seen by the deserializer (receiver). From this
data, the RMS jitter can be estimated from the CDF data and a PDF (Probability
Distribution Function) of the jitter produced.
• Jitter — This test measures the jitter in the received data totally on-chip, using a technique
that accumulates the measurement
on-the-fly.
• LFJitterFromCDF — This characterization-only-test accumulates an on-chip CDF
(Cumulative Distribution Function) of the low frequency jitter seen by the deserializer
(receiver). From this data, the RMS jitter can be estimated from the CDF data and a PDF
(Probability Distribution Function) of the jitter produced. This test requires the transmitter
and receiver clock to be phase-locked to each other.
• MeanSamplingInstant — This test measures the mean sampling instant, within the bit
duration, of the deserializer (receiver).
• MultiPhaseSamplingError — This test measures the bit-to-bit duration, thus, allowing the
estimation of the multi-phase sampling error of the deserializer (receiver).
• OffsetFrequency — This test measures the offset frequency between the serializer and the
deserializer, as required by most of the Tessent SerdesTest tests. When in characterization
mode, the sign of the frequency offset is also reported.
• TransistionDensityDependentDelay — This test measures the difference in delay from a
reference of the sampling instant of the data, while varying the density of transitions in the

September 2017
SerdesTest
received data. This test can be repeated over the range of adjustment of the equalization in
the receiver, thus allowing for quick determination of the optimal settings.
Default Value
The default is Jitter.
Usage Conditions
This property is only used in the TestStep wrapper of the SerdesVerify wrapper.
Example
The following will measure Jitter.
etv (MyChip) {
SerdesVerify (Tests) {
TestStep (OnChipJitter) {
SerdesTest: Jitter;
Controller (BP1) {
//...
}
}
}
}
Related Information

September 2017
SetBisrChain
SetBisrChain
The SetBisrChain property is used to specify values that are to be scanned into the BISR chain.
This property is used in conjunction with RunMode: BisrChainAccess. For memories with a
serial BISR interface, both the internal and external registers will be set to the same value.
Syntax
SetBisrChain (<int>): 1 | (0);
where int specifies the index of a BISR register index to set.

Default Value
The default is 0.
Usage Conditions
This property is used in the TestStep: Controller wrapper of the following verification wrappers
of the .etEarlyVer, .etSignOff, and .etManufacturing files:
• MembistPVerify
• MembistVerify
When using this property, BisrChainRotate must be set to Off.
Example
This example demonstrates how to set the BISR[1] and BISR[40] registers to 1. The value 0
will be scanned in all other BISR registers.
TestStep (Step0) {
BisrChainRotate: Off;
EnableBiraCapture: Off;
SetBisrChain(1): 1;
SetBisrChain(40): 1;
}
}
}
Related Information
Controller TestStep

September 2017
SetBisrChainExpected
SetBisrChainExpected
The SetBisrChainExpected property is used to set an expected value on specific timeslot when
scanning out the BISR chain content. When not specified, BISR chain timeslots are compared
against 0, so you only need to specify the timeslots you want compared against 1. This property
is only used for verification and serves no purpose in the manufacturing flow.
Syntax
SetBisrChainExpected(<timeSlot>): 1;
where timeslot is the position of the BISR register you want to compare to 1. The timeslot
closest to tdo is timeslot 0. You can use the <designName>_LVISION_BISR_.map file found
within the LVDB to check the position of any BISR register.
Default Value
None
Usage Conditions
wrappers:
• MembistPVerify
• MembistVerify
This property is ignored when you specify EnableBiraCapture to Off.
Example
This example demonstrates how to set an expected compare value of 1 on the BISR[1] and
BISR[4] registers to 1. The value 0 will be compared for all other BISR registers.
TestStep (Step0) {
SetBisrChainExpected(1): 1;
SetBisrChainExpected(4): 1;
}
}
}
Related Information
EnableBiraCapture TestStep
MembistPVerify

September 2017
SetupChainRegister
SetupChainRegister
The SetupChainRegister property enables you to specify which HSDL register of the
controller is going to be tested with a walking 0 pattern. The setupChain test sequence applies
sequentially all one patterns, then a “011111...1” pattern through the register chain input, and
compares the register chain output with the same.
Syntax
where registerName is a valid HSDL register name for the specified controller as listed under
“attribute register_access” in the hsdl file.
Default Value
None
Usage Conditions
The SetupChainRegister property is used in the TestStep: Controller wrappers of the
following major wrappers:
• LogicbistVerify
• MembistPVerify
• MembistVerify
• SerdesVerify
• JtagVerify
• WTAPVerify
When the SetupChainRegister property is present, the only test performed is the setupChain
test on the specified register, and any other property related to the normal operation of the
embedded test controller is irrelevant.
Example 1
The following example specifies to perform a setupChain test on the registers
SHORT_SETUP_REG of the memory BIST controller connected to the WTAP BIST port
WBP0 which is connected on the TAP port BP1.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
SetupChainRegister: SHORT_SETUP_REG;
}
}
}
}

September 2017
SetupChainRegister
Example 2
The following example specifies to perform a flush test on the registers LONG_SETUP_REG of
the top-level logic BIST controller which is connected on the TAP port BP0.
etv (MyDesignA) {
LogicBistVerify (1) {
TestStep (0) {
Controller (BP0) {
SetupChainRegister: LONG_SETUP_REG;
}
}
}
}
Related Information

September 2017
SetupRate
SetupRate
The SetupRate property is used when the embedded test controller is accessed through a Direct
Pin interface rather than a TAP. This property enables you to specify whether the scan shifting
is to be done at the TCK or system clock frequency.
Syntax

• SysClock — indicates that scanning is to be performed with the system clock.
• TCK — indicates that scanning is to be performed with TCK.
Default Value
The default value is TCK.
Usage Conditions
The following conditions apply:
Table A-11. SetupRate Usage Conditions

Usage Conditions Memory Logic BIST
BIST Verification
Verification Section *
Section
Scan
Verification
Section
This property is meaningful only when the embedded test ✓ ✓

controller is accessed through a Direct Pin interface and not
the IEEE 1149.1 TAP.
SetupRate must be set to TCK when UseAsyncClocks is set to ✓ ✓
On, because the memory controller runs off a clock that is
asynchronous to TCK. Because scan shifting cannot be
performed asynchronously, it must be performed with TCK.
This property is only applicable for pre-5.0 logic BIST controllers.

Example
This example specifies that scanning is performed with the system clock.

September 2017
SetupRate
etv (MyDesignA) {
SetupRate: SysClock;
}
}
Related Information
ClockPeriod MembistVerify
UseAsyncClocks ScanVerify
LogicbistVerify TCKRatio
MembistPVerify

September 2017
ShiftClkSelect
ShiftClkSelect
The ShiftClkSelect property enables you to specify the shift clock source to be used when the
logicTest controller is running. The clock sourcing ShiftClkSrc1 and ShiftClkSrc2 are either
automatically selected by ETPlanner based on the ShiftClockFrequency property or selected by
you by means of the ShiftClockSource1 and ShiftClockSource2 properties in the .etplan file.
When a shift clock source frequency is specified with the ShiftClkSelect property, this
frequency is compared to the default shift clock source frequency. If the specified frequency is
greater than the default (+ 0.5% margin), then a precautionary warning is ssued.
Syntax
shiftClkSrc1/16 | shiftClkSrc2 |shiftClkSrc2/2 |
shiftClkSrc2/4 | shiftClkSrc2/8 |shiftClkSrc2/16;

• TCK — indicates that the shift clock will be TCK.
• ShiftClkSrc1 — indicates that the shift clock comes from the clock specified in the .etplan
file with the ShiftClockSource1 property.
• ShiftClkSrc1/2 — indicates that the shift clock comes from the clock specified in the .etplan
file with theShiftClockSource1 property with a period of 1/2.
file with the ShiftClockSource1 property with a period of 1/4.
• ShiftClkSrc1/16 — indicates that the shift clock comes from the clock specified in the
.etplan file with the ShiftClockSource1 property with a period of 1/16.
• ShiftClkSrc2 — indicates that the shift clock comes from the clock specified in the .etplan
file with the ShiftClockSource2 property.
• ShiftClkSrc2/16 — indicates that the shift clock comes from the clock specified in the
.etplan file with the ShiftClockSource2 property with a period of 1/16.
Default Value
The default is TCK.

September 2017
ShiftClkSelect
Usage Conditions
This property is used in the following LogicbistVerify wrappers:
• LogicbistVerify
• This property cannot be specified when RunMode of the LogicbistVerify is set to
HWDefault.
• This property must be set to TCK when ParallelLoad is set to Yes.
Example
This example specifies that the shift clock source 2 will be selected with a frequency of 1/16.
etv (MyDesignA) {
ShiftClkSelect: ShiftClkSrc2/16;
TestStep (1) {
}
}
}
}
Related Information
Controller ShiftClockSource1 in the manual ETPlanner
Tool Reference
LogicbistVerify ShiftClockSource2 in the manual ETPlanner
Tool Reference
ParallelLoad ShiftClockFrequency in the manual
RunMode TestStep

September 2017
ShiftClockController
The ShiftClockController wrapper groups the properties that enable you to specify how the
Shift Clock sources belonging to a Shift Clock controller will be affected when the associated
UserDefinedSequence is used within a ScanVerify or LogicbistVerify wrapper.
Syntax
ShiftClockSource(1 | 2) {
Pin: <string>;
PinInv: <string>;
}//End of ShifttClockSource wrapper
}//End of ShifttClockController wrapper
Default Value
None
Usage Conditions
wrapper.
• This wrapper can only be used with a physical region that has been generated with Version
7.0 or newer.
Example
The following example shows that the shift clock source 1 of the Shift Clock controller in the
sub-physical region subCore will be driven by the port clk2 on subCore which is in turn driven
by the top-level pin clk[0].
ShiftClockController {
ShiftClockSource (1) {
ClockInput: clk2;
}
ClockInput (clk2) {
Pin: clk[0];
}

September 2017
}
}
...
}
Related Information
ClockInput Pin
LogicbistVerify ShiftClockSource
PhysicalRegion UserDefinedSequence

September 2017
ShiftClockSource
ShiftClockSource
The ShiftClockSource wrapper allows you to identify which shift clock source on the Shift
Clock controller will be affected when UserDefinedSequence is used in the ScanVerify or
LogicbistVerify wrappers.
Syntax
ShiftClockSource (1 | 2) {
Pin: <string>;
PinInv: <string>;
}//End of ShifttClockSource wrapper
}//End of ShifttClockController wrapper
where legal values are 1 or 2 and can be specified as a comma-separated list.

Default Value
None
Usage Conditions
This wrapper is used in the UserDefinedSequence: ClockSourceOverride: PhysicalRegion:
ShiftClockController wrapper.
Example
The following example shows that the shift clock source 1 of the Shift Clock controller in the
sub-physical region subCore will be driven by the port clk2 on subCore which is in turn driven
by the top-level pin clk[0].
ShiftClockController {
ShiftClockSource (1) {
ClockInput: clk2;
}
ClockInput (clk2) {
Pin: clk[0];
}
}
}
...
}

September 2017
ShiftClockSource
ShiftClockSource wrappers.
----------------------------------------
SCC Source ClockInput on Physical Region FreqRatioRelToSource
---------------------------------------------------------------------
-
1 clk2 1.0

----------------------------------------------------------------
clk2 clk[0] 1.0
Related Information
ClockInput Pin
LogicbistVerify ShiftClockController
PhysicalRegion UserDefinedSequence

September 2017
SignalToMeasure
SignalToMeasure
The SignalToMeasure property selects on which specific signal to select when measuring jitter.
Syntax
SingnalToMeasure: (Databit) | RecoveredClock | TransmitterClock;
Default Value
The default value is Databit.
Usage Conditions
• This property is considered only for the jitter tests selected by the SerdesTest property are as
follows: Jitter, JitterFromCDF, LFJitterFromCDF.
• When the default value of Databit is selected, the particular bit in the received data word is
selected by the DataBitNo property.
Example
The following will perform a Jitter1 test for controller BP1, but on the transmitter clock.
etv (MyChip) {
SerdesVerify (OnChipJitter) {
TestStep (Jitter1) {
SerdesTest: Jitter;
Controller (BP1) {
//...
SignalToMeasure: TransmitterClock;
LowerLimit: 0.0;
UpperLimit: 2.0;
}
}
}
}
}
Related Information
DataBitNo TestStep
SerdesVerify

September 2017
SimulationModel
SimulationModel
The SimulationModel wrapper enables you to specify properties for the current leakage
simulation model of pads. You use this wrapper when either the LeakageNC or
TriStateEnableNC value is specified for the RunTest property, which is located in the TestStep
wrapper.
When either the LeakageNC or TriStateEnableNC test is specified in the RunTest property in
the TestStep wrapper, the HDL generated simulation test bench automatically includes a model
for current leakage of the pads. This model is used for every pad that might be tested during the
LeakageNC and TriStateEnableNC tests, such as for any pad that is both bidirectional and
symmetrical. The models are instantiated over the DUT pins within an HDL DUT card.
The current leakage model behavior of the pad consists of holding the last value driven by the
pad when it is tri-stated and then toggling the value after the decay time assigned to the pad
elapsed.
By default, all pads are assigned an infinite decay time that model an ideal pad with no leakage
current. You can change this default globally for all pads, and you can also assign a specific
decay time for any pad using the syntax of the SimulationModel wrapper. For detailed
information on how to calculate decay time, refer to the Application Note “MPC Testing of I/O
Pin Leakage”.
Syntax
SimulationModel {
GlobalPadDecayTime: <n>(ns) | us | ps;
PadDecayTime {
<PinName>: <n>(ns) | us | ps;
}
}
Default Value
None
Usage Conditions
Example
This example specifies a default decay time of 1us and a pad decay time of 2.5us for particular
pads.

September 2017
SimulationModel
etv (MyDesignA)
JtagVerify (ETC) {
SimulationModel {
PadDecayTime {
D1(0): 2.5us;
D1(1): 2.5us;
D1(2): 2.5us;
D1(3): 2.5us;
D1(4): 2.5us;
D1(5): 2.5us;
D1(6): 2.5us;
D1(7): 2.5us;
D1(8): 2.5us;
}
}
TestStep (1) {
}
}
}
Related Information
GlobalPadDecayTime TestStep
LeakageNCOptions RunTest

September 2017
SimulationScript
SimulationScript
The SimulationScript property enables you to specify the name of the script that ETVerify
generates for making it easier to manage and run simulations.
Syntax
where fileName is any valid file name.

Default Value
The default name is <designName>_sim.script.
Usage Conditions
This property is used in the following types of verification:
• CPUVerify
• CustomVerify
• FastScanVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• ScanVerify
• SerdesVerify
The script is only generated when -verilog On is specified on the command line.
Example
This example specifies that during ETVerify run on the top the following script is generated—
Custom1_sim.script.
etv (MyDesignA) {
CustomVerify (Custom1) {
SimulationScript: Custom1_sim.script;
}
}
Related Information
CPUVerify LogicbistVerify
CustomVerify MembistVerify
FastScanVerify ScanVerify

September 2017
SimulationScript
MembistPVerify -verilog

September 2017
SimulationTimePrecision
SimulationTimePrecision
The SimulationTimePrecision property enables you to specify the `timescale precision in the
Verilog testbench.
Syntax
SimulationTimePrecision: 1s | 10s | 100s | 1ms | 10ms | 100ms | 1us | 10us | 100us | 1ns | 10ns
| 100ns | 1ps | (10ps) | 100ps | 1fs | 10fs | 100fs;
Default Value
The default value is 10ps.
Usage Conditions
The timescale in the generated testbench with the specified value for SimulationTimePrecision
and SimulationTimeUnit is as follows:
`timescale <SimulationTimeUnit>/<SimulationTimePrecision>

September 2017
SimulationTimeUnit
SimulationTimeUnit
The SimulationTimeUnit property enables you to specify the `timescale time unit in the
Verilog testbench.
Syntax
SimulationTimeUnit: 1s | 10s | 100s | 1ms | 10ms | 100ms | 1us | 10us | 100us | 1ns | 10ns |
100ns | 1ps | 10ps | (100ps) | 1fs | 10fs | 100fs;
Default Value
The default value is 100ps.
Usage Conditions
The timescale in the generated testbench with the specified value for SimulationTimePrecision
and SimulationTimeUnit is as follows:
`timescale <SimulationTimeUnit>/<SimulationTimePrecision>

September 2017
SpareElementPriority
The SpareElementPriority property specifies the type of spare element to be allocated first
upon failure. This property is used only for memories with redundant row and column elements.
To find a repair solution for a faulty memory initially declared as unrepairable, change the
repair strategy by specifying a different SpareElementPriority setting.
Syntax
SpareElementPriority: (Column) | Row;
When SpareElementPriority: Column is specified, all single-bit errors are repaired by

redundant column or IO elements; multi-bit errors are automatically repaired by spare row
elements. If the number of faults exceeds the number of redundant column or IO elements, the
remaining redundant row elements are allocated for these faults. This is the most flexible
solution because it automatically allocates redundant row elements for multi-bit failures while
allocating redundant column or IO elements for single-bit failures.
When SpareElementPriority: Row is specified, redundant rows are allocated for all errors
(single-bit and multi-bit errors). The redundant column/IO elements are allocated only for the
remaining faults that occurred after all the redundant rows were allocated.
A redundant column or IO element cannot repair a multi-bit failure. If only a redundant column
or IO element is available when a multi-bit error is detected, the repair status will be
unrepairable.
Default Value
The default is Column.
Usage Conditions
wrappers of the .etEarlyVer, .etSignOff, and .etManufacturing files:
• MembistPVerify
• MembistVerify
When you set the SpareElementPriority property to Row, the value you specify for RunMode
must be RunTimeProg.
Example
This example instructs the repair analysis engine to allocate redundant rows before redundant
column/IO elements.
TestStep (0) {
Controller (BP1) {
SpareElementPriority: Row;

September 2017
}
}
}
Related Information
Controller TestStep

September 2017
SlowedDownBurstCycles
The SlowedDownBurstCycles property enables you to specify how many burst cycles should
be slowed down during the burst phase. Use this property in conjunction with
EffectiveSlowedDownFrequency to create runtime adjustable Burst Clock waveforms.
Syntax
Default Value
The default is 0.
Usage Conditions
This property can be used directly in LogicbistVerify or ScanVerify, or in
BurstClockController.
• If you globally define this property in the LogicbistVerify or ScanVerify wrapper, ETVerify
automatically adjusts the value for each burst clock controller should the specified value
exceed the controllers maximum allowed value, i.e. BurstLength-2.
• The value specified for this property in a BurstClockController wrapper must be less than or
equal to the controllers BurstLength-2. For example, if a burst clock controller was
generated with a burst length of 4 you would only be allowed to specify a value of 2 for
SlowedDownBurstCycles.
• Specifying SlowedDownBurstCycles directly in the LogicbistVerify or ScanVerify
wrapper is equivalent to repeatedly specifying it in a BurstClockController wrapper for all
• SlowedDownBurstCycles declared in the BurstClockController wrapper has precedence
over SlowedDownBurstCycles declared directly in the LogicbistVerify or ScanVerify
wrapper.
• When BurstCyclesWithShiftClock is set to Yes, then SlowedDownBurstCycles is not
supported by the hardware and is ignored.
Example
This example specifies that all Burst Clock controllers should slow down 2 burst cycles for
those burst clock controllers with a BurstLength greater than 3, while those with a
BurstLength of less than 4 will only have 1 slowed down burst cycle.

September 2017
etv (MyDesignA) {
TestStep (1) {
}
}
}
}
Related Information
BurstClockController LogicbistVerify

September 2017
StartVector
StartVector
The sections below provide detailed information on the following usage of the StartVector
property:
The StartVector property enables you to specify the first logic BIST vector to apply.
Syntax
StartVector: <value>;
where value is either an integer or an arithmetic expression consisting of integers and keywords
LastVector and LastDefaultVector. The arithmetic expression must be in double quotes.
Default Value
Usage Conditions
This property is used in the LogicbistVerify: Controller wrapper.
When you set the StartVector property to a non-default value, the value you specify for
RunMode must be RunTimeProg.
Example
This example specifies that the last 1/4 of all available vectors are applied.
etv (MyDesignA) {
TestStep (1) {
}
}
}
}
Related Information
Controller RunMode
LogicbistVerify StartVector
EndVector
ScanVerify Usage
The StartVector property enables you to specify the first scan vector to apply.

September 2017
ScanVerify Usage
Syntax
StartVector: <value>;
where value is an integer or an arithmetic expression consisting of integers and the keyword
LastVector. The arithmetic expression must be in double quotes.
You can also specify the following keywords for <value>:
• LastChainTestVector
• FirstScanTestVector
You use these keywords to distinguish chain test vectors from scan test vectors, and simulate a
given number of chain test patterns followed by a given number of scan test patterns. Refer to
Example A-1 on page 298.
Default Value
The default value is 1, the initial vector in the test pattern file created by the ETVerify tool.
Usage Conditions
This property is used in the ScanVerify wrapper.
• The EndVector and StartVector properties enable you to specify the exact number of
vectors that you want to include in the test bench or manufacturing test file.
• The EndVector and StartVector properties can also be specified in the TestStep wrapper
but only when Mode is set to Prepare. In this case, there is no Controller wrapper.
Example
This example specifies that the initial ControllerChain scan vector to be applied is 10.
etv (MyDesignA) {
ScanVerify (4) {
PatternName: controllerChain_1;
TCKRerios: 100.0ns;
TestStep (ControllerChain) {
ETATestGroupName: scanVerify;
Mode: ControllerChain;
StartVector: 10;
}
}
}
Related Information
EndVector TestStep
Mode ScanVerify

September 2017
SplitPattern
SplitPattern
The SplitPattern property instructs ETVerify to create a new tester pattern fragment when
writing out the current test step. The pattern can be in either WGL, STIL, or SVF format. Some
manufacturing processes use test programs containing multiple WGL, STIL, or SVF fragments.
Syntax
SplitPattern: On | (Off);
Default Value
Usage Conditions
This property is used in the MembistVerify: TestStep and MembistPVerify: TestStep wrappers
of the .etManufacturing file.
Example
This example instructs ETVerify to create a separate pattern that starts with the current test step.
MembistPVerify (TOP_P1) {
TestStep (SPLIT) {
SplitPattern: On;
RunMode: HWDefault;
Controller(BP2) {
CompareGoID: On;
ExtractRepairFuseMap: Off;
CheckRepairStatus: Off;
}
}
}
Related Information
MembistPVerify

September 2017
StilVectorFile
StilVectorFile
The StilVectorFile property enables you to specify the STIL file generated by Tessent FastScan
or Tessent TestKompress, that provides the vector set to be used in a ScanVerify wrapper.
Syntax
StilVectorFile: <fileName>;
where fileName can be any identifier that is a valid operating system file name.
Default Value
None
Usage Conditions
• The StilVectorFile property appears in the ScanVerify wrapper if the ETPlanner
VectorFileFormat property is specified to Stil. The StilVectorFile and PatternDBFile
property are mutually exclusive.
Example
This example instructs ETVerify to use the STIL vector file TOP.fastscan_vector_multi_stil.
etv (MyDesignA) {
ScanVerify (multi){
...
TestStep (Serial){
Mode: Multi;
Controller (BP0) {
StilVectorFile:
TOP.fastscan_vector_multi_stil;
StarVector: 1;
EndVector: 2;
}
}
}
}
Related Information
Controller PatternDBFile
TestStep VectorFileFormat in the manual ETPlanner
Tool Reference
ScanVerify

September 2017
SurfaceProportion
SurfaceProportion
The SurfaceProportion property allows you to specify the proportion of the total noise bits
captured around the median of the measured beat period edge to include in the measurement of
the RmsJitter test.
Syntax
SurfaceProportion: (1/2) | 1/4 | 1/8 | PEAK2PEAK;
Default Value
The default value is 1/2.
Usage Conditions
Example
SurfaceProportion: 1/2;
Related Information
MeasurementEdge TestStep

September 2017
SVFFile
SVFFile
The SVFFile property specifies one or more file names of pre-existing SVF sequences that will
be included within a UserDefinedSequence.
When you specify the SVFFile property, ETVerify looks for the following SVF files:
• <svfDir>/<svfID>.svf when the ETVerify runtime option -inputLVDBName is not
specified. If -svfDir is not explicitly specified, <svfDir> defaults to the current working
directory.
• <inputLVDBName>/SVFFiles/<svfID>.svf when the ETVerify runtime option
-inputLVDBName is specified.
When the LVDB is created, all SVF files in the directory that the -svfDir runtime option points
to are copied into the SVFFiles directory inside the LVDB directory.
Syntax
SVFFile: <svfName>;
where svfName is a comma-separated list of file names of pre-existing SVF sequences.

Default Value
None
Usage Conditions
This property is used in the UserDefinedSequence wrapper.
• In the BSDL-only verification flow, the SVFFile and TestStep properties are mutually
exclusive within a given UserDefinedSequence wrapper.
• If the UserDefinedSequence is used as a PreTAPUserDefinedSequence, it is assumed that
the Mentor Graphics TAP controller has been reset in the SVF. Therefore, after the SVF
sequence is applied, you must ensure that the Mentor Graphics TAP controller is placed in
the Run Test Idle state.
• Mentor Graphics supports the following SVF commands:
o PIOMAP
o PIO
o SIR
o SDR
o RUNTEST

September 2017
SVFFile
• The Mentor Graphics SVF parser also supports the following two commands/pragmas.
Because both pragmas start with a comment character, third-party SVF parsers will treat
them as comments.
o !LV TDO_SYMBOL — Identifies the register associated with a failing bit that helps in
debugging.
o — Monitors results in the SVF flow. Bits labelled as
!LV TDO_SAMPLE
TDO_SAMPLE contain special data and are not compared during scan-out.
The following syntax specifies these commands:
!LV TDO_SYMBOL [<index_range>] <register_name> [<register_size>];
!LV TDO_SAMPLE [<index_range>] <register_name> [<register_size>];
where:
<index_ranges> := <index_range> {, <index_range>}
<index_range> :::= <integer>: <integer>
<register_name> :::= <identifier>
<register_size> :::= <integer>
o Text in boldface denotes keywords and required syntax punctuations.

o One space must be between !LV and TDO_SYMBOL and between !LV and
TDO_SAMPLE.
o If a failing bit has an associated symbol, the symbol name is reported along with the
failure. Otherwise, failures of an instruction register are reported as IR#, and failures
of a data register are reported as DR#, where # is the failing bit of the instruction or
data register being scanned out. For example:
LV TDO_SYMBOL [0:4,15:11] IR_STATUS[10];
If bit 1 fails during an SIR operation, ETVerify reports IR_STATUS[1] as the failing
bit. However, if bit 5 fails, ETVerify reports IR5 as the failing bit.
o The syntax in the following example shows that bits 34 through 41 are treated as
special data bits signifying an error count. These bits are not compared against an
expected value.
!LV TDO_SAMPLE [34:41] SVF_BP1_ERROR_CNT[8];
• ETVerify does not track what actions the SVF takes. This means that if an SVF file sets a
UserIRBit/UserDRBit and that bit needs to remain set for the entire pattern, then ETVerify
will reset that bit the next time it accesses the IR/DR register. In order to preserve the bit
settings applied by the SVF, you must add a TestStep to the UserDefinedSequence and use
the UserIRBit/UserDRBit properties to set the value that is needed on those bits. Refer to
“Example 3” on page 541.
Example 1
The following example specifies that the sequence defined in the file ./mySVF.svf will be
included in this pattern.

September 2017
SVFFile
etv (MyDesignA) {
UserDefinedSequence (USD_1) {
SVFFile: mySVF;
}
}
Example 2
The following example loads two SVF files, lv_jtag_en and pll_en, in the UDS setup_seq.
When you specify multiple SVF files, they are applied from left to right. So in the example,
lv_jtag_en is applied before pll_en.
etv (chip) }
UserDefinedSequence (setup_seq) {
SVFFile: lv_jtag_en, pll_en;
TestStep (1) {
UserIRBit (0): On;
}
}
}
Example 3
In this example, the SVF had set UserDRBit 14 to 1. You would then need to also set the
TestStep 'UserDRBit(14) : on;'. Add UserDRBit properties in the first TestStep that accesses the
INT_DR so any userDRbits are not reset.
UserDefinedSequence(PostTAP_UDS_with_SVF) {
SVFFile: PostTAP.svf;
ClockSourceOverride {...}
TestStep(PostTAP_svf_TestStep_0) {
//
// Add UserDRBit properties so we shift in the UserDRBit values
// set in the SVF
//
UserDRBit(14) : On;
}
TestStep(DeassertReset) {
PinSettings { RESETN : 1; }
}
...
}
Related Information
UserDefinedSequence -inputLVDBName
SVFFile -svfDir
TestStep

September 2017
SVFName
SVFName
The SVFName property enables you to specify the name of an svf sequence to include with this
pattern.
Syntax
SVFName: <svfName>;
where svfName corresponds to the following:

• A file called <svfDir>/<svfName>.svf when -inputLVDBName is not specified. Note that
svfDir defaults to. when -svfDir is not specified.
• A file called <inoutLVDBName>/SVFFiles/<svfName>.svf when -inputLVDBName is
specified.
Default Value
None
Usage Conditions
This property is used in the CustomVerify wrapper.
• Within a given CustomVerify wrapper, SVFName and UserDefinedSequence are mutually
exclusive.
• The following properties in CustomVerify are ignored when SVFName is specified:
o TestClockSource
o UserDRBit
o UserIRBit
• Mentor Graphics supports the following SVF commands:
o PIOMAP
o PIO
o SIR
o SDR
o RUNTEST
• Two new commands/pragmas are introduced and supported by Mentor Graphics SVF
parser: !LV TDO_SYMBOL anLV TDO_SAMPLE.
!LV TDO_SYMBOL — This command is used to identify the register associated with a failing
bit.

September 2017
SVFName
!LV TDO_SAMPLE — This command is used to monitor results in the SVF flow. Bits labelled
as TDO_SAMPLE contain special data and are not compared during scanning out.
The following syntax specifies these new commands:
!LV TDO_SYMBOL [<index_range>] <register_name>
[<register_size>];
!LV TDO_SAMPLE [<index_range>] <register_name>
[<register_size>];
where:
<index_ranges> ::= <index_range> { , <index_range>}
<index_range> :::= <integer> : <integer>
o Text in bold denote keywords and required syntax punctuations.

o There should be exactly one space between !LV and TDO_SYMBOL, !LV and
TDO_SAMPLE.
o If a failing bit has a symbol associated with it, then the symbol name will be reported
along with the failure. Otherwise, failures of an instruction register will be reported
as IR#, and those on a data register will be reported as DR# where # is the failing bit
of the instruction or data register being scanned out. For example:
LV TDO_SYMBOL [0:4,15:11] IR_STATUS[10];
If bit 1 fails during an SIR operation, ETVerify will report IR_STATUS[1] as the
failing bit.
o The syntax in the following example means bits 34 through 41 are treated as special
data bits signifying an error count. These bits are not compared against an expected
value.
!LV TDO_SYMBOL [34:41] SVF_BP1_ERROR_CNT[8];
Example
This example specifies to include the sequence defined in the file ./mySVF.svf in this pattern.
etv (MyDesignA) {
CustomVerify (ctrl1) {
SVFName: mySVF;
}
}

September 2017
SVFName
Related Information
CustomVerify UserDRBit
IncludeTapInit UserIRBit
SVFFile -inputLVDBName
TestClockSource -svfDir
UserDefinedSequence

September 2017
Tap
Tap
The Tap wrapper is used for multi-chip modules that consist of two or more die packaged into a
single part. Each die will have an IEEE 1149.1 TAP module that is daisy-chained with the next
die. ETVerify will generate test patterns to address the die-under-test. The Tap wrapper
describes one TAP in the daisy chain.
Syntax
}
Usage Conditions
This wrapper is used in the JTAPAccess:PreAmble and JTAPAccess:PostAmble wrappers of
the Global Section.
• Except for the TAP being verified, each TAP in the daisy chain should have a Tap wrapper.
• The DeviceId property is mandatory only if the preamble or postamble TAP has a device ID
register.
Example
Refer to Figure A-16 for an example of the Tap wrapper.
Related Information
JTAPAccess PreAmble
PostAmble BypassOpCode
DeviceId

September 2017
TCKPeriod
TCKPeriod
The TCKPeriod property enables you to specify the TCK (test clock) clock period used in the
test bench.
Syntax
TCKPeriod: <time>;
where time is a real number specified in nanoseconds.

Default Value
The default value is 100 nanoseconds.
Usage Conditions
The TCKPeriod property is used in the following types of verification:
Table A-12. TCKPeriod Usage Conditions

Usage Conditions TAP Verification Custom Verification
Section Section
WTAP Verification Logic BIST Verification
Section Section
Scan Verification
Section
Memory BIST
SerdesTest Verification
Section
Specify the period of TCK clock when the ✓
UseAsyncClocks property is set to On or
when the TestClockSource property is set to
TCK. Otherwise, the ClockPeriod wrapper
should be used.
TCKPeriod is the only period to define. ✓
Example
This example instructs ETVerify to use a period of 10 nanoseconds.
etv (MyDesignA) {
ScanVerify (1) {
TestClockSource: TCK;
TCKPeriod: 100;
}
}

September 2017
TCKPeriod
Related Information
TestClockSource ScanVerify
ClockPeriod SerdesVerify
CustomVerify TCKRatio
JtagVerify TestClockSource
LogicbistVerify UseAsyncClocks
MembistVerify

September 2017
TCKRatio
TCKRatio
The TCKRatio property enables you to specify the ratio of the period of the TCK test clock to
the period of the master clock in the test bench. You use the related ClockPeriod to specify the
period of the master clock.
Syntax
TCKRatio: 1 | 4 | 8 | 16 | 32| 64 | 128;

• 1 — specifies that the periods of TCK and the master clock are identical.
• 4 — specifies that the period of TCK is 4 times the period of the master clock.
Default Value
The default value of the TCKRatio property depends on the following:
how UseAsyncClocks is set.
• When UseAsyncClocks is set to On, the TCKRatio property defaults to 1.
• When UseAsyncClocks is set to Off, the TCKRatio property defaults to 16.
Usage Conditions
The TCKRatio property is used in the following types of verification:
Table A-13. TCKRatio Usage Conditions

Usage Conditions Logic BIST Scan Custom Memory BIST
Verification Verification Verification Verification
Section Section Section Section
SerdesTest
Verification
Section
For TAP protocol, TCK ✓
period must be at least 4 times
longer than period of
BIST_CLK.

September 2017
TCKRatio
Table A-13. TCKRatio Usage Conditions

Usage Conditions Logic BIST Scan Custom Memory BIST
Verification Verification Verification Verification
Section Section Section Section
SerdesTest
Verification
Section
For Direct Pin protocol, TCK ✓
period must be at least 8 times
longer than BIST_CLK
period.
If TestClockSource is set to ✓ ✓ ✓
TCK, the TCKRatio property Only used for Only used for
should be set to 1. pre-5.0 logic pre-5.0 logic
BIST BIST
controllers controllers
The TCKRatio property ✓
cannot be set to a value
greater than 1 when
ParallelLoad is set to On.
Example
In this example, ETVerify sets the period of the master clock to 100 ns and the period of TCK to
400 ns.
etv (MyDesignA) {
ClockPeriod: 100;
TCKRatio: 4;
}
}
Related Information
ClockPeriod ParallelLoad
LogicbistVerify SerdesVerify
MembistPVerify TestClockSource
MembistVerify UseAsyncClocks

September 2017
TestBenchModuleName
TestBenchModuleName
The TestBenchModuleName property specifies the Verilog top-level module name of the test
bench in the <patternName>.v file. You can use this property to give a different test bench
module name for each test bench so that more than one test bench can be loaded into a Verilog
simulator at the same time.
Syntax
where name is the Verilog top-level module name of the test bench.
Default Value
The default value is TB.
Usage Conditions
• CPUVerify
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• ScanVerify
• SerdesVerify
• WTAPVerify
Example
This example specifies the top-level module name in the JTAG verification test bench as
JTAG_TB:
etv (TOP) {
JTagVerify (TOP) {
PatternName: tapbistv;
TestBenchModuleName: JTAG_TB;
}
}
The output file tapbistv.v contains:

module JTAG_TB();
...
endmodule

September 2017
TestBenchModuleName
Related Information

September 2017
TestClockSource
TestClockSource
TestClockSource can be used in the ETVerify configuration file as follows:
• A Property inside several xxxVerify wrappers
• A Wrapper inside UserDefinedSequence
Property
The TestClockSource property enables you to specify the clock source for the embedded test
controllers.
Syntax
TestClockSource: (Functional) | TCK | (System) | System_2 | System_4 |
SystemPLL | SystemPLL_2 | SystemPLL_4 | Test;

• Functional — indicates that the clock source comes through the functional path of the
design. This may be routed directly from an input pin or through a PLL, divider, or
multiplexer.
• TCK — indicates that the clock source is the TAP TCK.
• System — indicates that the clock source comes from the main system clock pin and has a
period equal to the system clock period. Valid only for designs with inserted LogicBIST.
• System_2 — indicates that the clock source comes from the main system clock pin and has a
period equal to twice the system clock period (1/2 frequency). Valid only for designs with
inserted LogicBIST.
• System_4 — indicates that the clock source comes from the main system clock pin and has a
period equal to four times the system clock period (1/4 frequency). Valid only for designs
with inserted LogicBIST.
• SystemPLL — indicates that the clock source comes from the PLL (phase-locked loop) and
has a period equal to the system clock period. Valid only for designs with inserted
LogicBIST.
• SystemPLL_2 — indicates that the clock source comes from the PLL and has a period equal
to twice the system clock period (1/2 frequency). Valid only for designs with inserted
LogicBIST.
• SystemPLL_4 — indicates that the clock source comes from the PLL and has a period equal
to four times the system clock period (1/4 frequency). Valid only for designs with inserted
LogicBIST.
• Test — indicates that the clock source comes from the test side of a 2:1 multiplexer that is
used to inject the test clock source at the base of the clock domain used by the memory BIST
controller. This is used only when ETVerify generates a test pattern using the Direct Pin
protocol on the pins of a sub-block module. The multiplexer on the clock domain inside the
sub-block module, and the select line is controlled by a primary input of the sub-block
module and has been properly described as a FuncMode port in the .designe file before

September 2017
TestClockSource
designExtract was run. Specifying the value System is synonymous to Test for the Direct Pin
protocol.
When System/System_2/System_4/SystemPLL/SystemPLL_2/SystemPLL_4 are specified, and
logic test is present, then:
• System = ShiftClockSource1
• System_2 = ShiftClockSource1/2
• SystemPLL = ShiftClockSource2
• System_4 = ShiftClockSource1/4
• SystemPLL_2 = ShiftClockSource2/2
• SystemPLL_4 = ShiftClockSource2/4.
Default Value
The default value for the TestClockSource property is different for the following types of
verification:
Table A-14. TestClockSource Default Values
Default is... Custom Verification Section Logic BIST
Verification
Section
Functional ✓
System ✓
Usage Conditions
The TestClockSource property is used for the following types of verification:
Table A-15. TestClockSource Usage Conditions

Usage Conditions Custom Logic BIST Memory
Section
TAP
Verification
Section
For chip-level verification, this ✓ ✓ ✓
property is only meaningful when the
embedded test controller is accessed
through TAP.

September 2017
TestClockSource
Table A-15. TestClockSource Usage Conditions

Usage Conditions Custom Logic BIST Memory
Section
TAP
Verification
Section
The TestClockSource property is ✓
ignored when the SVFName
property is specified.
The design contains a clock
multiplexer where the multiplexer
select signal is identified by the
FuncMode wrapper in the .designe
file.
The TestClockSource property is ✓
only used in the LogicBistVerify
wrapper for pre-existing cores
created with Mentor Graphics
software prior to Version 5.0.
Example
This example specifies that the clock driving the embedded test controller is generated from the
PLL and has a period equal to twice the system clock period.
etv (MyDesignA) {
TestClockSource: SystemPLL_2;
}
}
Related Information
CustomVerify MembistPVerify
JtagVerify MembistVerify
IncludeTapInit SVFName
LogicbistVerify

September 2017
TestClockSource
Wrapper
The TestClockSource wrapper allows you to identify which memory BIST controller clock
sources will be affected when the UserDefinedSequence is used in a MembistPVerify or
MembistVerify wrapper.
Syntax
Pin: <string>;
PinInv: <string>;
where RE is a comma-separated list of regular expressions identifying a valid TestClockSource

value.
Usage Conditions
This wrapper is used in the UserDefinedSequence: ClockSourceOverride: PhysicalRegion:
MemBistController wrapper.
• The supplied regular expression must match one of the following legal TestClockSource
values:
o Functional
o TCK
o System
o System_2
o System_4
o SystemPLL
o SystemPLL_2
o SystemPLL_4
For more details on these TestClockSource values, refer to the TestClockSource Property.

September 2017
TestClockSource
Example
The following example shows the TestClockSource wrapper used to change the System_2 and
System_4 clock sources for all the memory BIST controllers which module name and/or
instance name contain the string .*F300.*.
PhysicalRegion (.*) {
Pin: clk[0];
}
}
}
}
...
}
TestClockSource wrapper.
Summary of the MemBistController Overrides
------------------------------------------
Overrides for TestClockSource System_2:
BistPort Source Pin FreqRatioRelToSource
--------------------------------------------------------------------
BP2 clk[0] 1.0
BP3 clk[0] 1.0
Overrides for TestClockSource System_4:

BistPort Source Pin FreqRatioRelToSource
--------------------------------------------------------------------
BP2 clk[0] 1.0
BP3 clk[0] 1.0
Related Information
ClockSourceOverride MembistVerify
MemBistController PhysicalRegion

September 2017
TestDurationInBeatCycles
TestDurationInBeatCycles
The TestDurationInBeatCycles property allows you to specify the duration of the current test in
cycles, assuming that there is an offset in frequency between the transmitter (serializer) and the
receiver (de-serializer) that will result in a beat frequency of the signal coming out of the
median detector of the ULTRA controller. This selection applies to all tests listed in SerdesTest,
except FunctionalLoopback and BasicTests.
Syntax
TestDurationInBeatCycles: <int>
where int is an integer number greater than or equal to 0.

Default Value
The default is 0.
Usage Conditions
Example
TestDurationInBeatCycles: 1000;
Related Information

September 2017
The TestEndRefreshEnable property enables you to specify if AutoRefresh operations are to
be automatically performed on a DRAM after the execution of the algorithm. The default
duration between AutoRefresh operations is determined when the controller is generated. You
can override the default duration by setting RunMode to RunTimeProg and specifying the
TestEndRefreshInterval property.
Syntax
TestEndRefreshEnable: On | (Off);

• On — specifies that AutoRefresh operations are to be automatically performed after the
• Off — specifies that AutoRefresh operations are not to be performed automatically after the
Default Value
Usage Conditions
• The memory library file property RetentionTimeMax determines the default refresh
interval.
• PersistentBISTInputs must be set to On.
• When this property is set to On and RunMode is HWDefault, the default refresh interval will
be used.
• When this property is set to On and RunMode is RunTimeProg, you can override the default
refresh interval using the TestEndRefreshInterval property.
Example
This example specifies that AutoRefresh operations are to be performed by the programmable
memory BIST controller after execution of the algorithm.
TestStep (4) {
TestEndRefreshEnable: On;
PersistentBISTInputs: On;

September 2017
Related Information
Controller RunMode
TestEndRefreshInterval RetentionTimeMax in the manual

September 2017
TestEndRefreshInterval
The TestEndRefreshInterval property enables you to specify the refresh interval that overrides
the default value determined by the RetentionTimeMax property of the memory library files.
The TestEndRefreshInterval value is scanned into the programmable memory BIST controller
and is used for counting the time between two consecutive AutoRefresh operations applied to a
DRAM after the test completion.
Syntax
TestEndRefreshInterval: time[s | ms | us | (ns) | ps];
where time is a real number. Valid values for specifying the units for time are as follows:
• s — specifies the refresh interval in seconds.
• ms — specifies the refresh interval in milliseconds.
• us — specifies the refresh interval in microseconds.
• ns — specifies the refresh interval in nanoseconds.
• ps — specifies the refresh interval in picoseconds.
Default Value
If this property value is not specified, it defaults to the lowest value of all RetentionTimeMax
properties in the memory library files divided by the maximum number of memory rows.
Usage Conditions
• TestEndRefreshEnable must be set to On.
• RunMode must be set to RunTimeProg; otherwise, this property is ignored.
• The specified value of TestEndRefreshInterval must be greater than zero.
• Note that consecutive AutoRefresh operations cannot be applied one after another; they must
alternate with at least one NoOperation operation. Therefore, if the specified value for
TestEndRefreshInterval is shorter than the total duration of the AutoRefresh operation and
the NoOperation operation of a particular operation set, then the AutoRefresh is applied less
frequently than specified with the property and may violate the memory retention time.
• PersistentBISTInputs must be On to enable the refresh mode while the controller is not
executing.
Example
This example specifies an elapsed time of 250 milliseconds between two successive
AutoRefresh operations after execution of the algorithm.

September 2017
TestStep (4) {
TestEndRefreshEnable: On;
TestEndRefreshInterval: 250ms;
PersistentBISTInputs: On;
Related Information
Controller TestStep
MembistPVerify RetentionTimeMax in the manual
RunMode TestEndRefreshInterval in the manual
TestEndRefreshEnable PersistentBISTInputs

September 2017
TestPath
TestPath
The TestPath property enables you to specify the enable path(s), locally and/or globally, to test
during the TriStateEnableNC test.
Syntax
TestPath: (Both) | Local | Global;

• Both — specifies that the TriStateEnableNC test verifies both enable paths sequentially.
• Local — specifies that the TriStateEnableNC test verifies only the enable path that
originates at the enable boundary-scan cells.
• Global — specifies that the TriStateEnableNC test verifies only the enable path that
originates at the TAP output ForceDisable.
Default Value
Usage Conditions
This property is used in the JtagVerify: TestStep: TriStateEnableNCOptions wrapper.
TriStateEnableNC.
Example
This example specifies that only the local enable path is verified during the TriStateEnableNC
test.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
TestPath: Local;
}
}
}
}
Related Information
RunTest TriStateEnableNCOptions
TestStep JtagVerify

September 2017
TestStep
TestStep
The sections below provide detailed information on the following usage of the TestStep
wrapper:
• MembistPVerify Usage
• MembistVerify Usage
• UserDefinedSequence Usage
• CPUVerify Usage
JtagVerify Usage
The required TestStep wrapper groups different TAP and IO tests. Each test step is processed
sequentially and independently of all others.
Syntax
For the complete syntax for the wrapper, refer to the TAP Verification Section.
testStepName of the TestStep wrapper is a string that identifies the test step in the generated test
bench.
Default Value
None
Usage Conditions
• You must repeat this wrapper for each test step.
• Test steps are executed in the order in which they appear in the configuration file.
Example
This example shows that TestStep (0) and TestStep (1) run different tests.

September 2017
TestStep
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
RunTest: Input;
RunTest: Output;
}
TestStep (1) {
RunTest: BypassReg;
RunTest: Sample;
}
}
}
The TestStep wrapper is used to group all logic BIST controllers that are to be run in parallel.
You can specify multiple TestStep wrappers in the configuration file.
The test steps are executed in the order they appear. Normally, only a single logic BIST
controller is run in each TestStep. It is possible to run multiple embedded logic BIST controllers
within a single test step.
Syntax
For the complete syntax for the wrapper, refer to the Logic BIST Verification Section.
MembistPVerify Usage
The TestStep wrapper is used to specify a set of tests to be performed by the memory BIST
controller. All programmable memory BIST controllers are to be run in parallel. You specify
multiple TestStep wrappers in the wrapper in the configuration file.
Syntax
For the complete syntax for the wrapper, refer to the Memory BIST Verification Section.
MembistVerify Usage
The TestStep wrapper is used to group all memory BIST controllers that are to be run in
parallel. You may specify multiple TestStep wrappers in the configuration file.
Syntax
For the complete syntax for the wrapper, refer to the Memory BIST Verification Section.
ScanVerify Usage
The TestStep wrapper is used to specify the type of scan tests to apply (scan tests in
single/multi/controllerChain, flop asynchronous set/reset tests, flop retention tests) and the
circuit to which the tests should be applied.
These test steps are executed in the order that they appear. Only one controller can be specified
in each TestStep.

September 2017
TestStep
Syntax
For the complete syntax for the wrapper, refer to the Scan Verification Section.
SerdesVerify Usage
The TestStep wrapper is used to group all ULTRA controllers that are to be run in parallel. You
can specify multiple TestStep wrappers in the configuration file.
These test steps are executed in the order that they appear. Normally, only a single ULTRA
controller is run in each TestStep. It is possible to run multiple UTRA controllers within a single
test step.
Syntax
For the complete syntax for the wrapper, refer to the SerdesTest Verification Section.
UserDefinedSequence Usage
The TestStep wrapper is used to used to define a set of actions to perform in your custom
initialization sequence.
A listing of the wrappers and properties available within the TestStep wrapper follows
Figure A-20.
Syntax
Figure A-20 presents the complete syntax for the TestStep wrapper in the
UserDefinedSequence wrapper.
Figure A-20. TestStep Wrapper in the UserDefinedSequence Wrapper
TestStep (<testStepId>) {//Repeatable

PinSettings{
PinCompares{
<pinName>: 0 | 1 | x;
WTAPSettings(<moduleName>| DP# | BP#){//Repeatable
UserBitAlias(<n>): <binaryNumber>;
For the TestStep wrapper, testStepID is a unique name for the defined initialization sequence.

September 2017
TestStep
WTAPVerify Usage
The TestStep wrapper groups different tests. Each test step is processed sequentially and
independently of all others.
Syntax
For the complete syntax for the wrapper, refer to the WTAP Verification Section.
Usage Conditions
This wrapper is used in the WTAPVerify wrapper.
• Test steps are executed in the order in which they appear in WTAPVerify.
Example
etv (MyDesignA) {
WTAPVerify (core1) {
TestStep (0) {
Controller (BP0)
RunTest: InstReg;
}
}
TestStep (1) {
Controller (BP0)
RunTest: BypassReg;
}
}
}
}
CPUVerify Usage
The TestStep wrapper groups different tests. Each test step is processed sequentially and
independently of all others.
Syntax
For the complete syntax for the wrapper, refer to the CPU Verification Section.
Usage Conditions
This wrapper is used in the CPUVerify wrapper.

September 2017
TestStep

• Test steps are executed in the order in which they appear in CPUVerify.
Example
etv (MyDesignA) {
CPUVerify (Test1) {
TestStep (0) {
CPUActionsFile: myChip_TAPTest.cpuWR;
Variable {
CPUInterfaceAddress[7:0]: 8’h30;
RegAVal[3:0]: 4’b0110;
}
}
}
}

September 2017
TestTimeMultiplier
TestTimeMultiplier
The sections below provide detailed information on the following usage of the
TestTimeMultiplier property:
• Memory BIST Usage
• CPUVerify Usage
Memory BIST Usage
The TestTimeMultiplier property specifies the multiplier to extend the memory BIST run time.
The final time would be equal to the original test time (as calculated by ETAssemble) multiplied
by the value defined using the TestTimeMultiplier property.
Syntax
TestTimeMultiplier: <mulNum>;
where mulNum is a real number.

Default Value
Usage Conditions
This property is used in the TestStep: Controller wrapper of the following verification types:
• MembistPVerify
• MembistVerify
Example
This example instructs ETVerify to stretch the membist run by 20%.
etv (MyDesignA) {
MembistVerify (1) {
TestStep (0) {
TestTimeMultiplier: 1.2;
}
}
}
}
Related Information

September 2017
TestTimeMultiplier
SerdesVerify Usage
The TestTimeMultiplier property specifies a multiplier that applies to the duration of the
current test step.
Syntax
where x is a real value greater than 0.0.

Default Value
Usage Conditions
This property is used in the SerdesVerify: Controller wrapper.
• Test time is extended when the multiplier is greater than 1.0 and shortened when the
multiplier is less than 1.0.
• You can use this option to dramatically decrease simulation time, especially for the jitter
test.
• You can also use this option to optimize test time for the generated test vector or test bench
by overriding the calculated worst case value that ETVerify normally uses.
Related Information
CPUVerify Usage
The TestTimeMultiplier property specifies a multiplier that applies to the duration of the
current test step.
Syntax
where x is a real value greater than 0.0.

Default Value
Usage Conditions
This property is used in the CPUVerify wrapper.

September 2017
TestTimeMultiplier
• Test time is extended when the multiplier is greater than 1.0 and shortened when the
multiplier is less than 1.0.
• You can use this option to dramatically decrease simulation time, especially for the jitter
test.
• You can also use this option to optimize test time for the generated test vector or test bench
by overriding the calculated worst case value that ETVerify normally uses.
Related Information
CPUVerify

September 2017
TogglePattern
TogglePattern
The TogglePattern property instructs the Test Pattern Generator (TPG) to apply the selected
Pattern while toggling it from its reference value to its binary complement. This toggling
happens for every cycle of the serializer parallel clock rate.
For example, for a 20-bit word, and if the P1100 pattern is selected, the words transmitted will
toggle between 20’b11001100110011001100 and 20’b00110011001100110011.
Syntax
TogglePattern: On | (Off);
Default Value
Usage Conditions
This property is used in the SerdesVerify: TestStep wrapper.
Applicable Tests
This property will have no effect on the following tests—FunctionalLoopback and BasicTests.
Example
TogglePattern: On;
Related Information
InjectErrors SerdesVerify
Pattern TestStep

September 2017
TPGChannelEnable
TPGChannelEnable
The TPGChannelEnable property enables the Test Pattern Generator (TPG) for one channel.
Given that this property is repeatable, many TPGs can be started during the course of one test.
By default, when a specific channel is selected for a test with the ChannelSelect property, the
TPG associated with this channel is automatically started for the tests that require a pattern to be
generated for the same channel where the measurement is performed. This includes the
following tests: RmsJitter, DutyCycle, Delay.
In case of the FunctionalLoopback test, the success of the test will be verified for all those TPGs
and RPAs that are started at the beginning of the test.
Syntax
TPGChannelEnable: <int>;

Default Value
The default value depends on the ChannelSelect value.
Usage Conditions
generated. The ETVerify tool will automatically validate this value and reject invalid ones.
Example
TestSelect: FunctionalLoopback;
Related Information
ChannelSelect SerdesVerify
Controller TestStep
RPAChannelEnable Channel in the manual ETPlanner Tool
Reference

September 2017
TriStateEnableNCOptions
The TriStateEnableNCOptions wrapper enables you to specify properties for the
TriStateEnableNC test.
Syntax
TriStateEnablesNCOptions {
TestPath: (Both) | Local |Global;
NumberOfCycles: <n>;
LogicLevel: (Both) | High| Low;
}
Default Value
None
Usage Conditions
Only use this wrapper and its associated properties when RunTest is set to TriStateEnableNC.
Example
The following example specifies that TestStep (0) and TestStep (1) run the TriStateEnableNC
test with different parameters.
etv (MyDesignA) {
JtagVerify (ETC) {
TestStep (0) {
TestPath: Local;
NumberOfCycles: 7;
LogicLevel: Both;
}
}
TestStep (1) {
TestPath: Global;
NumberOfCycles: 7;
LogicLevel: Both;
}
}
}
}

September 2017
Related Information
LogicLevel TestPath
NumberOfCycles TestStep
RunTest JtagVerify
SimulationModel TestPath

September 2017
Type
Type
The Type property enables you to control whether the generated WGL complies with the
requirements of LSI Logic.
Syntax
Type: (Generic) | LSI;

• Generic — generates a WGL format pattern file, which does not comply with the
requirements of LSI logic.
• LSI — generates a WGL format pattern file, which complies with the requirements of LSI
logic.
Default Value
The default is Generic.
Usage Conditions
This property is used in the WGL wrapper in the Tester-Related Data Section.
• If you are using LSI Logic as your ASIC vendor, you specify this option.
• If the WGL wrapper is included into the ETVerify configuration file and the Type property
is set to LSI, ETVerify will generate LSI specific TCF (Test Condition file) file, as shown in
the example below:
Figure A-21. Sample ETVerify Configuration File
etv (SOC) {
IncludeAllNonPowerPins: No;
FlattenLoops: None;
MaxLoopCount: 5000;
WGL {
Type: LSI;
}
JtagVerify (1) {
...
}
}
Example
In this example, ETVerify generates a WGL format pattern file that complies with the
requirements of LSI Logic.
WGL {
Type: LSI;
}

September 2017
Type
Related Information
WGL -wgl

September 2017
UnderSamplingClkRatio
UnderSamplingClkRatio
The UnderSamplingClkRatio property allows you to specify how many sampling clock cycles
between each sample to consider for the current measurement. This selection applies to all tests
listed in SerdesTest, except BasicTests and FunctionalLoopback.
Syntax
UnderSamplingClkRatio: <int>;
where int is an integer number greater or equal to 0. A value of 0 means that the sampling
occurs every cycle. A value of 1 means that the sampling occurs every other clock cycle.
Default Value
Usage Conditions
Example
UnderSamplingClkRatio: 2;
Related Information

September 2017
UpperLimit
UpperLimit
specifies the test limits for the measurement performed.
Syntax
MeasurementLimits (<units>) {
LowerLimit: <real>;
UpperLimit: <real>;
}
Default Value
Usage Conditions
This property is valid only in the SerdesVerify: TestStep: Controller: MeasurementLimits
wrapper.
Example
The following will perform an DutyCycleDistortion test for controller BP1, and comparing the
expected measurement to both lower an upper limits.
etv (MyChip) {
SerdesVerify (Distortion) {
TestStep (DistortionTS) {
SerdesTest: DutyCycleDistortion;
Pattern: P1010;
Controller (BP1) {
//...
MeasurementLimits (%) {
LowerLimit: -1.0;
UpperLimit: 1.0;
}
}
}
}
}
Related Information
LowerLimit TestStep
MeasurementLimits

September 2017
UseAsyncClocks
UseAsyncClocks
The UseAsyncClocks property enables you to specify whether or not the test bench generates
asynchronous clocks inside a DUT or uses synchronous tester clocks.
Syntax

• On — does not generate any system clocks. This setting is typically used when the system
clock is generated by a free-running oscillator on the device-under-test (DUT) board and is,
therefore, asynchronous to TCK. A DUT card simulation model that contains the definition
of the system clocks is generated.
• Off — generates the system clocks. This setting is typically used when the system clocks are
generated by tester channels and are synchronous to TCK.
Default Value
Usage Conditions
The UseAsyncClocks property is used in the following wrappers:
• CustomVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• SerdesVerify
When you specify the UseAsyncClocks property to On, you must specify the clock period of
TCK using the TCKPeriod property.In this case, ETVerify assigns the default value of 100 ns.
When the UseAsyncClocks property is On, ETVerify reads the .tcm file for the clock used by
each controller and checks that the clock period is provided for all clocks used by the
controllers. You can specify additional clock periods using the ClockPeriods wrapper for the
remaining clocks, but if no controller specified in the configuration file uses them, ETVerify
ignores the additional clock periods. The ClockPeriods wrapper works with the
UseAsyncClocks property as follows:

September 2017
UseAsyncClocks
• When you specify the UseAsyncClocks property to On, the test bench generates any clock
used by the controller.
• When you specify the UseAsyncClocks property to Off, the ClockPeriods wrapper is
completely ignored. The single system clock period is specified by the ClockPeriod
property.
Example
This example instructs ETVerify to use asynchronous clocks in the test bench.
etv (MyDesignA) {
CustomVerify (1) {
UseAsyncClocks: On;
}
}
Related Information
ActiveControlCells MembistPVerify
ClockPeriod MembistVerify
ClockPeriods SerdesVerify
CustomVerify TCKRatio
LogicbistVerify TCKPeriod

September 2017
UseChildBisrEmulation
The UseChildBisrEmulation property instructs ETVerify to create behavioral code in the DUT
card simulation model to emulate the behavior of the BISR segments within the child blocks.
Hierarchical forces and observe commands are used to emulate the behavior of the BISR
segments on the port of the child block. This enables you to simulate the BISR operation on the
top level while using empty or scan shell models for the child blocks.
If you want to use the full simulation model for a given block, you can use
+define+Full_<blockName> on the simulator command line to strip out the behavioral code
associated with blockName.
The option also generates behavioral code which analyzes the fuse box content and reports on
the screen what was written to them. You can turn this feature on by specifying
+define+FuseBoxCtrlDebug on the command line of the simulator.
Syntax

• On—specifies to create the behavioral code in the DUT card simulation model
• Off—specifies not to create the behavioral code in the DUT card simulation model.
Default Value
Usage Conditions
• CustomVerify
• MembistPVerify
• MembistVerify
This property is automatically inserted in the correct xxxVerify wrapper when ETVerify creates
the .etEarlyVer and .etSignOff files.
Example
This example instructs ETVerify to create the behavioral emulation model for the child blocks
containing BISR segments.
etv (MyDesignA) {
CustomVerify (1) {
UseChildBisrEmulation: On;
}
}

September 2017
Figure A-22 shows the behavioral code that is created inside the DUT card model to emulate the
behavior of the BISR segments within the child blocks.
Figure A-22. Behavioral Code with Hierarchical forces/compares for Child BISR
Emulation
‘ifdef Full_<blockName>
initial $display(“Full simulation model for <InstancePath>.<BisrSIPort> is needed”);
‘else
//Emulates the BISR SHIFT register
reg [<ChainLength>1:0] SEG#;
always @ (posedge TB.DUT_inst.CHIP.<InstancePath>.<BisrClockPort>
or negedge TB.DUT_inst.CHIP.<InstancePath>.<BisrResetPort> ) begin
if (-TB.DUT_inst.CHIP.<InstancePath>.<BisrResetPort>) begin
SEG# <= <ChainLength>’b0;
end else begin
if ( (TB.DUT_inst.CHIP.<InstancePath>.<BisrScanEnPort> === 1’b1) &
(TB.DUT_inst.CHIP.<InstancePath>.<BisrMemDisPort> === 1’b1) &
((TB.DUT_inst.CHIP.<InstancePath>.<BisrMSelPort> === 1’b0)|
(TB.DUT_inst.CHIP.<InstancePath>.<BisrMSelPort> === 1’b1)) ) begin
SEG# <= {TB.DUT_inst.CHIP.<InstancePath>.<BisrSIPort>,SEG#[<ChainLength>-1:1]};
end else begin
SEG# <= {<ChainLength>{1’bx}};
end
end
end
//Emulates the retiming flop on BISR_SO port
always @ (negedge TB.DUT_inst.CHIP.<InstancePath>.<BisrClockPort>
or negedge TB.DUT_inst.CHIP.<InstancePath>.<BisrResetPort> ) begin
if (-TB.DUT_inst.CHIP.<InstancePath>.<BisrResetPort>) begin
force TB.DUT_inst.CHIP.<InstancePath>.<BisrSOPort> = 1’b0;
end else begin
force TB.DUT_inst.CHIP.<InstancePath>.<BisrSOPort> = SEG#[0];
end
end
‘endif
Related Information
CustomVerify MembistVerify
MembistPVerify

September 2017
UseDUTLoopBacks
UseDUTLoopBacks
The UseDUTLoopBacks property enables you to specify whether or not the generated test
bench performs signal loopbacks in a special DUT card simulation model. You specify these
loopbacks in your ETVerify configuration file.
Syntax

• On — specifies that the generated test bench performs signal loopbacks in the DUT card
simulation model.
• Off — specifies that the generated test bench does not perform signal loopbacks in the DUT
card simulation model.
Default Value
Usage Conditions
The UseDUTLoopBacks property is used for the following types of verification:
• Logic BIST Verification Section
• When the UseDUTLoopBacks property is set to Off, ETVerify ignores the DUTLoopBacks
wrapper.
• When the UseDUTLoopBacks property is set to On, a DUT card simulation model called
<patternName>_DUT.ext is generated in the output directory. ext is .vb for the Verilog and
.vhd for VHDL. This model instantiates the circuit under test and performs loopbacks from
output pins back to input pins as specified in the DUTLoopBacks wrapper in the xxxVerify

September 2017
UseDUTLoopBacks
wrapper. This is only a simulation model and has no effect on the WGL patterns generated.
This emulates loopbacks which exist on the DUT card used on the logic tester.
• When the LoadBoardInfoFile property is specified in the JtagVerify wrapper, it affects the
UseDUTLoopBacks property default value. The default value changes to On.
Example
This example specifies that the generated test bench performs signal loopbacks in the DUT card
simulation model.
etv (MyDesignA) {
UseDUTLoopBacks: On;
}
}
Related Information
CustomVerify MembistPVerify
DUTLoopBacks MembistVerify
LoadBoardInfoFile SerdesVerify
LogicbistVerify WTAPVerify

September 2017
UserBitAlias
UserBitAlias
For TAP UserBits
The UserBitAlias property specifies to ETVerify that a specific logic value will be driven on the
TAP port(s) corresponding to the UserIR or UserDR bit(s) defined by the alias. The
correspondence between the alias and the specific user TAP IR/DR bits should have been
previously defined in the .etassemble configuration file (Refer to UserBitAlias in the manual
ETAssemble Tool Reference).
For WTAP UserBits inside WTAPSettings
The UserBitAlias property, when specified inside a WTAPSettings wrapper, specifies to
ETVerify that a specific logic value will be driven on the WTAP port(s) corresponding to the
UserIR bit(s) defined by the alias.
The correspondence between the alias and the specific user WTAP IR bits should have been
previously defined in the .etassemble configuration file (Refer to UserBitAlias in the manual
ETAssemble Tool Reference.
Syntax

• aliasName — specifies alias names for a single user IR or DR bits or groups of user IR or
DR bits.
• binaryNumber — is a binary number.
Default Value
None

September 2017
UserBitAlias
Usage Conditions
The UserBitAlias property is used for the following types of verification:
Table A-16. UserBitAlias Usage Conditions
Usage Conditions Custom Logic BIST User- WTAP
Verification Verification Section Defined Verification
Section Sequence Section
Memory BIST
Section
TAP Verification
Section
Scan Verification
Section
SerdesTest
You must have defined the ✓ ✓ ✓ ✓
aliases in the .etassemble file.
The UserBitAlias property is ✓
ignored when SVFName is
specified. When SVFName is
specified, TAP settings should
be specified in this SVF file.
This property can be specified ✓
both in the xxxVerify wrapper
and in the TestStep:
WTAPSettings wrapper.
This property can only be ✓
specified in the xxxVerify:
This property can only be ✓
specified in the xxxVerify:
TestStep: WTAPSettings
wrapper.
Example
Having used the following properties in the .etassemble configuration file to insert embedded
test circuits in Core:

September 2017
UserBitAlias
Configuration (unita) {
...
WTAP {
...
NumberUserIrBits: 12;
...
UserBitAlias (bus_width) {
LeftIndex: 0;
RightIndex: 0;
}
UserBitAlias (algoMode) {
LeftIndex: 1;
RightIndex: 1;
}
UserBitAlias (my_wtap_IR_bit_2) {
LeftIndex: 2;
RightIndex: 2;
}
UserBitAlias (boot_strap_mode) {
LeftIndex: 10;
RightIndex: 3;
}
}
}
in the following example, aliases are used to set several WTAP user IR bits to specific values
using easy to remember names.
etv (MyDesignA) {
...
LogibistVerify (MyDesign) {
BurstCyclesWithShiftClock: Yes;
WTAPSettings (DP1){
UserBitAlias (bus_width): 1’b1;
UserBitAlias (algoMode): 1’b1;
}
TestStep (1) {
WTAPSettings (DP1){
UserIRBit(11): On;
UserBitAlias (boot_strap_mode): 8’b10011101;
}
}
TestStep (2) {
WTAPSettings (DP1){
UserIRBit(11): On;
UserBitAlias (boot_strap_mode): 8’hc7;
}
}
}
}

September 2017
UserBitAlias
Related Information
JtagVerify TestStep
IncludeTapInit UserDefinedSequence
LogicbistVerify UserDRBit
MembistPVerify UserIRBit
MembistVerify WTAPSettings
SVFName WTAPVerify
ScanVerify NumberUserBits in the manual ETAssemble
Tool Reference

September 2017
UserDefinedSequence
UserDefinedSequence
The UserDefinedSequence wrapper enables you to define arbitrary initialization sequences to
be used as preamble to your embedded test patterns. The defined UserDefinedSequence are
referenced from any xxxVerify wrapper using the PreTAPUserDefinedSequence,
PostTAPUserDefinedSequence, or PostTestUserDefinedSequence properties.
You use the CustomVerify wrapper to simulate your sequence stand-alone. Once you confirm it
is correctly implemented, you reference it in the other xxxVerify wrappers.
There can be many UserDefinedSequence wrappers to define different arbitrary sequences.
However, each wrapper must have a unique name.
Syntax
Figure A-23 presents the complete syntax for the UserDefinedSequence wrapper.
Figure A-23. UserDefinedSequence Wrapper
//Repeatable
SVFFile: <svfName>;
TestStep(<testStepID>) {//Repeatable
PinSettings{
PinCompares{
<pinName>: 0 | 1 | x;
WTAPSettings(<moduleName>| DP# | BP#){
//Repeatable

September 2017
UserDefinedSequence
Pin: <string>;
PinInv: <string>;
ClockInput(<RE> | new<portName>) {
//Repeatable
Pin: <string>;
PinInv: <string>;
BurstClockController(<pinName>) {
//Repeatable
Pin: <string>;
PinInv: <string>;
Pin: <string>;
PinInv: <string>;
For the UserDefinedSequence wrapper, sequenceName is a unique name for the defined
initialization sequence.
Usage Conditions
UserDefinedSequence can be created using one of the following basic methods:
1. By defining series of TestStep wrappers containing elements such as:
o PinSettings wrappers
o PinCompares wrappers
o UserDRBit properties
2. By referencing an SVF file which contains the required actions using the SVFFile
property
Several examples are provided to guide you through the following operations:
• If you need a sequence which involves manipulating primary input of the chip, then it is
recommended that you create an SVF file with a list of PIO commands describing vector-

September 2017
UserDefinedSequence
by-vector the sequence you want implemented as shown in Example 1 below. You can even
use the procedure documented in “Converting Test Bench Events into PIO Commands” on
page 593 to automatically convert events on pins inside a Verilog test bench into PIO
commands.
• You use the TestStep: UserDRBit (<n>) syntax when you want to set User bits in the
Mentor Graphics TAP as shown in “Example 2” on page 592.
• If you need to load a Master TAP to give control to the Mentor Graphics TAP, you describe
the pattern needed using SIR and SDR commands in an SVF file as shown in “Example 3”
on page 593. Note that a UserDefinedSequence using an SVFFile and referenced by a
PreTAPUserDefinedSequence property in a given xxxVerify wrapper will suppress the
TAP reset that normally happens after the PreTAPUserDefinedSequence has happened.
This is to prevent the TRST from resetting the effect of the actions performed by your
UserDefinedSequence.
Note
You must take care of resetting the Mentor Graphics TAP at the appropriate time when
creating a UserDefinedSequence that uses an SVFFile and is to be referenced by a
PreTAPUserDefinedSequence property as it is assumed the TAP is ready to be used and
parked in the RunTesTIdle state once such PreTAPUserDefinedSequence has
completed.
Before you reference a UserDefineSequence within the various xxxVerify wrappers, you
should simulate it first stand-alone using a CustomVerify wrapper as shown in Example 1 and
“Example 2” on page 592. If you are in a the ETAssemble directory of the lvWorkSpace, and
you are not using LogicTest, the test benches are normally created from the content of the pre-
layout LVDB. This is not very practical when you want to debug a UserDefinedSequence
within a CustomVerify wrapper. To make this easier, you can use the useLVDB Off option
when invoking the make test bench target. This will instruct the makefile to use the local files
instead of the one stored in the LVDB, thus, allowing you to quickly iterate without recreating
the LVDB each time you edit the SVF file or UserDefinedSequence: TestStep wrappers. You
can also set the following environment variable in your shell:
setenv useLVDB Off
However, you must remember to “un-setenv” this variable at the end and redo a complete Sign-
Off verification from the LVDB.
Example 1
This example defines a UserDefineSequence called EnableTAP which simply references an
SVFFile called EnableTAPThroughCPU.svf. The location of the SVFFile is inside a directory
specified with the -svfDir runtime option when the -inputLVDBName option is not specified, or
it is inside the <LVDBName>/SVFFiles when the -inputLVDBName option is specified.
UserDefinedSequence (EnableTAP) {
SVFFile: EnableTAPThroughCPU.svf;
}

September 2017
UserDefinedSequence
The content of the SVFfile is shown below. Notice how the SVF file has two sections —
PIOMAP and PIO commands. Also notice how the pin TRST is asserted low and brought back
high at the bottom of the PIO commands followed by a RUNTEST 3 TCK command. The
RUNTEST TCK command is used to toggle TCK after the end of the reset to bring the TAP state
machine in the RunTestIdle state ready to be used by the test pattern.
PIOMAP (
1 cpuClk
2 cpuRstn
3 cpuData(3)
4 cpuData(2)
5 cpuData(1)
6 cpuData(0)
7 tck
);
!reset the CPUInterface to turn off the CpuData drivers
PIO (LHZZZZH );
PIO (LLZZZZH );
PIO (LHZZZZH );
PIO (LHZZZZH );
!Write all 0s to cpu register 2
PIO (LHHLHLH );
PIO (HHHLHLH );
PIO (LHLLLLH );
PIO (HHLLLLH );
PIO (LHLLLLH );
PIO (HHLLLLH );
PIO (LHLLLLH );
PIO (HHLLLLH );
PIO (LHLLLLH );
PIO (HHLLLLH );
!reset TAP now that the Cpu has release its control on it
PIO (LHLLLLL );
PIO (HHLLLLH );
!toggle TCK to bring TAP into RunTestIdle State
RUNTEST 3 TCK ENDSTATE IDLE;
Example 2
Below is a UserDefinedSequence called PLLX7 that is used to program a PLL multiplication
factor and start it. The PLL is controllable by user bits from the Mentor Graphics TAP, so
programming the PLL is easily achieved using two TestSteps with UserDRBits properties.
UserDefinedSequence (PLLX7) {
TestStep (0) {//Set pllRatio to 7
UserDRBit (0): On;
UserDRBit (1): On;
UserDRBit (2): On;
UserDRBit (3): Off;
UserDRBit (4): Off;
UserDRBit (5): On;
}
TestStep (1){//Turn On PLL
UserDRBit (0): On;
UserDRBit (1): On;
UserDRBit (2): On;

September 2017
UserDefinedSequence
UserDRBit (3): Off;

UserDRBit (4): On;
UserDRBit (5): On;
Pause: 20us;
}
}
Example 3
The following example is used to program a scan path linker in order to give control to the
Mentor Graphics TAP. The Master TAP is reset, then it’s IR is loaded with the OPcode to select
the ScanPath linker then the scan path linker is loaded to give control to the Mentor Graphics
TAP.
This example clearly shows why the Reset of the TAP is omitted after running a
PreTAPUserDefinedSequence with SVF. In this example, the control would be given right
back to the Master TAP if the reset was re-asserted before starting to use the Mentor Graphics
TAP.
PIOMAP (
1 Jtag_tms
2 Jtag_tdi
3 Jtag_trstb
4 Jtag_tck
);
!reset the MAster and Slave TAPs
PIO (LHHL);
PIO (LHLH);
PIO (LHHL);
!Toggle TCK to bring TAP in RunTestIdle
RUNTEST 1 TCK;
!Load Master TAP with Opcode to access ScanPath Linker
SIR 18 TDI (3FFFD) TDO (00000) MASK (00000);
!Load Scan Path Linker to enable TAP 1
SDR 2 TDI (1) TDO (0) MASK (0);
Converting Test Bench Events into PIO Commands

You might have a simulation test bench already working that performs the actions you need to
be done as part of a UserDefineSequence. If this is the case, there is a simple procedure to
follow to cyclize the signal values and convert the pattern into series of PIO SVF commands.
Simulate your test bench normally along with a simple module similar the one shown in
Figure A-24. You need to copy this module into a file and adjust the element (marked in red) to
match your test bench name, your pin list, and your clock period. As the module exists in
Figure A-24, the UserDefineSequence is needed to operate 7 pins during 8-clock cycles to load
a CPU register with a value in order to enable the TAP controller. Notice how cycles is set to 16
in the example. This corresponds to 8 clock cycles because the sampling period is defined as
twice the real clock period in order to sample the clock high and low for each clock cycle.

September 2017
UserDefinedSequence
Figure A-24. Module to Cyclize IO Values during Verilog Simulation
timescale 1ns / 10ps

module SignalStrobe;
real offset = 0.9; // Strobing offset as a fraction of period

real period = 100; // Strobing period in ns, typically, 2*clockPeriod
integer cycles = 16; // Number of strobe to make
integer cycle;
integer fhandle;
initial begin
fhandle = $fopen("Data.strobe");
#(offset*period);
for (cycle = 1; cycle <= cycles; cycle = cycle +1) begin
// Edit the signal list below.
// Replace TB by your test bench module name
// Replace CHIP by the instance of your chip with your test bench
$fdisplay(fhandle,cycle," ",
TB.CHIP.cpuClk, //PIOMAP signal 1
TB.CHIP.cpuRstn, //PIOMAP signal 2
TB.CHIP.cpuData[3],
TB.CHIP.cpuData[2],
TB.CHIP.cpuData[1],
TB.CHIP.cpuData[0],
TB.CHIP.tck); //PIOMAP signal n
#(period);
end
end
endmodule
Running the normal simulation with the extra SignalStrobe module will generate an output file
called Data.Strobe which will look like the content of Figure A-25.
Figure A-25. Data.Stobe File Created by the SignalStrobe Module
1 01xxxx1
2 00zzzz1
3 01zzzz1
4 01zzzz1
5 0110101
6 1110101
7 0100001
8 1100001
9 0100001
10 1100001
11 0100001
12 1100001
13 0100001
14 1100001
15 0100000
16 1100001
With these cyclized vector, you create a PIO commands using the following command

September 2017
UserDefinedSequence
strobe2pio Data.Strobe
You add the PIOMAP() header listing the pins in the same order you listed them in the
SignalStrobe module, and you obtain an SVF file that reproduces your initialization sequence.
The vector list shown in Figure A-24 was used to generate the SVF file example shown in
“Example 1” on page 591. The comments and the final RUNTEST command were inserted
manually.
Note
Just like with the svf2cpu Utility, the strobe2pio utility is a Tcl program that requires you
to have tclsh in your search path. If you do ‘which tclsh’ and it does not find it, then you
must either fix your search path or possibly install a working version of tclsh which you
can download from www.tcl.tk.
Related Information
CustomVerify TestStep
PinSettings UserDRBit
PinCompares svf2cpu Utility
PostTAPUserDefinedSequence -inputLVDBName
PreTAPUserDefinedSequence -svfDir

September 2017
UserDRBit
UserDRBit
For TAP UserDRBits
The UserDRBit (n) property specifies to ETVerify that a logic high (‘1’) or a logic low (‘0’)
will be driven on the TAP port corresponding to the UserDRBit.
Syntax

• n — an integer that specifies a UserDR bit in the TAP’s internal data register.
• On — specifies to ETVerify that a logic high (‘1’) will be driven on the TAP port
corresponding to the UserDR bit.
• Off — specifies to ETVerify that a logic low (‘0’) will be driven on the TAP port
corresponding to the UserDR bit.
Default Value
Usage Conditions
This property is used for the following types of verification:
Table A-17. UserDRBit Usage Conditions

Usage Conditions Custom User- Logic BIST Verification
Verification Defined Section
Section Sequence
Memory BIST Verification
Section
Section
Section
The setting of this property is “sticky” ✓ ✓ ✓
(stays the same) for the rest of the
pattern unless another one (for the
same bit) is present in a subsequent
test step.
The maximum number of user data ✓ ✓ ✓
register (UserDR) bits that you can
specify is 2048.

September 2017
UserDRBit
Table A-17. UserDRBit Usage Conditions

Section Sequence
Section
Section
Section
Setting this property overrides any ✓
assignment contained in the
TapOverrides wrapper in the .designe
file.
When you specify the UserDRBit ✓
(<n>) property within the xxxVerify
wrapper, the specified value of the
user instruction register bit is applied
throughout the test bench or test
pattern set, unless it is overridden in
the TestStep wrapper.
The UserDRBit (<n>) property is ✓
ignored when the SVFName property
is specified.
The UserDRBits (<n>) property is ✓
ignored when the IncludeTapInit
property is set to No.
This property is only meaningful if
you use the NumberUserDRBits
property in the .etassemble file to add
UserIR bits to the WTAP instruction
register. If the value that you assign to
the NumberDRUserBits property is
m, the maximum value that you can
specify is m-1. For example, if
NumberUserBits is 10, ETAssemble
creates UserDRBit (0) through
UserDRBit (9) in the TAP’s user Data
Register.
Example 1
This example specifies that UserDR bit 14 is to be set to logic 1, and the associated port on the
TAP controller is to be held at a value of 1.

September 2017
UserDRBit
TestStep (1) {
UserDRBit (14): On;
}
}
Example 2
This example specifies that UserDR bit 14 is to be set to logic 1.
etv (MyDesignA) {
UserDRBit (14): On;.
}
}
Related Information
IncludeTapInit SVFName
“Overriding UserDRBit Settings” in the LV
Flow User’s Manual

September 2017
UserIRBit
UserIRBit
For TAP UserIRBits
The UserIRBit (n) property specifies to ETVerify that a logic high (‘1’) or a logic low (‘0’) will
be driven on the TAP port corresponding to the UserIRbit.
For WTAP UserIRBits inside WTAPSettings
The UserIRBit (n) property, when specified inside a WTAPSettings wrapper, specifies to
ETVerify that a logic high (‘1’) or a logic low (‘0’) will be driven on the WTAP port
corresponding to the UserIRbit.
Syntax

• n — is an integer that specifies a UserIR bit in the TAP (or WTAP) instruction register.
• On — specifies to ETVerify that a logic high (‘1’) will be driven on the TAP port
corresponding to the UserIR bit.
• Off — specifies to ETVerify that a logic low (‘0’) will be driven on the TAP port
corresponding to the UserIR bit.
Default Value

September 2017
UserIRBit
Usage Conditions
This property is used for the following types of verification:
Table A-18. UserIRBit Usage Conditions

Section Sequence
Section
Section
Section
This property is only meaningful ✓ ✓ ✓
if you use the NumberUserBits
property in the .etassemble file to
add UserIR bits to the TAP
instruction register. If the value
that you assign to the
NumberUserBits property is m,
the maximum value that you can
specify is m-1. For example, if
NumberUserBits is 10,
ETAssemble creates UserIRBit
(0) through UserIRBit (9) in the
TAP’s instruction register.
The UserIRBit property is ✓ ✓ ✓
ignored when SVFName is
specified. When SVFName is
specified, TAP settings should be
specified in this SVF file.
This property can be specified both ✓
in the xxxVerify wrapper and in the
TestStep: WTAPSettings wrapper.
This property can only be specified ✓ ✓
in the xxxVerify: WTAPSettings
wrapper.
This property can only be specified ✓
in the xxxVerify: TestStep:

September 2017
UserIRBit
Related Information
WTAPSettings Summary of Specific Verification Sections
SVFName NumberUserBits in the manual ETAssemble
Tool Reference
“Overriding UserIRBit Settings” in the LV
Flow User’s Manual

September 2017
Variable
Variable
The Variable wrapper specifies variable names with their associated values. Those variables
can be any valid Verilog register names, and their associated values must be a binary or
hexadecimal number with a size matching the size of the variable.
Such variables are useful to parametrize your CPUInterface ReadWriteSetup tasks. For
example, you must map a CPU register address to the CPUInterface of the TAP controller. The
selected address might change from one chip to the next but you might want to reuse the same
Task file for all chips. That is easily accomplished by using a variable to define the used address
of the specific chip. You would define a variable such as CPUInterfaceAddress [7:0] with a
value of 8’h56. Then in your task definition, you simply use CPUInterfaceAddress as the
address to use when accessing the CPU interface of the TAP.
Syntax
Variable {
<VariableName>: <binaryValue>;
}
where these criteria presents the following:

• VariableName — is a valid Verilog register name with or without a bus range.
• binaryValue — is a binary or hexadecimal number matching the size of the variable. Use
<int>’b<digit> to represent binary numbers and <int>’h<digit> to represent hexadecimal
numbers.
Default Value
None
Usage Conditions
This wrapper is used in the CPUVerify: TestStep wrapper.
• You must use valid Verilog register names as variable names.
• If you use the same variable name in more that one TestStep: Variable wrapper, then it
must be specified with equal size in all instances.
Example
This example specifies two variables used in two separate TestSteps. Notice how the size of
CPUInterfaceAddress is 8 bit, and the size of RegAVal is 4 bit in both TestSteps. You would
not be allowed to define the RegAVal[3:0] in one TestStep and RegAVal[2:0] in another.
CPUVerify (Test1) {
TestStep (0) {
Variable {
RegAVal[3:0]: 4’b0100;

September 2017
Variable
TestStep (1) {
Variable {
RegAVal[3:0]: 4’b0110;
}
}
}
Related Information
CPUVerify CPUInterface in the manual ETPlanner Tool
Reference
TestStep The CPU Interface in the manual Embedded
Test Hardware: Reference

September 2017
Waveform
Waveform
The Waveform wrapper allows you to overwrite the default waveform definition used by
ETVerify to generate patterns.
Syntax
Edge1: <0-99>;
Edge2: <1-100>;
}
where the above criteria presents the following:

• waveformName in the Waveform wrapper is a mandatory parameter. The waveforms
supported are as follows:
o DIN0 — for input data pins in TAP BIST verification IO tests.
o DOUT — for output data pins in TAP BIST output tests and memory BIST
diagnostic CMP_STAT pin.
o TDI — is associated with the JTAP TDI input signal.
o TDO — is associated with the JTAP TDO output signal.
o TCK — is associated with the JTAP TCK input signal. This waveform name
specification is allowed, when TCKRatio is greater than one, and the waveform type
is NRZ.
o TCK_IsClkTyp — is associated with the JTAP TCK input signal. This waveform
name specification is allowed, when the TCKRatio is equal to one, and the
waveform type is RONE or RZ.
o TRST — is associated with the JTAP TRST input signal.
• The following waveform Type(s) — waveformType — are supported:
o RONE — indicates that the waveform to use should be a return to 1. This is
generally used for clocks.
o RZ — indicates that the waveform to use should be a return to 0. This is generally
used for clocks.
o STRB — indicates that the waveform to use should be a strobe window. This must be
used for outputs.
o NRZ — indicates that the waveform to use should be non-return to 0. This is
generally used for input signals.
o DNRZ — indicates that the waveform to use should be a delayed non-return to 0.
This is generally used for input signals.

September 2017
Waveform
Usage Conditions
This wrapper is used in the following wrappers:
• CustomVerify
• JtagVerify
• LogicbistVerify
• MembistPVerify
• MembistVerify
• ScanVerify
• SerdesVerify
• WTAPVerify
or at the top level—in the Global Section.
• The Waveform wrapper can be specified in the following ways:
o Globally for all applicable patterns
It is global if placed right under the etv wrapper.
o Locally for a specific pattern
You can override the global value by specifying a new Waveform wrapper under
the xxxVerify wrapper.
• It is mandatory to specify the Edge1 property inside the Waveform wrapper.
• You specify the Edge2 property only when using the waveform type RZ, RONE, and STRB.
• Table A-19 summarizes the conditions under which the Edge1 and Edge2 properties are
specified. Both properties Edge1 and Edge2 must be specified with the waveform RONE,
RZ and STRB. The Edge2 property must not be specified with the waveform type DNRZ and
NRZ. The DNRZ waveform type requires an Edge1 property value greater than 0. The
Edge1, when using the NRZ waveform type, must be set to 0.
Note
As one can see, this feature can be used to slightly alter test pins timing in both the test
bench and the generated patterns. Default pin timing should always work, unless
exceptional circumstances. Incorrect waveform specification might make your output test
bench fail. Use with great care.

September 2017
Waveform
Table A-19. Waveform Type vs. Edge1 and Edge2

Waveform Type Edge1 and Edge2 Usage Conditions
RONE Edge1 = <0-99> , Edge2 = <1-100>
RZ Edge1 = <0-99> , Edge2 = <1-100>
STRB Edge1 = <0-99> , Edge2 = <1-100>
DNRZ Edge1 > 0 , no Edge2
NRZ Edge1 = 0 , no Edge2
• Table A-20 summarizes the waveform types supported for the available waveform names.
Table A-20. Waveform Name vs. Waveform Type

Waveform Name Waveform Types Supported
DIN0 DNRZ, NRZ
DOUT STRB
TRST DNRZ, NRZ
TDI DNRZ, NRZ
TDO STRB
TCK (TCKRatio > 1) NRZ
TCK_IsClkTyp (TCKRatio = 1) RONE, RZ
Example
This example illustrates how to specify waveforms in the etVerify configurations file. In this
example, the TDO waveform is set for SerdesVerify to open at 60% of the tester period and
closes at 70% of the tester period. The global TDO waveform settings to 80% and 90% applies
to all xxxVerify wrappers that do not include Waveform wrapper override properties like the
one in SerdesVerify. As illustrated, the local Waveform wrapper (inside the SerdesVerify
wrapper) overrides the global Waveform wrapper (under the etv wrapper).
etv (TOP) {
Waveform (TDO) {
Type: STRB;
Edge1: 80;
Edge2: 90;
}
SerdesVerify (A) {

September 2017
Waveform
Waveform (TDO) {
Type: STRB;
Edge1: 60;
Edge2: 70;
}
}
LogicbistVerify (ControllerD) {
...
}
}
Related Information
TCKRatio Summary of Specific Verification Sections
Global Section

September 2017
WGL
WGL
The WGL wrapper combines all properties that include tester-related information pertaining to
the WGL format.
Syntax
WGL {
Type: (Generic) | LSI;
ForceBidir: “0”, “1” “X”, “Z”, “-”,
“00”, “10”, “X0”, ”Z0”, ”-0”,
“01”, “11”, “X1”, “Z1”, “-X”,
“0Z”, “1Z“, “XZ“, “ZZ“, “-Z”,
“0-”, “1-”, “X-”, “Z-”, “--”;
}
Usage Conditions
This wrapper is used in the Tester-Related Data Section.
If this wrapper is included into the ETVerify configuration and the Type property is set to LSI,
ETVerify will generate LSI specific TCF (Test Condition file) file, as shown in the example
below:
etv (SOC) {
IncludeAllNonPowerPins: No;
FlattenLoops: None;
MaxLoopCount: 5000;
WGL {
Type: LSI;
}
JtagVerify (1) {
...
}
}
Related Information
ForceDisable Type

September 2017
WTAPSettings
WTAPSettings
The sections below provide detailed information on the following usage of the WTAPSettings
wrapper:
• xxxVerify Usage
• “UserDefinedSequence Usage” on page 610
xxxVerify Usage
The WTAPSettings wrapper specifies settings for a specific WTAP controller.
Syntax
DisableClocks: On | (Off); // Applicable only
// for LogicbistVerify
}

• When there is one instance of the WTAP in the design, moduleName is used to specify the
name of the WTAP controller.
• If there are multiple instances, then the following values are used:
o BP# — when a TAP is present.
o DP# — for Direct Pin Interface when no TAP is present.
Default Value
None
Usage Conditions
These usage conditions apply to the WTAPSettings wrapper:
• This wrapper is used in all types of verification.
• Multiple WTAPSettings wrappers can be used — one per WTAP controller.
Example
In the following example, the UserIRBit (14) is turned on, and UserBitAlias associated with
the name B1_clk_DIS is set to 1.
WTAPSettings (BP0){
UserIRBit(14): On;
UserBitAlias(B1_clk_DIS): 1’b1;
} //end of WTAPSettings wrapper
} //end of WTAPVerify wrapper

September 2017
WTAPSettings
Related Information
LogicbistVerify SerdesVerify
UserDefinedSequence Usage
The WTAPSettings wrapper, when used inside a UserDefinedSequence wrapper, specifies
WTAP settings that are slightly different than those available for all other xxxVerify wrappers.
It is possible to poll values from the WTAP status register (IRStatus) and to enable specific
embedded test controllers (BistEn).
Syntax
Figure A-28 shows the WTAPSettings wrapper in the TestStep: UserDefinedSequence
wrapper.
Figure A-28. UserDefinedSequence Wrapper (WTAP Verification)
WTAPSettings (<moduleName> | DP# | BP#) {
// Repeatable
}
}
}
}
Usage Conditions
This wrapper is used in the UserDefinedSequence: TestStep wrapper.
Related Information
BistEn UserDefinedSequence
IRStatus UserBitAlias
TestStep UserIRBit

September 2017
WTAPVerify
WTAPVerify
The WTAPVerify wrapper introduces wrappers and properties for setting test steps, controller
properties, and test algorithms. These settings vary depending on whether you are using
ETVerify with the Mentor Graphics capabilities logic test or fault insertion.
Syntax
For the complete syntax for the wrapper, refer to the WTAP Verification Section.
Usage Conditions
A separate WTAPVerify wrapper is created for each WTAP by ETVerify when the runtime
option -genConfigFile or -genManufacturingConfigFile is On.
Example
A sample WTAPVerify wrapper appears below.
TestStep (0) {
Controller (BP0) {
RunTest: InstReg;
RunTest: ByPassReg;
RunTest: IDReg;
}
}
}

September 2017
WTAPVerify

September 2017
Appendix B
User-Defined Sequences and Custom
Verification Steps
This section describes how to create custom user-defined sequences for arbitrary initialization
and explains how to test and use them. It also provides sample ETVerify configuration files to
illustrate this feature.
Overview
This application note describes how you can create, test and use user-defined sequences (UDS).
UDS can be either used as a self-contained pattern for third-party test resources or be referenced
in xxxVerify wrappers as an initialization sequence.
This application note describes how to use UDS. Perform the following steps:
• Step 1 — Create the UDS during Step 3 ETAssemble (Early Verification).

This process is described in detail in Creating User-Defined Sequences.
• Step 2 — Verify and debug the stand-alone UDS during Step 3 ETAssemble (Early
Verification).
This process is described in detail in Testing and Using User-Defined Sequences.
• Step 3 — Reference the UDS as an initialization sequence of a controller during Step 3
ETAssemble (Early Verification)
• Step 4 — Reference the UDS that was created and verified during Step 5 Final
ETSignOff in the LV Flow.
Steps 3 and 4 are described in detail in Referencing User-Defined Sequences.
In addition to UDS, the initialization sequence can also come from a pre-existing SVF file. The
process of using an SVF file for initialization goes through the same steps as described above,
except that the creation of the SVF file might happen elsewhere. It is also possible to convert a
UDS to its equivalent SVF file using the ETVerify tool.

September 2017
User-Defined Sequences and Custom Verification Steps
Creating User-Defined Sequences

This section describes how to create user-defined sequences. You use one
UserDefinedSequence wrapper in the .etEarlyVer configuration file for each UDS being
created. This is done during early verification in Step 3 ETAssemble of the LV Flow. The UDS
is stored in a file with .pgsl_uds extension. This file is used when you reference the UDS for
verifying/debugging it and for initialization purposes.
UserDefinedSequence Wrapper
You use the UserDefinedSequence wrapper to define an arbitrary sequence when you want to
create it.There can be more than one UserDefinedSequence wrapper to specify different
arbitrary sequences; however, each wrapper must have a unique name.
Note that only the SVFFile property is allowed to be specified outside the TestStep wrapper.
Figure 1 illustrates complete syntax of the UserDefinedSequence wrapper and its placement
within the ETVerify configuration file.
Figure B-1. UserDefinedSequence Wrapper within ETVerify Configuration File
// Global Properties Section
...
// Tester-related Data Section

...
// Vector Generation Section

...
// User-Defined Sequence Section

UserDefinedSequence (<sequenceName>) {// Repeatable
SVFFile: <svfName>;
PinSettings {
<pinName>: 0 | 1;
} // End of PinSettings sub-wrapper
PinCompares {
<pinName>: 0 | 1;
} //End of PinCompares sub-wrapper
ApplyTCKClockCycles: <tckCycles>;
DRStatus (<index>): 0 | 1;
IRStatus (<index>): 0 | 1;
UserBITAlias(<AliasName>): <binaryNumber>;
UserDRBIT(n): On | (Off);
UserIRBIT(n): On | (Off);
} //End of TestStep wrapper
} //End of UserDefinedSequence wrapper

September 2017
// UDS Verification Section using CustomVerify

CustomVerify {
...
}
// Other Verification Sections

xxxVerify {
...
}
} //End of etv wrapper
UDS Output Files

As was mentioned above the UDS is stored in a file with .pgsl_uds extension. Each UDS is
stored in a separate file. The directory where this file is created depends on the value of
-userDefinedSequenceDir, -outDir, and -inputLVDBName runtime options as follows:
• When the ETVerify runtime option -inputLVDBName is specified,

<inputLVDBName>/UserDefinedSequences/<sequenceName>.pgsl_uds is created.
Values for -outDir and
-userDefinedSequenceDir are ignored for this purpose.
• When the ETVerify runtime option -inputLVDBName is NOT specified, but
-userDefinedSequenceDir is specified,
<userDefinedSequenceDir>/<sequenceName>.pgsl_uds is created.
• Otherwise, the output goes to
<outDir>/UserDefinedSequences/<sequenceName>.pgsl_uds. If -outDir is not
explicitly specified, <outDir> defaults to the current working directory.
SVF File Locations

When the SVFFile property is specified, ETVerify looks for the following SVF files:
• <svfDir>/<svfID>.svf when the ETVerify runtime option -inputLVDBName is not

specified. If -svfDir is not explicitly specified, <svfDir> defaults to the current working
directory.
• <inputLVDBName>/SVFFiles/<svfID>.svf when the ETVerify runtime option
-inputLVDBName is specified.
When the LVDB is created, all SVF files in the directory that the -svfDir runtime option points
to are copied into the SVFFiles directory inside the LVDB directory.
When an SVF file is used in PreTAPUserDefinedSequence, it is assumed that the TAP

controller has been reset in the SVF. Therefore, after the SVF sequence is applied, you must
ensure that the Mentor Graphics TAP controller is placed in the Run Test Idle state.

September 2017
SVFFile Property
You use the SVFFile property to specify one or more file names of pre-existing SVF sequences
that will be included within this pattern.
The SVF files may or may not be generated by the LV Flow. However, only the following SVF
commands are supported: PIOMAP, PIO, SIR, SDR, and RUNTEST.
The Mentor Graphics SVF parser also supports the following two commands/pragmas. Because
both pragmas start with a comment character, third-party SVF parsers will treat them as
comments.
• !LV TDO_SYMBOL — Identifies the register associated with a failing bit that helps in
debugging.
• !LV TDO_SAMPLE — Monitors results in the SVF flow. Bits labelled as TDO_SAMPLE
contain special data and are not compared during scan-out.
The following syntax specifies these new commands:
!LV TDO_SYMBOL [<index_range>] <register_name> [<register_size>];

!LV TDO_SAMPLE [<index_range>] <register_name> [<register_size>];
where:
<index_ranges> := <index_range> {, <index_range>}

<index_range> :::= <integer>: <integer>
• Text in boldface denotes keywords and required syntax punctuations.

• One space must be between !LV and TDO_SYMBOL and between !LV and TDO_SAMPLE.
• If a failing bit has an associated symbol, the symbol name is reported along with the
failure. Otherwise, failures of an instruction register are reported as IR#, and failures of a
data register are reported as DR#, where # is the failing bit of the instruction or data
register being scanned out. For example:
!LV TDO_SYMBOL [0:4,15:11] IR_STATUS[10];
If bit 1 fails during an SIR operation, ETVerify reports IR_STATUS[1] as the failing bit.
However, if bit 5 fails, ETVerify reports IR5 as the failing bit.
• The syntax in the following example shows that bits 34 through 41 are treated as special
data bits signifying an error count. These bits are not compared against an expected
value.
!LV TDO_SAMPLE [34:41] SVF_BP1_ERROR_CNT[8];

September 2017
Sequence of Operations Within UDS

The actions associated with the properties within a given TestStep wrapper occur in the exact
order listed below irrespective of the order in which they are specified in the configuration file.
However, when a UDS comprises more than one TestStep the order in which the TestSteps are
specified in the configuration file is maintained in the actual initialization sequence:
1. SVF commands from the SVFFile property are applied.

2. PinSettings and PinCompares are applied. These PinSettings and PinCompares
remain active until changed by PinSettings and PinCompares in a subsequent
TestStep.
3. IRStatus are followed by the UserIRBit settings. Note that UserBitAlias mapped to
UserIRBits are applied at the same time as the other UserIRBits.
4. DRStatus are followed by the UserDRBit settings. Note that UserBitAlias mapped to
UserDRBits are applied at the same time as the other UserDRBits.
5. Pause or InitialWaitCycles, whichever is larger, is applied.
6. ApplyTCKClockCycles is applied.
For detailed descriptions of the properties used in the TestStep wrapper of the
UserDefinedSequence wrapper.
Example (Step 1)
Figure B-2 presents an example of the UserDefinedSequence wrapper to illustrate how UDS is
created. Suppose your design has some internal compliance enable logic, a PLL and a memory
BIST controller. The compliance enable must be turned on before the TAP is reset and the PLL
must be locked before the controller could be tested. First, you will create a UDS to turn on the
compliance enable and another UDS to lock the PLL, once verified and debugged the UDS can
be then used while testing the memory BIST controller.
Figure B-2. A Sample TOP.etEarlyVer Configuration File for Creating UDS
etv (TOP) {
// Global Properties
...
// Sequence to turn on the compliance enable

UserDefinedSequence (ACCESS_LV_TAP) {
TestStep (1) {
PinSettings {
EN_CE[0]: 0;
EN_CE[1]: 0;
}
}

September 2017
TestStep (2) {
PinSettings {
EN_CE[0]: 0;
EN_CE[1]: 1;
}
}
}
// Sequence to make the PLL lock
UserDefinedSequence (LOCK_PLL) {
TestStep (1) {
PinSettings {
D[4]: 0;
D[5]: 0;
}
}
TestStep (2) {
PinCompares {
Q[5]: 0;
}
}
TestStep (3) {
PinCompares {
Q[5]: X;
}
PinSettings {
D[4]: 1;
D[5]: 0;
}
DRStatus (0): 0;
UserIRBit (3): On;
UserDRBit (3): Off;
IRStatus (6): 0;
}
TestStep (4) {
PinSettings {
D[4]: 1;
D[5]: 1;
}
UserDRBit (3): On;
UserIRBit (5): On;
}
TestStep (5) {
PinCompares {
Q[5]: 1;
}
DRStatus(0): 1;
DRStatus(1): 1;
IRStatus(6): 1;
}
TestStep(6) {
PinCompares {
Q[5]: X;

September 2017
Testing and Using User-Defined Sequences
}
}
} // UserDefinedSequence
// Sequence to turn off the compliance enable
UserDefinedSequence (DIASABLE_LV_TAP) {
TestStep (1) {
PinSettings {
EN_CE[0]: 0;
EN_CE[1]: 0;
}
}
}
// Other wrappers
} // etv
The configuration file shown above defines three UDS called ACCESS_LV_TAP, LOCK_PLL
and DISABLE_LV_TAP. ACCESS_LV_TAP has two TestSteps, LOCK_PLL has six TestSteps
and DISABLE_LV_TAP has 1 TestStep. Each TestStep does certain things needed for the LV
TAP to be accessible and for the PLL to lock. In order to create the .pgsl_uds file containing this
initialization sequence, you use the following runtime options on the command line:
etv TOP \
-verificationFlow EarlyVer \
-outDir outDir \
-select “UserDefinedSequence(*)”
If you are using lvWorkspace, you will use the following command:
make testbench \
cmdOptions=”-select UserDefinedSequence(*)”
This creates the files called ACCESS_LV_TAP.pgsl_uds, LOCK_PLL.pgsl_uds and
DISABLE_LV_TAP.pgsl_uds in the
outDir/UserDefinedSequences directory. These are binary files in Tessent internal file format.
The next step is to verify the UDS and debug it, if needed. It is described in the next section.

This section describes how to verify your user-defined sequences that were created in the
previous step, using the CustomVerify wrapper of the ETVerify configuration file. The
CustomVerify wrapper can be used to perform the following operations:
• Create a test bench in Verilog or VHDL to verify UDS through simulation.

• Create an equivalent SVF file that can be used wherever this sequence is needed.
• Create a stand-alone pattern in SVF, WGL, FTDL, or TSTL2 that can be used on a tester
for exercising third-party test resources.
The Custom Verification Section of the ETVerify configuration file consists of one or more
CustomVerify wrappers. For detailed descriptions of the contents of this wrapper, refer to the
ETVerify input files sections of your reference manual.

September 2017
Figure B-3 illustrates the Custom Verification Section within the structure of the ETVerify
configuration file.
Figure B-3. Custom Verification in the ETVerify Configuration File Structure
//Global Property Section
.
.
.
.
//Vector Generation Section
LogicTestVectors {
.
.
}
UserDefinedSequence (<sequenceName>) {//Repeatable
.
.//Set of sub-wrappers and properties
.
}
//Custom Verification Section
CustomVerify (<name>) {//Repeatable
.
.//Set of sub-wrappers and properties
.
//Specific Verification Section(s)

xxxVerify (<name>) {
.
.//Set of wrappers and properties
.
} // End of xxxVerify wrapper
CustomVerify Wrapper
You can use multiple CustomVerify wrappers; however, each wrapper must have a unique
name—each wrapper generates a test bench and/or test vector file of its own.
Note that Figure B-4 summarizes all properties and wrapper within the CustomVerify wrapper
that are used under different scenarios. Only a few of them are actually used for verifying and
debugging the user-defined sequences.

September 2017
Figure B-4. Complete Syntax of the CustomVerify Wrapper
CustomVerify (<name>) {//Repeatable
ClockPeriods {
.
.
}
PinSettings {
<pinName>: 0 | 1;
PinCompares {
<pinName>: 0 | 1;
UserBitAlias(<AliasName>): <binaryNumber>;
TCKRatio: 1 | 4 | 8 | 16 | 32 | 64 | 128;
PreTapUserDefinedSequence: <sequenceName>;
PostTapUserDefinedSequence: <sequenceName>;
IncludeTapInit: (Yes) | No;
UseSysClocks: (On) | Off;
DUTLoopBacks {
.
.
}
TestClockSource: TCK | (System) |
System_2 | System_4 | SystemPLL |
SystemPLL_2 | SystemPLL_4 | Test;
UDS File Locations

When the PreTAPUserDefinedSequence, PostTAPUserDefinedSequence, and/or
PostTestUserDefinedSequence property is specified, ETVerify looks for the following UDS
files:


September 2017

PreTap, PostTap, and PostTest UserDefinedSequence

Properties
You use the PreTAPUserDefinedSequence, PostTAPUserDefinedSequence, and/or
PostTestUserDefinedSequence property to specify the name of the user-defined sequence to be
included in this pattern. The UDS name must correspond to sequenceName of a
UserDefinedSequence wrapper in the current configuration file or to the name of a user-defined
sequence that already exists.
If you want a UDS pattern to be applied before the TAP is accessed you use the
PreTapUserDefinedSequence property that points to a .pgsl_uds file that only performs
PinSettings, PinCompares, Pause, and ApplyTCKClockCycles.
A .pgsl_uds file used by the PostTAPUserDefinedSequence property will be applied after the
TAP has been reset.
A .pgsl_uds file used by the PostTestUserDefinedSequence property will be applied at the very
end of the pattern.
Positive and Negative Clocks

You use the DefineClock (P|N) property to specify pins on your design you want to be driven
with a clock. Use this property for each clock you want to define. You must use the
DefineClock (N) property immediately after its corresponding positive clock to define the
negative pin of a differential clock pair. Note that the specified pin must be an input or inout
port.
This example illustrates how to define as a single ended clock on port CLKA and a differential
clock on the pair of pins CLKBP and CLKBN.
etv (MyDesignA) {
.
.
.
CustomVerify (1) {
DefineClock (P): CLKA;
DefineClock (P): CLKBP;
DefineClock (N): CLKBN;
}
}

September 2017
Example Continued (Step 2)

In the previous section, you created three UDS called ACCESS_LV_TAP.pgsl_uds,
LOCK_PLL.pgsl_uds and DISABLE_LV_TAP.pgsl_uds. These UDS need to be verified by
simulation first. To do that you will add a CustomVerify wrapper to the configuration file as
shown in Figure B-5.
Figure B-5. Sample Configuration File (TOP.etEarlyVer) for Verifying UDS
etv (TOP) {
...

< Same as in Figure 2. >

UserDefinedSequence (DISABLE_LV_TAP) {
// Section to verify ACCESS_LV_TAP, LOCK_PLL and DISABLE_LV_TAP UDS

CustomVerify (TEST_UDS) {
PatternName : TEST_UDS;
DefineClock(P) : D[0];
DefineClock(P) : CLKD[1];
DefineClock(N) : CLKD[0];
DefineClock(P) : CLK1;
DefineClock(P) : CLK2;
PreTapUserDefinedSequence : ACCESS_LV_TAP;
PostTapUserDefinedSequence : LOCK_PLL;
PostTestUserDefinedSequence : DISABLE_LV_TAP;
}
// Other wrappers

The configuration file shown above has a CustomVerify wrapper that refers to UDS you have
created. To generate a test bench you use the following ETVerify runtime options on the
command line:
etv TOP \
-outDir outDir \
-verilog On \
-select “customVerify(TEST_UDS)”
If you are using lvWorkSpace, you will use the following command:

September 2017
Referencing User-Defined Sequences
make testbench \
cmdOptions=”-select CustomVerify(TEST_UDS)”
The above commands will create a Verilog test bench outDir/TEST_UDS.v, which you will
simulate to be make sure the UDS works as desired.
If there are any problems, you go back to Step1 to generate a modified UDS and then back to
Step 2 for verifying it. Once you are satisfied with it, it is ready to be used along with other
controllers and test structures. In this example, you will use it with a memory BIST controller.
This operation is described in the next section.

Once UDS have been created and verified, it is ready to be used along with other controllers and
test structures. UDS can be referenced in all xxxVerify wrappers, and only one
PreTAPUserDefinedSequence, PostTAPUserDefinedSequence, and/or
PostTestUserDefinedSequence property can be specified in any wrapper at a time.
You already saw how to reference a UDS from a CustomVerify wrapper when you wanted to
created a test bench for verifying it in the previous section. It is referenced the same way from
other wrappers as well. The directory where ETVerify looks for the corresponding .pgsl_uds
file is described in UDS File Locations.
Any UDS that is going to be used during Step 5 Final ETSignOff should be first used and
verified during early verification phase. The exact same UDS should be used during sign-off,
and no new UDS should be created at that time.

Let us continue with the example to illustrate how a UDS is used while verifying an embedded
test controller. The modified configuration file is shown in Figure B-6.
Figure B-6. Sample Configuration File (TOP.etEarlyVer) for Referencing UDS
etv (TOP) {
...



September 2017
UserDefinedSequence (DISABLE_LV_TAP) {
// Section to verify ACCESS_LV_TAP, LOCK_PLL and DISABLE_LV_TAP UDS
CustomVerify (TEST_UDS) {
}
// Use ACCESS_LV_TAP and LOCK_PLL for initialization before testing

this
// memory BIST controller and use DISABLE_LV_TAP to finalize the
pattern.
MembistVerify (UDS_MBIST_GoNoGo) {
PatternName : MBIST_GoNoGo_CLKD;
TestClockSource : SystemPLL; // CLKD
ClockPeriod : 40ns;
TckRatio : 16;
TestStep (1) {
Controller (BP1) {
ReducedAddressCount : Off;
Diagnostic : Off;
CompareGoID : On;
}
}
// Other wrappers
In the configuration file shown above, the ACCESS_LV_TAP, UDS is being used to initialize
the chip so that the LV TAP can be accessed, and the LOCK_PLL UDS is being used to perform
the initialization before the memory BIST controller, BP1, is started. Finally, the
DISABLE_LV_TAP.pgsl is applied at the end of the pattern to disable the LV TAP. To generate
a simulation test bench in Verilog, you will use the following ETVerify runtime options on the
command line:
etv TOP \
-outDir outDir \
-verilog On \
-select “MembistVerify(UDS_MBIST_GoNoGo)”
If you are using lvWorkspace, you will use the following command:
make testbench \
cmdOptions= \

September 2017
”-select MembistVerify(UDS_MBIST_GoNoGo)”
The above commands create a Verilog test bench outDir/MBIST_GoNoGo_CLKD.v. It uses the
initialization sequence from outDir/UserDefinedSequences/ACCESS_LV_TAP.pgsl_uds
immediately and it uses outDir/UserDefinedSequences/LOCK_PLL.pgsl_uds before TestStep 1
and outDir/UserDefinedSequences/DISABLE_LV_TAP.pgsl_uds is used after TestStep 1
completes.
When you get to Step 5 Final ETSignOff in the LV Flow, you create LVDB before generating
any test benches or test vector datasets. All UDS and SVF files created during early verification
must become part of the LVDB. To do that, you will use the following command:
etv TOP \
-createLVDB On \
-outputLVDBName ../../TOP.lvdb \
-userDefinedSequenceDir \
../topVerify/outDir/UserDefinedSequences \
-svfDir ../topVerify/SVFFiles \
-log outDir/etv.log_CreateLVDB
If you are using lvWorkspace, you will simply do the following:
make lvdb
The above commands will create ../../TOP.lvdb. All UDS files will get copied to ../../TOP.lvdb/
UserDefinedSequences and all SVF files will go to ../../TOP.lvdb/SVFFiles.
In order to reference the UDS in Step 5 Final ETSignOff, you will modify the .etSignOff and
.etManufacturing configuration files appropriately and then create simulation test benches and
production test vector subsets.

The configuration file shown below illustrates how you can create a test bench for verifying a
memory BIST controller that references UDS created during early verification. It is similar to
the configuration file shown in Figure B-7.
Figure B-7. Sample Sign-Off Configuration File (TOP.etSignOff) for Using UDS
etv (TOP) {
// Global properties
// No UserDefinedSequence wrappers here.
// A memBist controller using ACCESS_LV_TAP, LOCK_PLL and

DISABLE_LV_TAP
MembistPVerify (TOP_P1) {
PatternName :
membistv_P1_TOP;
SimulationScript :
TOP_sim.script;

September 2017
ClockPeriod : 100ns;
TckRatio : 16;
TestStep (ReducedAddress) {
Controller (BP1) {
ReducedAddressCount : On;
Diagnostic : Off;
}
}
} // MembistPVerify
// Other wrappers
} // etv
To generate a Verilog simulation test bench you will use the following command:
etv TOP \
-configFile TOP.etSignOff \
-inputLVDBName ../../TOP.lvdb \
-verilog On \
-outDir outDir \
-select “MembistPVerify(TOP_P1)”
If you are using lvWorkSpace you will use the following command in the topVerify_sigOff
directory:
make testbench \
cmdOptions= \
“-select MembistVerify(TOP_P1)”
“-select MembistVerify(TOP_P1)”
The above commands create a Verilog test bench
outDir/membistv_P1_TOP.v that use the initialization sequence from
../../TOP.lvdb/UserDefinedSequences/ACCESS_LV_TAP.pgsl_uds and
../../TOP.lvdb/UserDefinedSequences/LOCK_PLL.pgsl_uds and the finalization sequence from
../../TOP.lvdb/UserDefinedSequences/DISABLE_LV_TAP.pgsl_uds. These are the same UDS
that were created during early verification and then copied to LVDB.
Similarly, you can create production patterns by modifying the .etManufacturing file
appropriately. A sample configuration file is shown in Figure B-8.
Figure B-8. Sample Manufacturing Configuration File (TOP.etManufacturing)

Using UDS
etv (TOP) {
IncludeAllNonPowerPins : No;
IncludeAllPowerPins : No;
FlattenLoops : None;
WGL {
Type : Generic;
}

September 2017
// No UserDefinedSequence wrappers here.

MembistVerify (1) {
PatternName : membistv_1;
ClockPeriod : 100ns;
TckRatio : 16;
ETATestGroupName : membistVerify;
Controller (BP1) {
CompareGoID : On;
}
}
}
// Other wrappers
} // etv
To generate WGL vectors for testing the memory BIST controller, you will use the following
command:
etv TOP \
-configFile TOP.etManufacturing \
-outDir manufacturing_patterns \
-wgl On \
-log outDir/etv.log_patterns \
-select “membistVerify(1)”
If you are using lvWorkSpace, you will use the following command:
make patterns \
cmdOptions=”-select membistVerify(1)”
The above commands will create production patterns in WGL format and store them in
manufacturing_patterns/membistv_1.wgl. This pattern will use the initialization sequence from
../../TOP.lvdb/UserDefinedSequences/ACCESS_LV_TAP.pgsl_uds,
../../TOP.lvdb/UserDefinedSequences/LOCK_PLL.pgsl_uds and the finalization sequence from
../../TOP.lvdb/UserDefinedSequences/DISABLE_LV_TAP.pgsl_uds.

September 2017
Appendix C
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Mentor Support Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
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.

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

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

ETVerifyReference PDF

Uploaded by

Copyright:

Available Formats

ETVerifyReference PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ETVerifyReference PDF

Uploaded by

Copyright:

Available Formats

ETVerify Tool Reference

Software Version 2017.3

© 2009-2017 Mentor Graphics Corporation

Mentor Graphics Corporation

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

ETVerify Tool Reference, v2017.3 3

4 ETVerify Tool Reference, v2017.3

ETVerify Tool Reference, v2017.3 5

6 ETVerify Tool Reference, v2017.3

ETVerify Tool Reference, v2017.3 7

8 ETVerify Tool Reference, v2017.3

ETVerify Tool Reference, v2017.3 9

10 ETVerify Tool Reference, v2017.3

End-User License Agreement

ETVerify Tool Reference, v2017.3 11

Figure 3-1. The ETVerify Startup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

12 ETVerify Tool Reference, v2017.3

Figure A-18. Example etVerify Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503

ETVerify Tool Reference, v2017.3 13

Table 11-1. ETVerify Output Files in Step 3: ETAssemble/Early Verification . . . . . . . . . . 153

14 ETVerify Tool Reference, v2017.3

This preface covers the following topics:

ETVerify Tool Reference, v2017.3 15

The manual contents comprise the following chapters and appendices:

16 ETVerify Tool Reference, v2017.3

• Angle brackets, < >

ETVerify Tool Reference, v2017.3 17

Command Line and Property Options

• Properties — Yes / No. For example:

18 ETVerify Tool Reference, v2017.3

• x — is an integer that identifies the number of bits in value.

• This first sample syntax corresponds to 1.

• The syntax below corresponds to 1010 or hex A.

• Finally, the following syntax corresponds to 0101111.

where the preceding variables represent the following:

ETVerify Tool Reference, v2017.3 19

All input files support this syntax.

• All identifiers must begin with a letter.

Port (\lalala) {...

20 ETVerify Tool Reference, v2017.3

Special Characters in File Names

ETVerify Tool Reference, v2017.3 21

22 ETVerify Tool Reference, v2017.3

ETVerify Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

ETVerify Input Files

ETVerify Tool Reference, v2017.3 23

ETVerify Configuration Files

Tessent MemoryBIST Algorithm File

.controller StepAlgo Selection File

24 ETVerify Tool Reference, v2017.3

Optional Physical Constraints File

BSDL-Only Flow Third-Party Files

ETVerify Tool Reference, v2017.3 25

26 ETVerify Tool Reference, v2017.3

Chapter topics follow this sequence:

ETVerify Startup File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

ETVerify Startup File Syntax

Figure 3-1. The ETVerify Startup File

The next section provides detailed description of the ClockPeriodswrapper.