Et Assemble Reference

SIEMENS EDA
ETAssemble Tool
Reference
Software Version 2021.2 and Later
Unpublished work. © 2021 Siemens
This material contains trade secrets or otherwise confidential information owned by Siemens Industry Software, Inc.,
its subsidiaries or its affiliates (collectively, "Siemens"), or its licensors. Access to and use of this information is
strictly limited as set forth in Customer's applicable agreement with Siemens. This material may not be copied,
distributed, or otherwise disclosed outside of Customer's facilities without the express written permission of
Siemens, and may not be used in any way not expressly authorized by Siemens.
This document is for information and instruction purposes. Siemens reserves the right to make changes in
specifications and other information contained in this publication without prior notice, and the reader should, in all
cases, consult Siemens to determine whether any changes have been made. Siemens disclaims all warranties with
respect to this document including, without limitation, the implied warranties of merchantability, fitness for a
particular purpose, and non-infringement of intellectual property.
The terms and conditions governing the sale and licensing of Siemens products are set forth in written agreements
between Siemens and its customers. Siemens' End User License Agreement may be viewed at:
www.plm.automation.siemens.com/global/en/legal/online-terms/index.html.
No representation or other affirmation of fact contained in this publication shall be deemed to be a warranty or give
rise to any liability of Siemens whatsoever.
TRADEMARKS: The trademarks, logos, and service marks ("Marks") used herein are the property of Siemens or
other parties. No one is permitted to use these Marks without the prior written consent of Siemens or the owner of
the Marks, as applicable. The use herein of third party Marks is not an attempt to indicate Siemens as a source of a
product, but is intended to indicate a product from, or associated with, a particular third party. A list of Siemens'
trademarks may be viewed at: www.plm.automation.siemens.com/global/en/legal/trademarks.html. The registered
trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the
mark on a world-wide basis.
Support Center: support.sw.siemens.com

Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form
Table of Contents
Chapter 1
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Character Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Command Line and Property Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
BitsValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Bus Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Special Characters in File Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Chapter 2
Summary of ETAssemble Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
ETAssemble Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
.lvbscan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
.etassemble Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Memory Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Design Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Pad Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Cell Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Pin Order List File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
.lvlib File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 3
.etassemble Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
.etassemble Configuration File Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
.etassemble Syntax (-flow EBScan) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
.etassemble Syntax (-flow chip | block) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Sample .etassemble Starter Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Reference for ETAssemble Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
ACGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
ACMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
ACModeSel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
AllowedAuxiliaryPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
ATPGParallelGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
AuxiliaryTestPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
AuxIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
AuxInPortList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
AuxOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
AuxOutPortList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ETAssemble Tool Reference, v2021.2 and Later 3

Table of Contents
BlockedAuxiliaryPins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
BondingOption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
BoundaryScan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
BurstEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Bypass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
BypassedBGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
CaptureDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
CDLaunchAligned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
CDScanEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
ChainOrdering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ChildPowerDomainGroupMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
ComponentCompliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
CompStatPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ConnectionStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ConstantConnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
ConstantLogic0Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
ConstantLogic1Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
CreateScalarPortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
CustomObject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
CustomObject (ConnectLogicHighToPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
CustomObject (ConnectLogicLowToPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
CustomObject (ConnectNetToPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
CustomObject (ConnectPortToPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
CustomObject (CreateInputPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
CustomObject (CreateOutputPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
CustomObject (DisconnectPort). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
CustomObject (Gate1Connect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
CustomObject (Gate1InterceptDestination) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
CustomObject (Gate1InterceptSource) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
CustomObject (Gate2Connect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
CustomObject (Gate2InterceptSource) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
CustomObject (InterceptTopLevelPort). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
CustomObject (ModuleInstantiate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
CustomObject (MoveConnection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
CustomObject (Mux2Connect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
CustomObject (Mux2InterceptDestination) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
CustomObject (Mux2InterceptSource) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
CustomObject (PortToPortConnect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
DecodeSource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
DedicatedBGroupName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
DefaultBSDLUserIRbitCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
DeviceIdCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
DICellMapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4 ETAssemble Tool Reference, v2021.2 and Later

Table of Contents
DirectScanEnablePin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
DisableChildBisrChains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
EmbeddedBScanPortNaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
EnableBCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
EnableSignal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
ExplicitAuxPortConnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
ExplicitCompStatConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
ExplicitCompStatConnectionStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
ExternalAuxInPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
ExternalAuxOutPins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
ExtScanPortNaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
ExternalFuseBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
EXTESTPulseMinDuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
EXTESTTrainExecution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
FeedThroughMux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
FeedThroughs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
ForceExternalLTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
FuseBoxAccessPipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
FuseBoxAddressBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
FuseBoxInterfaceResetPresent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
FuseBoxProgrammingMethod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
FuseBoxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
FuseBoxWriteDuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
IddqEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
InjectTCKOnClockSources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
InsertAfterPin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
InsertBeforePin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
InstanceName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
InstancePath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
InternalAuxInPins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
InternalAuxOutPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
InternalBScanCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
InternalBScanSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
LocalAuxInPinList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
LocalAuxOutPinList. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
LogicTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
LowerBlockModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
ManufacturersIdCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
MaximumTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
MaxBisrChainLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
MaxFuseBoxProgrammingSessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
MaxScanChainSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
MaxTCKFreq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
MaxWRCKFreq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
MemBISR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
NumberBistPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
NumberOfInternalScanChains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
NumberOfPeripheryScanChains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
NumberUpdateGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Table of Contents
NumberUserBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
NumberUserDRBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
NumberUserIRBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
OutputsPerEnableCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
PadIOPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
PowerDomainGroupPriority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Private. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
RegisterAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
RepairWordSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
ResetTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
RevisionCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
SafeValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
SampleOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
ScanChain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
ScanConcatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
ScanEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
ScanIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
ScanOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
SetResetTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
SetTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
SJOMuxPresent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
ShiftPhase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Sides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
SubClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
TAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
TCMGenClockSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
TestFlopReset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
TestMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
TestPortConnections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
TestPointEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
TestPortNaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
TestReceiverInitClkPinAssert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Train . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
UnusedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
UseLocalAuxPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
UserBitAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
UserBitAliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
UserDefinedTestPointMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
UserInstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
UserSignal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
WTAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
ZeroCounterBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Table of Contents
Chapter 4
Memory Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Reference for Memory Library File Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
MemoryTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
AddressCounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
ATD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
BistOrTMActive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
BitGrouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
BusRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CellName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
ColumnSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
ColumnSegmentCountRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
ColumnSegmentRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
ConcurrentRead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
ConcurrentWrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
CountRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
DataOutHoldWithInactiveReadEnable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
DataOutStage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
DisableDuringScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
EmbeddedTestLogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Fuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
FuseMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
FuseSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
GroupWriteEnableMap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
InternalScanLogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
LogicalAddressMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
LogicalPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
LogicalPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
LogicLow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
MemoryHoldWithInactiveSelect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
MemoryType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
MilliWattsPerMegaHertz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
MinHold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
NotAllocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
NumberOfBits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
NumberOfSpareElements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
NumberOfWords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
ObservationLogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
OperationSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
PhysicalAddressMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
PhysicalDataMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
PinMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
PipelineDepth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Table of Contents
Polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
ReadOutOfRangeOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
RedundancyAnalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
RepairEnable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
RetentionTimeMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Retimed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
ROMContentsFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
RowSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
RowSegmentRange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
RowSegmentCountRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
SafeValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
SegmentAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
ShadowRead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
ShadowWrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
ShadowWriteOK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
ShiftedIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
ShiftedIORange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
SpareElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
TestInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
TestOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
TransparentMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Chapter 5
.lvbscan Input File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Complete Syntax for the .lvbscan File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
AC_HP_Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
AC_HP_onChip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
AC_LP_Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
ACCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
ACSelectCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
ACMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
ACModeSel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
ACSignal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
AuxIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
AuxOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
BSDLInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
BScanCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
BScanSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
BScanShiftIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
BScanShiftInRetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
BScanShiftOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
CellInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
ClockBscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
ControlCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
DifferentialType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
DisableResult . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
DisableValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Table of Contents
ForceDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
FromPad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
InitClk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
InitClkPolarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
PinInv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
SafeValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
SelectJTagInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
SelectJTagOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
ShiftBScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
ShiftBScan2Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
UpdateBscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Chapter 6
Pad Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Pad Library Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
ACTiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
BlibCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
DefaultBcells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
PadAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
PadLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Chapter 7
Cell Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Cell Library Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
AND2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
CellLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
CellsToUseOnFunctionalClockPaths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
ClockAnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
ClockBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
ClockGatingANDCell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
ClockGatingORCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
ClockInverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
ClockMultiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
ClockOr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
LogicalLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

Table of Contents
Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Or2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
RetimingFlop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
SynchronizerCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
UpdateGroupDelayElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Chapter 8
Pin Order Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Pin Order List Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
PinName Column Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
PinNumber Column Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
PinType Column Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Sides Column Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Chapter 9
ETAssemble Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
ETAssemble Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
-arch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
-CADEnvFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
-cellLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
-clockGatingScanModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
-config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
-define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
-defineFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
-embeddedTestSpecification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
-etDefFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
-extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
-f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
-f_sv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
-flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
-fvScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
-genPinTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
-genTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
-hdleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
-HDLwarningFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
-ICTechFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
-incDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
-lvlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
-macroSynthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
-mfcu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
-modifiedExtension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
-outDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
-padLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
-pinOrderInfoFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Table of Contents
-pinOrderList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
-pragma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
-r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
-rtlExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
-stopMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
-structuralExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
-timingscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
-userLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
-y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
-yvhdl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Language Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Chapter 10
Output Files for ETAssemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Summary of Output Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Output Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Design Summary File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Boundary Scan Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
TAP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Logic Test Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Memory BIST Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Diagnostic Interface File (DIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
WTAP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
TimingGen Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
fvGenerate Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Appendix A
Adding a User Data Register to the Boundary-Scan Chain . . . . . . . . . . . . . . . . . . . . . . . . 491
Background and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Index
Third-Party Information

Table of Contents

List of Figures
Figure 3-1. Syntax of .etassemble Configuration File for EBScan Flow (-flow EBScan) . . 28
Figure 3-2. Syntax of .etassemble Configuration File for Normal LV Flow (-flow chip | block)
29
Figure 3-3. Sample ETAssemble Starter Template for Top Level . . . . . . . . . . . . . . . . . . . . 35
Figure 3-4. Sample ETAssemble Starter Template for Block or Core Level . . . . . . . . . . . . 35
Figure 3-5. Sample ETAssemble Starter Template for EBScan Flow
(-genTemplate On). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 3-6. Flow With Multiple Bonding Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 3-7. Bonding Option package1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 3-8. Bonding Option package2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 3-9. Sample BoundaryScan Wrapper in the .etassemble File . . . . . . . . . . . . . . . . . . 62
Figure 3-10. Syntax Summary of the Connections wrapper . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 3-11. Example Connections Between TAP Controller and Core Modules . . . . . . . . 83
Figure 3-12. Syntax for TAP Controller Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 3-13. Example Chip With a TAP Having a CPUInterface Connected to a CPU Block 85
Figure 3-14. TAP Connections of CPUInterface and User Data Bits . . . . . . . . . . . . . . . . . . 85
Figure 3-15. Internal Boundary-Scan Cell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Figure 3-16. Internal Bscan Cell Without a SJO Mux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 3-17. TAP Wrapper Syntax in the User-Configuration File . . . . . . . . . . . . . . . . . . . 203
Figure 4-1. Memory Library File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Figure 4-2. Memory Property Section Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Figure 4-3. Single Port Memory With BitSlice=2 and StrobingFlop Registers . . . . . . . . . . 255
Figure 4-4. PhysicalDataMap Wrapper for an 8-Bit-Wide Memory. . . . . . . . . . . . . . . . . . . 299
Figure 4-5. PhysicalDataMap Wrappers for a 4-Bit-Wide Memory . . . . . . . . . . . . . . . . . . . 299
Figure 4-6. Memory With 2 Stages of Built-In Pipelining on the Output Data . . . . . . . . . . 302
Figure 4-7. Port Wrapper Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Figure 4-8. ROM Contents File in Hexadecimal Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Figure 4-9. ROM Contents File in Binary Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Figure 5-1. Syntax for .lvbscan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Figure 6-1. Syntax Summary of the Pad Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Figure 6-2. Example Connections and Function Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Figure 7-1. Syntax Summary of the Cell Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Figure 7-2. Dedicated Isolation Cells Automatically Moved Inside Power Isolation Cells by
ETAssemble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Figure 7-3. Scan Control Signal Source Automatically Moved Inside Power Isolation Cells by
scanGenerate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Figure 7-4. ClockAnd Cell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Figure 7-5. ClockBuffer Cell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Figure 7-6. ClockGatingANDCell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Figure 7-7. ClockGatingORCell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

List of Figures
Figure 7-8. ClockInverter Cell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Figure 7-9. Clock Multiplexer Cell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Figure 7-10. ClockOr Cell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Figure 7-11. SynchronizerCell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Figure 8-1. Sample Pin Order List File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Figure 8-2. Sample Pin Order List File Showing Direction Specifications. . . . . . . . . . . . . . 440
Figure 9-1. Generated File When Using -genTemplate On. . . . . . . . . . . . . . . . . . . . . . . . . . 459
Figure 10-1. DataForPhysicalRegion Wrapper Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Figure 10-2. BistPort Wrapper Syntax for a LogicTest Controller . . . . . . . . . . . . . . . . . . . . 481
Figure 10-3. BistPort Wrapper Syntax for a Memory BIST Controller . . . . . . . . . . . . . . . . 481
Figure 10-4. Example of Diagnostic Interface File (DIF) Syntax . . . . . . . . . . . . . . . . . . . . . 486

List of Tables
Table 3-1. Properties in the Connections Wrapper in the TAP Wrapper . . . . . . . . . . . . . . . 77

Table 3-2. Descriptions of Valid Connections in the WTAP Wrapper . . . . . . . . . . . . . . . . 86
Table 3-3. EmbeddedBScanPortNaming Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Table 3-4. Examples of PinName Regular Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Table 3-5. TestPortNaming Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Table 4-1. Port Function Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Table 4-2. Port Function Value Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Table 4-3. Operator Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Table 6-1. Valid Values for the Attribute Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Table 6-2. Pad Cell Class Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Table 6-3. Pad Cell Subclass Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Table 6-4. Available Subclasses for Each Pad Cell Class . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Table 6-5. Pre-Defined Function Types in the Pin Wrapper . . . . . . . . . . . . . . . . . . . . . . . . 391
Table 7-1. Valid portFunction Values for the Port property in Different Cell-Type Wrappers
424
Table 10-1. LV Flow Output Files for Memory BIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Table 10-2. ETAssemble WTAP-Related Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

List of Tables

Chapter 1
About This Manual
The Siemens EDA LV Flow tool set 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; and interconnects and memories at the board level. The LV Flow tool also generates a
complete IEEE 1149.1 test access port (TAP) and boundary-scan implementation, as well as
timing-robust scan.
This manual describes the input files, runtime options, and output files for the ETAssemble®
tool that is part of the LV Flow.
For the complete list of Tessent-specific terms, refer to the Tessent Glossary.
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
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.
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, { }
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
About This Manual
Character Formatting
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.
• 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.
About This Manual
Command Line and Property Options
• 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
• 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, Siemens EDA LV tools pad the left bits with
logic 0s.
About This Manual
Bus Ranges
Caution
Do not specify a value of 1 outside the range specified by x. If you do, the 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.
• 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.
About This Manual
Identifiers
• 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])
/*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.*/
About This Manual
Special Characters in File Names
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”;
Chapter 2
Summary of ETAssemble Input Files
This chapter summarizes the required and optional input files for the ETAssemble tool.
ETAssemble Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
ETAssemble Input Files
ETAssemble Input Files

Multiple files can serve as input to the ETAssemble tool as described in this chapter:
.lvbscan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
.etassemble Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Memory Library File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Design Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Pad Library File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Cell Library File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Pin Order List File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
.lvlib File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
.lvbscan File
These optional .lvbscan files describe pad-boundary scan combo cells. They are automatically
found using the Verilog and VHDL file search path as long as they have the .lvbscan extension.
Therefore, it is recommended to place your .lvbscan files in the same directory where the netlist
description of the boundary-scan cell is also found.
The .lvbscan file is normally pre-created by ETAssemble when running with -flow EBScan. It
can also be pre-generated by hand to document a pad-boundary scan combo cell you have
created manually.
For detailed information about this file, see “.lvbscan Input File.”
.etassemble Configuration File

The .etassemble configuration file specifies configuration data for boundary-scan chains, the
TAP controller, the WTAP controller, memory BIST controller, and the logicTest controller.
For detailed information about this file, see “.etassemble Configuration File.”
Memory Library File

Every memory that you intend to test in your design must be described in a memory template.
Multiple instances of the same memory should use the same memory template. You can create a
separate memory library file for each memory template or group as many memory templates as
you want into the same memory library file.
For more information, see “Memory Library File.”
Design Netlist
Design Netlist
The required design netlist consists of a Verilog or VHDL description of the design complete
with I/O cells. It is assumed that the design netlist is a completely functioning circuit to which
ETAssemble adds embedded test features without affecting the functional behavior of the chip.
Pad Library File

This required input file contains models for the I/O cells in your design.
For detailed information about this file, see “Pad Library.”
Cell Library File

This required input file contains models for the various library cells that can be used with the
RTL generated by ETAssemble or when inserting logic in your design.
For detailed information about this file, see “Cell Library File.”
Pin Order List File

The optional pin order list file, .pinorder, contains the pin-specific information for the top-level
design. This information is used by ETAssemble to create boundary-scan chains and a valid
BSDL file. If you do not provide a .pinorder file, ETAssemble automatically generates a default
file with data extracted from your design netlist.
For detailed information about this file, see “Pin Order Input File.”
.lvlib File
For VHDL designs, you need to create lvlib file containing a VHDL logical library (for VHDL
designs only).
Refer to lvlib VHDL Library Description for detailed information.
.lvlib File
Chapter 3
This chapter describes in detail the wrappers and properties available for the .etassemble
configuration files in alphabetical order.
.etassemble Configuration File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
.etassemble Configuration File Structure
.etassemble Configuration File Structure

Based on the information extracted when ETChecker was run on your design, the .etassemble
configuration file starter template is created by ETPlanner. Typically, this configuration file
does not need to be edited, but in some cases, adjustments can be required. Edit this file to make
required changes and to produce the .etassemble configuration file.
The .etassemble configuration file serves as input to ETAssemble and instructs the tool on how
you want the embedded test capabilities configured and integrated into your design.
ETAssemble can generate and/or integrate the customized configuration of the TAP controller
and boundary scan.
The contents of the .etassemble configuration file depend on the flow you are running
ETAssemble in. The following figures summarize syntax of the .etassemble configuration file
for these flows:
• Figure 3-1: Complete syntax of .etassemble when running ETAssemble in -flow

EBScan.
• Figure 3-2: Complete syntax of .etassemble when running ETAssemble in -flow chip |
block.
.etassemble Syntax (-flow EBScan) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
.etassemble Syntax (-flow chip | block) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Sample .etassemble Starter Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Reference for ETAssemble Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
.etassemble Syntax (-flow EBScan)

Figure 3-1. Syntax of .etassemble Configuration File for EBScan Flow (-flow
EBScan)
Configuration (top)
BoundaryScan {
PadIOPins: <pinList>;
// You must list the pins on the block that must
// be asserted Low or High for the PAd buffers to
// operate correctly. Those VSS and VDD pins as
// well as configuration signals connected to
// Pad buffers.
ConstantLogic0Inputs: VCC, Ten3[2:1], Ten4[2]a;
ConstantLogic1Inputs: VDD1, Ten3[2:1], Ten4[2]a;
.etassemble Syntax (-flow chip | block)
ACMode {
TestReceiverInitClkPinAssert: (RisingEdge)|
FallingEdge | Logic0 | Logic1;
ACGroup (<groupName>) {
Pins { <list of pin names>; } } }
Overrides { <pin>: option (option1, option2,...optionN);
}
MaxScanChainSize: <int>;
EmbeddedBScanPortNaming {
ForceDisable: <ForceDisable>;
ClockBscan: <ClockBscan>;
UpdateBscan: <UpdateBscan>;
ShiftBscan: <ShiftBscan>;
ShiftBscan2Edge: <ShiftBscan2Edge>;
SelectJtagInput: <SelectJtagInput>;
SelectJtagOutput: <SelectJtagOutput>;
BscanSelect: <BscanSelect>;
BscanShiftIn: <BScanSI>;
BscanShiftOut: <BScanSO>;
ExternalAuxOut: <AuxOut>;
ExternalAuxOutEn: <AuxOutEn>;
ExternalAuxIn: <AuxIn>;
ExternalAuxInEn: <AuxInEn>;
InitClk: <InitClk>;
ACSignal: <ACSignal>;
ACMode: <ACMode>;
ACModeSel: <ACModeSel>;
}//End of EmbeddeBScanPortNaming
InternalAuxInPins: <Input/InoutPinName> \
[, <Input/InoutPinName>,...];
InternalAuxOutPins:<Output/InoutPinName> \
[, <output/InoutPinName>,...];
ExternalAuxInPins:<Input/InoutPinName> \
ExternalAuxOutPins:<Output/InoutPinName> \
[, <Output/InoutPinName>,...];
ConstantLogic0Inputs: vcc, Ten3[2:1], Ten4[2]a;

ConstantLogic1Inputs: vdd, Ten1, Ten2, Ten3[0],Ten4[1];
}//End of BoundaryScan
}//End of Configuration

Figure 3-2. Syntax of .etassemble Configuration File for Normal LV Flow (-flow
chip | block)
Configuration (top) {
CompStatPort: <pin>;
AllowedAuxiliaryPins: <pin>, <pin>,...;
BlockedAuxiliaryPins: <pin>, <pin>,...;
CreateScalarPortsOnly: Yes | (No);
ExplicitCompStatConnection: <pin>;
ExplicitCompStatConnectionStatus: <pin>;
LocalAuxInPinList: <Input/InoutPinName> \
LocalAuxOutPinList: <Output/InoutPinName> \
UseLocalAuxPins: On | Off;
LogicTest {
AuxInPortList: <pin>, <pin>,...;
AuxOutPortList: <pin>, <pin>,...;
NumberOfInternalScanChains: <int>;
NumberOfPeripheryScanChains: <int>;
DirectScanEnablePin (<polarity>): <pin>;
ForceExternalLTest {
<clockLabel>: Yes | No;
}
DICellMapping {
<pin1>: <instancePath1>;
...
<pinN>: <instancePathN>;
}
}
ExplicitAuxPortConnections {
ConnectionStatus { //Only required when TCMGen is used
AuxIn(#) : <pin>;
AuxOut(#) : <pin>;
AuxEn : <pin>;
}
AuxIn(#) : <pin>;
AuxOut(#) : <pin>;
AuxEn : <pin>;
}
UserDefinedTestPointMapping {
<PortOrInternalPinOrNet1>: <hierarchicalPathName1>;
...
<PortOrInternalPinOrNetN>: <hierarchicalPathNameN>;
}
}//End of LogicTest
LowerBlockModule (<moduleName>) {
InstancePath (<instanceRelativeToRootModule>){ ExplicitAuxPortConnections
{
AuxIn(#) : <pin>;
AuxOut(#) : <pin>;
AuxEn : <pin>;
}
AuxInPortList: <pin>, <pin>,...; AuxOutPortList: <pin>, <pin>,...;
ATPGParallelGroup: <string>;
}
}//End of LowerBlockModule
BoundaryScan {
NumberUpdateGroups: <int>;
OutputsPerEnableCell: <int>;
EnableSignal (<string>): <pin>;
Overrides {
<pin>: option (option1, option2,...optionN);
}
Sides {
<instanceName1>: <pin1>;
<instanceName2>: <pin2>;
...
<instanceNameN>: <pinN>;
}
AuxIn {
<pin>:<pin>,<internalPin>,...;
}
AuxOut {
<outputPinName>:
<corePort1>,<controlPort2>,...;
}
EnableBCell {
Name: <blibname>;
Ports {//Repeatable
<portName>;
}
}
InternalBScanCells {
Cell(<cellName>) {// repeatable
InsertBeforePin: <pinName>;
SafeValue: 0 | 1 | (X);
Connection: <hierachicalPath>;
SJOMuxPresent: Off | (On);
SampleOnly: (Off) | On;
}
}
InternalBScanSegment (<instancePath>) { // repeatable
InsertAfterPin: <pinName>;
DedicatedBGroupName: <BGroupName>;
}
ACMode {
EXTESTPulseMinDuration: <real number>;
EXTESTTrainExecution {
Train: <integer>;
MaximumTime: <real number>;
}
Pins {
<list of pin names>;
}
}
}
BondingOption (<BondingOptionName>) { //repeatable
UnusedPins: <TopLevelPin>,<TopLevelPin>,...;
DeviceIdCode: 16’b<deviceId> | (16’h<deviceId>);
RevisionCode: 4’b<revId> | (4’h<revId>);

BypassedBGroups: <BGroupName>,<BGroupName>,...;
EnableSignal: <InternalNet>;
}
}//End of BoundaryScan
TAP {
InstanceName: <instanceName>;
ComponentCompliance: (2001) | 1993;
DefaultBSDLUserIRbitCode: <x>;
DeviceIdCode: <binaryNumber>;
ManufacturersIdCode: <binaryNumber>;
MaxTCKFreq: x;
NumberBistPorts: x;
NumberUserBits: x;
NumberUserDRBits: x;
RevisionCode: <binaryNumber>;
InjectTCKOnClockSources: All |
(TopMemBistClocks) | None;
Connections {
<ConnectionsProperties>
}
ScanConcatenation {
ScanEnable: <InputPortName>;
Select: <NetName>;
Clock: <InputPortName>;
ScanChain {
SI: <ScanInPort>;
S0: <ScanOutPort>;
}
}
UserInstruction (<instructionName>){
<Properties>
}
UserBitAliases {
<UserBitAliases>
}
UserSignal (<TAPportName>) {
<UserSignalProperties>
}
TestPortConnections {
TCK : <hierarchicalOutputPortName>;
TMS : <hierarchicalOutputPortName>;
TRST : <hierarchicalOutputPortName>;
TDI : <hierarchicalOutputPortName>;
TDO : <hierarchicalInputPortName>;
TDO_EN(1|0): <hierarchicalInputPortName>;
}
}//End of TAP
TCMGenClockSource(<subModuleInstancePathName.clockPortName>) {
ReferencePin: <currentModuleClockPortName>;
ReferencePinInv: <currentModuleClockPortNameInv>;
FreqRatio: <int>;
} //End of TCMGenClockSource
WTAP { Bypass: Yes | No; DeviceIdCode: <number>; ManufacturersIdCode:

<number>; RevisionCode: <number>; InstanceName: <instanceName>;
MaxWRCKFreq: x; NumberBistPorts: x; NumberUserIRBits: x;
InjectTCKOnClockSources: Always |
(InternalSourceOnly) | Never;
Connections{
<WTAP_port1>: <connection1>;
}
AuxiliaryTestPort {
OutputPort: <HierarchicalPath>;
InputPort: <HierarchicalPath>;
EnablePort: <HierarchicalPath>;
InternalNets {//Repeatable
Input: <HierarchicalPath>;
Output: <HierarchicalPath>;
Enable: <HierarchicalPath>;
}
}
UserBitAlias (<aliasName>) {
LeftIndex: x;
RightIndex: x;
}
}//End of WTAP
MemBISR {
Connections {
BisrDone: <Port>;
BisrGo: <Port>;
FunctionalRepairClockLabel: <Label>;
FunctionalRepairEnable: <Port>;
FuseBoxAccess: <Port>;
FuseBoxAddress: <Port>;
FuseBoxBufferTransfer: <Port>;
FuseBoxClock: <Port>;
FuseBoxDone: <Port>;
FuseBoxInterfaceReset : <Port>;
FuseBoxSelect: <Port>;
FuseBoxValue: <Port>;
FuseBoxWrite: <Port>;
PowerDomainGroupBusy (<int>) : <Net|Port>;
PowerDomainGroupDone (<int>) : <Net|Port>;
PowerDomainGroupEnable (<int>): <Net|Port>;
PowerDomainGroupReset (<int>) : <Net|Port>;
ProgrammingVoltagePin: <Port>;
WriteDurationCounter: <Port>;
}
ChainOrdering: <listOfInstances>;
ChildPowerDomainGroupMapping {
}
DisableChildBisrChains: <listOfInstances>;
ExternalFuseBox: Yes | (No);
FuseBoxAccessPipeline: (On) | Off;
FuseBoxAddressBits: <size>;
FuseBoxInterfaceResetPresent: Yes | (No); //Yes is inferred when
FuseBoxInterfaceReset is specified and
ExternalFuseBox is Yes
FuseBoxProgrammingMethod: (Unbuffered) | Buffered;
FuseBoxSize: <size>;
FuseBoxWriteDuration: <time>;
MaxFuseBoxProgrammingSessions: <int>;
PowerDomainGroupPriority: <string>;
RepairWordSize: <int>;
MaxBisrChainLength: <int>;
ZeroCounterBits: <int>;
}//End of MemMISR
TestPortNaming {
WRSTN: <corePortName>;
WRCK: <corePortName>;
WSI: <corePortName>;
WSO: <corePortName>;
UpdateWR: <corePortName>;
ShiftWR: <corePortName>;
CaptureWR: <corePortName>;
SelectWIR: <corePortName>;
EnableWR: <corePortName>;
AuxOut: <corePortName>;
AuxIn: <corePortName>;
AuxEn: <corePortName>;
TestClockPort (<oldPortName>): <newPortName>;
TestClockPortFreqUnificationSuffix:
<suffixToTestClockPortName>; //Defaults to _extF
ETClockEnable: <ETClockEnablePortName>;
BISR_SI: <corePortName>;
BISR_SO: <corePortName>;
BISR_CLOCK: <corePortName>;
BISR_SCAN_ENABLE: <corePortName>;
BISR_CLEAR: <corePortName>;
BISR_SELECT: <corePortName>;
BISR_MEM_DISABLE: <corePortName>;
BISR_GO: <corePortName>;
BISR_DONE: <corePortName>;
}//End of TestPortNaming
ExtScanPortNaming {
TestMode: <string>;
CaptureDisable: <string>;
CDLaunchAligned: <string>;
CDScanEnable: <string>;
ScanIn: <string>;
ScanOut: <string>;
ShiftPhase: <string>;
BurstEnable: <string>;
TestFlopReset: <string>;
ResetTest: <string>;
SetTest: <string>;
SetResetTest: <string>;
IddqEnable: <string>;
TestPointEnable: <string>;
}//End of ExtScanPortNaming
CustomObject (<objectName>) {
Var(VariableName): <value>;
}//End of CustomObject
FeedThroughs {
<inPins> : <outPins>;
}//End of FeedThroughs
Sample .etassemble Starter Templates
FeedThroughMux:(<PO>): <PI_in>, <PI_en>[, <PI_in>. <PI_en>]*;

} //End of Configuration

The following figures illustrate sample starter templates created by ETPlanner for the
following:
• Figure 3-3 — for top level
• Figure 3-4 — for block or core level
• Figure 3-5 — for the EBScan (Embedded Boundary Scan) flow when using -
genTemplate On.
Note that these figures do not list all available properties in the starter template.
The following legend applies to these examples:
• Properties in brown are written out only if they were specified in the .etplan file.
• Properties in orange are inferred by ETPlanner when top-level pins are non-scan-
testable.
Figure 3-3. Sample ETAssemble Starter Template for Top Level
Top.etassemble File
Configuration (TOP) {
CompStatPort: xxx;
AllowedAuxiliaryPins: <pin>, <pin>,...;
BlockedAuxiliaryPins: <pin>, <pin>,...;
BoundaryScan {
Overrides {
Y[0]: Subclass(H);
// All pins that are declared as non-jtag are for
// non-scan-testable pins.
*: Option(NJTAG);
}
}
TAP {
DeviceIdCode: 16'hx;
RevisionCode: 4'hx;
ManufacturersIdCode: 11'hx;
ComponentCompliance: 1993;
Connections {
}
}
}
Figure 3-4. Sample ETAssemble Starter Template for Block or Core Level
Block/Core flow.etassemble File

Configuration (COREA) {
CompStatPort: xxx;
AllowedAuxiliaryPins: <pin>,<pin>,...;
BlockedAuxiliaryPins: <pin>,<pin>,...;
WTAP {
DeviceIdCode: 16'hx;
RevisionCode: 4'hx;
ManufacturersIdCode: 11'hx;
Connections {
}
}
}
Figure 3-5. Sample ETAssemble Starter Template for EBScan Flow

(-genTemplate On)
EBScan flow.etassemble File

Configuration (MyBScanCell) {
BoundaryScan {
/* You must list the pins on the block that are connected to the
PadIO/FromIO/toIO pins of pad cells.
Pins not listed here will be assumed to be internal pins that
are not interfacing with the device boundary.
You will get warning if a pin not listed here is seen to be
connected to a PadIO/FromIO/toIO pin of pad cells.
The order of the pin list is used as the order of the boundary
scan segments.
Bussed pins can be listed with a range.
Example:gioa[4],gioa[8:5],gioa[0].
PadIOPins:<PinList>;
/* Use this property to define optional options such as
SampleOnly, NJTAG, etc. */
Overrides{
// <pin>: options;
}
// <FunctionName>: <pinName>;
ForceDisable: ForceDisable;
ClockBscan: ClockBScan;
UpdateBScan: UpdateBScan;
ShiftBScan: ShiftBScan;
ShiftBScan2Edge: ShiftBScan2Edge;
SelectJtagInput: SelectJtagInput;
SelectJtagOutput: SelectJtagOutput;
BscanSelect: BscanSelect;
BscanShiftIn: BscanShiftIn;
BscanShiftOutn: BscanShiftOut;
InitClk: InitClk;
ACSignal: ACSignal;
ACMode: ACMode;
ExternalAuxOut: ExternalAuxOut;
ExternalAuxOutEn: ExternalAuxOutEn;
ExternalAuxIn: ExternalAuxIn;
ExternalAuxInEn: ExternalAuxInEn;
}
/* Use this property to list pins you want to equip with AuxIn
logic.
Use InternalAuxInPins if you are inserting a boundary-scan
segment within a block or an ELTCore module, and you want
to connect your MultiChains through pad cells found within
this module.
Use ExternalAuxInPins if you are inserting a boundary-scan
segment within a soft module which you will reuse later as
a pad/bscan combo cell to be used as an AuxIn pin */
InternalAuxInPins: <InputPinName> [<InputPinName>, ...];
ExternalAuxInPins: <InputPinName> [<InputPinName>, ...];
/* Use this property to list pins you want to equip with
AuxOut logic.
Use InternalAuxOutPins if you are inserting a boundary-scan
segment within a block or an ELTCore module, and you want
to connect your CompStat and/or your MultiChains through
pad cells found within this module.
Use ExternalAuxOutPins if you are inserting a boundary-scan
segment within a soft module which you will reuse later as

a pad/bscan combo cell to be used as an AuxOut pin */
InternalAuxOutPins:<OutputPinName> [<OutputPinName>, ...];
ExternalAuxInPins: <OutputPinName> [<OutputPinName>, ...];
}
}
Reference for ETAssemble Syntax

The following sections provide detailed descriptions for all available wrappers and properties of
the ETAssemble configuration file in alphabetic order.
ACGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
ACMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
ACModeSel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
AllowedAuxiliaryPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
ATPGParallelGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
AuxiliaryTestPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
AuxIn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
AuxInPortList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
AuxOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
AuxOutPortList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
BlockedAuxiliaryPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
BondingOption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
BoundaryScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
BurstEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
BypassedBGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
CaptureDisable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
CDLaunchAligned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
CDScanEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
ChainOrdering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ChildPowerDomainGroupMapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
ComponentCompliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
CompStatPort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ConnectionStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ConstantConnections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
ConstantLogic0Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
ConstantLogic1Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
CreateScalarPortsOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
CustomObject. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
CustomObject (ConnectLogicHighToPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
CustomObject (ConnectLogicLowToPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
CustomObject (ConnectNetToPort). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
CustomObject (ConnectPortToPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
CustomObject (CreateInputPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
CustomObject (CreateOutputPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
CustomObject (DisconnectPort). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
CustomObject (Gate1Connect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
CustomObject (Gate1InterceptSource) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
CustomObject (Gate2Connect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
CustomObject (Gate2InterceptSource) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
CustomObject (InterceptTopLevelPort) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
CustomObject (ModuleInstantiate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
CustomObject (MoveConnection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
CustomObject (Mux2Connect). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
CustomObject (Mux2InterceptDestination) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
CustomObject (Mux2InterceptSource) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
CustomObject (PortToPortConnect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
DecodeSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
DedicatedBGroupName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
DefaultBSDLUserIRbitCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
DeviceIdCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
DICellMapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
DirectScanEnablePin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
DisableChildBisrChains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
EmbeddedBScanPortNaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
EnableBCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
EnableSignal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
ExplicitAuxPortConnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
ExplicitCompStatConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
ExplicitCompStatConnectionStatus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
ExternalAuxInPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
ExternalAuxOutPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
ExtScanPortNaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
ExternalFuseBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
EXTESTPulseMinDuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
EXTESTTrainExecution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
FeedThroughMux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
FeedThroughs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
ForceExternalLTest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
FuseBoxAccessPipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
FuseBoxAddressBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
FuseBoxInterfaceResetPresent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
FuseBoxProgrammingMethod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
FuseBoxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
FuseBoxWriteDuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
IddqEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
InjectTCKOnClockSources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
InsertAfterPin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
InsertBeforePin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
InstanceName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
InstancePath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
InternalAuxInPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
InternalAuxOutPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
InternalBScanCells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
InternalBScanSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
LocalAuxInPinList. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
LocalAuxOutPinList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
LogicTest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
LowerBlockModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
ManufacturersIdCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
MaximumTime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
MaxBisrChainLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
MaxFuseBoxProgrammingSessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
MaxScanChainSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
MaxTCKFreq. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
MaxWRCKFreq. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
MemBISR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
NumberBistPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
NumberOfInternalScanChains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
NumberOfPeripheryScanChains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
NumberUpdateGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
NumberUserBits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
NumberUserDRBits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
NumberUserIRBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
OutputsPerEnableCell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
PadIOPins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
PowerDomainGroupPriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Private . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
RegisterAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
RepairWordSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
ResetTest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
RevisionCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
SafeValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
SampleOnly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
ScanChain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
ScanConcatenation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
ScanEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
ScanIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
ScanOut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
SetResetTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
SetTest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
SJOMuxPresent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
ShiftPhase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Sides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
SubClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
TCMGenClockSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
TestFlopReset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
TestMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
TestPortConnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
TestPointEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
TestPortNaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
TestReceiverInitClkPinAssert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Train . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
UnusedPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
UseLocalAuxPins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
UserBitAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
UserBitAliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
UserDefinedTestPointMapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
UserInstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
UserSignal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
WTAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
ZeroCounterBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
ACGroup
The ACGroup wrapper specifies AC grouping. AC grouping enables the AC mode on a selected
subset of your design’s AC-mode output pins while one of the two AC EXTEST instructions is
in effect. Each AC group has one internal boundary-scan cell—the ACSelect cell—which
supplies a gated version of the ACMode signal to all AC-mode output boundary-scan cells in
that group. The specified groupName is used for naming the ACselect cell and its connecting
nets in the output netlist.
Syntax
The following syntax specifies this wrapper:
ACMode {
Pins {
<List of Pin Names>;
}
}
}
Default Value
None
Usage Conditions
The ACGroup wrapper is used in the BoundaryScan: ACMode wrapper.
AC grouping does not occur when the ACMode wrapper is not present in the .etassemble file or
when the ACGroup wrapper is not specified. In this case, all AC output pins are controlled by
the non-gated global ACMode signal.
One ACGroup wrapper can override the grouping specified by any previous wrapper of this
type located in the ACMode wrapper.
Example
The following example illustrates two ACGroup wrappers in the ACMode wrapper.
ACMode {
ACGroup(BUS_A) {
Pins {
BUS_A[63:0];
}
}
ACGroup (Control) {
Pins {
AEN;
BEN;
AC_CONT*;
}
}
}
ACMode
The ACMode wrapper enables you to specify the following:
• Timing data specific to the execution of the EXTEST_PULSE and EXTEST_TRAIN

instructions.
• AC grouping of the AC-mode of output or inout pins.
Syntax
BoundaryScan {
ACMode {
Train: <integer>;
}
Pins {
<list of pin names>;
}
}
}
}
Default Value
None
Usage Conditions
The ACMode wrapper is used in the BoundaryScan wrapper.
Example
The following example shows the ACMode wrapper:
ACMode {
Train: 4;
MaximumTime: 1.0e-3;
}
AcGroup(BUS_A) {
Pins {
BUS_A[63:0];
}
}
ACGroup (Control) {
Pins {
AEN;
BEN;
AC_CONT*;
}
}
}
ACModeSel
The ACModeSel property defines the pin name that enables the pad’s ACSignal input to invert
the output data of a dot6-compliant output or bidirectional pad. During ACMode operation, this
inversion occurs during the RunTestIdle state when both ACSignal and ACModeSel pad pins
are asserted high. The ACModeSel pin normally connects to the output of a dot6 ACSelect cell,
which exists in your design only if you specify an ACGroup wrapper in your ETAssemble
configuration file.
See “Differential Output Pad Example” in the Support for IEEE 1149.6 Boundary Scan
document. For more information about ACSelect cells and their interactions with dot6 pads, see
the IEEE 1149.6 standard.
Syntax
The following syntax specifies this property:
where ACModeSel is the name of the pin on the BScanCell.
Usage Conditions
This property is used in the BScanCell wrapper.
Example
The following example defines the pin myACModeSel on cell module MyCell:
BScanCell (MyCell) {
ACModeSel: myACModeSel;
}
AllowedAuxiliaryPins
The AllowedAuxiliaryPins property defines top-level pins that can be used as auxiliary scan
pins.
Syntax
AllowedAuxiliaryPins: <pin>, <pin>, <pin>...;
where pin is a top-level pin.
buses and scalared numbers can be specified in the short notation as shown below:
AllowedAuxiliaryPins: A,B[4:2],C%[1:0];
is equivalent of:
AllowedAuxiliaryPins: A,B[4],B[3],B[2],C[1],C[0];
Default Value
None
Usage Conditions
Use this property if you want to identify specific pins that could be Auxiliary pins.
This property cannot be specified together with the BlockedAuxiliaryPins property.
Example
The following example designates allowed auxiliary pins:
AllowedAuxiliaryPins: DIN[0], DIN[1], DOUT[4]...;
ATPGParallelGroup
The ATPGParallelGroup property identifies the ELT cores with Embedded Deterministic Test
(EDT) that you want to apply ATPG patterns in parallel. With EDT, you can apply ATPG
patterns to an ELT core with a few scan channels. To save test time, the ATPG patterns must be
run on multiple cores in parallel. When ELT cores share the same ATPGParallelGroup label,
ETAssemble will not share the Auxiliary ScanIn/ScanOut pins for those ELT cores so that the
ATPG patterns can be applied in parallel.
Syntax
ATPGParallelGroup : <string>;
where string is the label used to identify ELT cores that will have their ATPG patterns applied
in parallel.
Default Value
None
Usage Conditions
This property is used in the LowerBlockModule: InstancePath wrapper of the .etassemble file.
You can specify this property not only at the top level, but also at the ELTCore and Block level.
AuxiliaryTestPort
The AuxiliaryTestPort wrapper can be used to multiplex custom test signals through a
specified set of block primary pins, so as to minimize the impact of the test signals on the block
footprint, as well as for facilitating the connection of these test signals at the next level(s) up,
until they ultimately reach the chip-level IO pads.
ETAssemble automatically creates one RTL module that handles all multiplexing within the
block and inserts it into the highest hierarchy level of your netlist.
For multiplexing your output test signals, you need to choose the name for your block data
output port (the AuxOut port), as well as the name of your block output enable port (the
AuxEnable port). You can multiplex many internal output test signals to a unique AuxOut port,
by repeating the InternalNets wrapper for every such signal. The multiplexing RTL module
will be as follows:
• Multiplex all your specified InternalNets: Output signals onto your specified AuxOut
Port
• Multiplex OR together with all different enable signal sources found in the
InternalNets: Enable properties and connect the result to your specified AuxEnable
port.
ETassemble directly connects the specified AuxIn port directly to all specified InternalNets:
Input pins in a star fashion, without going through the generated multiplexing module. Any
previous connection to Internal input pins is deleted prior to making that connection.
All block auxiliary test ports information is automatically forwarded to the next hierarchical
level up, where ETAssemble feeds them through any intermediate-level blocks, until they
finally reach chip-level ETAssemble, which can either connect them to dedicated test-only IO
pads or multiplex them with other functional logic on shared IO pads. The blocks’ AuxEnable
output pins contribute to the output pad’s enable logic so as to force it ON during the enabled
test.
Syntax
AuxiliaryTestPort {
EnablePort:<HierarchicalPath>;
}
}
where:
• OutputPort property — Specifies the hierarchical name of the block primary output
port (the AuxOut port) to which it multiplexes all specified InternalNets: Output pins.
• InputPort property — Specifies the hierarchical name of the block primary input port,
called the AuxIn port, that directly fans out to all specified InternalNets: Input pins.
• EnablePort property — Specifies the name of the block primary output port that carries
the Enable signal (the AuxEnable port) which is an OR of all specified InternalNets:
Enable pins.
• InternalNets wrapper — Contains a list of all internal test nets that need to be
multiplexed to/from the specified auxiliary test ports. You can repeat this wrapper for
each internal signal to multiplex.
• InternalNets: Output property — Specifies the hierarchical path to your output test
pin.
• InternalNets: Input property — Specifies the hierarchical path to your input test pin.
• InternalNets: Enable property — Specifies the hierarchical path to your enable output
test pin.
Usage Conditions
The AuxiliaryTestPort wrapper is used inside the WTAP wrapper.
In standard usage of ETAssemble, test signals such as memory BIST CMP_STAT or logicTest
controller’s AuxSI/AuxSO signals are automatically hooked to their own auxiliary ports and do
not need any user intervention. Therefore, the AuxiliaryTestPort wrapper should only be used
for custom test signals or for connecting memory BIST test signals outside of the standard
ETAssemble usage.
Example
The following is an example of how to use this wrapper:
WTAP {
....
AuxiliaryTestPort {
InputPort: my_AUXIN;
OutputPort: my_AUXOUT;
EnablePort: my_AUXEN;
InternalNets {
Output: core/myTestOut1;
Enable: core/myTestEnable1;
}
InternalNets {
Input: core/myTestIn;
}
InternalNets {
}
}
// This for hooking up memory BIST ports
// outside of the standard usage of ETAssemble
AuxiliaryTestPort {
OutputPort: BLOCK1_CMP_STAT;
EnablePort: BLOCK1_CMP_STAT_EN;
// For memory_1 with -sharedWIthGo On

InternalNets {
Output: WTAP_INST/status[2];
Enable: WTAP_INST/bistEn[1];
}
// For memory_2 -sharedWithGo On
InternalNets {
Output: WTAP_INST/status[5];
}
// For memory_3 with -compStat On
InternalNets {
Output: CTL1P_CMP_STAT;
}
}
}
For related information, refer to the following:
• WTAP
• WTAP Controller in the manual Embedded Test Hardware Reference
AuxIn
The optional AuxIn wrapper allows you to specify pins as auxiliary-input pins. Each auxiliary-
input pin is an extra fanout of a top-level input port. The control signal is an active-high signal
that enables the path between that input port and a target core input pin. Use this option to steer
test signals to sub-blocks and to make those test signals controllable for primary inputs. You can
use the same primary input as an auxiliary input to multiple destinations by specifying more
than one corePort, controlPort pairs.
You can configure the auxiliary-input pin to act as a test-data input when the device is in test
mode.
Syntax
AuxIn {
<inputPinName>:<corePort1>,<controlPort1>,...;
}
where variables are as follows:
• inputPinName — Specifies the name of the top-level input-only or bidirectional pin

that is to be multiplexed.
• corePort1 — Specifies the hierarchical path to the name of the core port that needs to be
driven.
• controlPort1 — Specifies the name of the control signal that indicates the device is in a
test mode using the pin data for test purposes. You can either specify a hierarchical path
to a net in the design or specify a port on the TAP instance as the control signal. To
designate a TAP instance port as the control signal, you can use the syntax BIST_EN(k)
to specify a bistEN port or the syntax MULTI_EN(k) to specify a multiEn port. The value
k must be a positive integer that is less than the number of BIST ports you specified for
the TAP.
Note
Although controlPortN is mandatory in the above syntax, it is used only when the
JTAG multiplexer is part of the input-pad buffer. In this case, the controlPort signal
enforces the JTAG multiplexer to select the functional input regardless of the value of
the selectJtagInput signal coming from the TAP controller.
Usage Conditions
The AuxIn wrapper is used inside the BoundaryScan wrapper.
These usage conditions apply:
• The specified inputPinName must be an input-only or a bidirectional pin. When a

bidirectional pin is selected for use as an AuxIn, the pad must be configured as an input-
only. This can be done by either:
o Selecting a pin that uses a bidirectional pad but which is always configured to
behave as an input, i.e., the outputEnable is tied inactive.
o Intercepting the outputEnable to ensure that it behaves as an input-only when the pin
is being used as an AuxIn.
Note
You can use a bidirectional pin as both an AuxIn and an AuxOut if the enable
signals are different and you do not activate the enable signals at the same time.
• The AuxIn wrapper should be used only for a specific custom connection that needs
other than the usual Siemens EDA LV controllers ports, such as the auxSI ports for the
logicTest controller. The LV Flow automates all those auxSI connections transparently,
based on information it finds in the Pin Order Input File or using the ports specified by
the AuxInPortList property.
• The pin names specified within this wrapper must be input or bidirectional pins and
must be listed in the PinName column of the Pin Order Input File.
• You can use this option to bring in signals from the top-level, making them available at
the block-level.
Example
The following example specifies two auxiliary-input pins. Control signals BIST_EN(3) and
BIST_EN(5) represent TAP ports bistEn3 and bistEn5, respectively.
BoundaryScan {
AuxIn {
INB[2]:./COREA/GO_T,BIST_EN(3),./COREB/
INA,BIST_EN(5);
DIN[15:8]:./COREA/INO_T[13:6],BIST_EN(3);
}
}
AuxInPortList
The AuxInPortList property specifies a list of top-level pins that allow you to specify which
pins to use as an auxiliary scan inputs for auxiliary scan chains of ELTs or a top logicTest
controller. The specified pins must be either input pins or bidirectional pins.
Syntax
AuxInPortList: <pin>, <pin>, <pin>...;
Buses and scalared numbers can be specified in the short notation as shown below:
AuxInPortList: A,B[4:2],C%[1:0];
is equivalent of:
AuxInPortList: A,B[4],B[3],B[2],C[1],C[0];
Default Value
None
Usage Conditions
This property is used in the following wrappers:
• LogicTest
• LowerBlockModule: InstancePath
Example
AuxInPortList: DIN[0], DIN[1], DOUT[4]...;
AuxOut
The optional AuxOut wrapper identifies pins as auxiliary-output ports. When a pin is identified
as an auxiliary-output port, it is connected via a multiplexer to the corresponding output port of
the core. The control signal for this multiplexer is an active-high signal, which connects the core
port to the auxiliary pin. Use this option to steer diagnostic signals from the core and to make
them available at the top level. If the chip contains multiple cores, all the core ports can be
identified as diagnostic signals with their corresponding control signals.
Syntax
AuxOut {
<outputPinName>: <corePort>,<controlPort1>,...;
}
where valid values are as follows:
• outputPinName — Specifies the top-level output or bidirectional pin that is used as an

auxiliary output pin.
• corePort — Specifies the name of the core port that is multiplexed to the top-level pin.
• controlPort1 — Specifies the name of the control signal for the multiplexer. You can
either specify a hierarchical path to a net in the design or specify a port on the TAP
instance as the control signal. To designate a TAP instance port as the control signal,
you can use the syntax BIST_EN(k) to specify a bistEN port or the syntax MULTI_EN(k)
to specify a multiEn port. The value k must be a positive integer that is less than the
number of BIST ports you specified for the TAP.
Usage Conditions
The AuxOut wrapper is used inside the BoundaryScan wrapper.
• The specified outputPinName must be an output-only or a bidirectional pin.
Note
You can use a bidirectional pin as both an AuxOut and an AuxIn if the enable signals
are different and you do not activate the enable signals at the same time.
• The AuxOut wrapper should be used only for a specific custom connection that needs
other than the usual Siemens EDA LV controllers ports, such as the auxSO ports for the
logicTest controller, or the CompStat port for the memory BIST controller. The LV
Flow automates all those auxSO connections transparently based on information it finds
in the Pin Order Input File or using the ports specified by the AuxOutPortList and
CompStatPort property.
• The pin names specified within this wrapper must be output or bidirectional pins and
must be listed in the PinName column of the Pin Order Input File.
Example
The following example specifies two auxiliary-output pins. Control signals BIST_EN(3) and
BIST_EN(5) represent TAP ports bistEn3 and bistEn5, respectively.
BoundaryScan {
AuxOut {
OUTB[2]:./COREA/GO_T,BIST_EN(3),./COREB/
OUTA,BIST_EN(5);
DOUT[15:8]:./COREA/INO_T[13:6],BIST_EN(3);
}
}
AuxOutPortList
The AuxOutPortList property specifies a list of top-level pins that allow you to specify which
pins to use as an auxiliary scan outputs for auxiliary scan chains of ELTs or a top logicTest
controller, as well as memory BIST. The specified pins must be either output pins or
bidirectional pins.
Syntax
AuxOutPortList: <pin>, <pin>, <pin>...;
AuxOutPortList: A,B[4:2],C%[1:0];
is equivalent of:
AuxOutPortList: A,B[4],B[3],B[2],C[1],C[0];
Default Value
None
Usage Conditions
This property is used in the following wrappers:
• LogicTest
Example
AuxOutPortList: DIN[0], DIN[1], DOUT[4]...;
BlockedAuxiliaryPins
The BlockedAuxiliaryPins property defines top-level pins that cannot be used as auxiliary scan
pins.
Syntax
BlockedAuxiliaryPins: <pin>,<pin>,....;
BlockedAuxiliaryPins: A,B[4:2],C%[1:0];
is equivalent of:
BlockedAuxiliaryPins: A,B[4],B[3],B[2],C[1],C[0];
Default Value
None
Usage Conditions
The BlockedAuxiliaryPins property is located inside the main Configuration wrapper.
Use this property if you want to eliminate a few pins, such as pins with critical timing
requirements, from being Auxiliary Scan pins.
This property cannot be specified together with the AllowedAuxiliaryPins property.
Example
The following example designates BlockedAuxiliaryPins:
BlockedAuxiliaryPins: DIN[0], DIN[1], DOUT[6];
BondingOption
The optional BondingOption wrapper enables you to specify different bonding options so that
the same die can be used in different physical packages. Whether pins are bonded or not
depends on the physical part package. The BondingOption wrapper enables you to bypass
portions of the boundary-scan register when, for example, functional blocks are not needed and
are deactivated and powered down for certain configurations. Also, different device IDs can be
assigned to parts that are sold in different configurations. ETAssemble creates one BSDL file
per bonding option.
Syntax
BondingOption (<BondingOptionName>) {
DeviceIdCode: 16'b<deviceId> | (16'h<deviceId>);
RevisionCode: 4'b<revId> | (4'h<revId>);
}
where BondingOptionName is the name that identifies the bonding option. This name is used as
part of the BSDL file name. Also, the BondingOptionName is used as the default value for the
PHYSICAL_PIN_MAP attribute in the BSDL file.
Default Value
None
Usage Conditions
This sub-wrapper is used in the BoundaryScan wrapper.
• The BondingOption wrapper is used only in the Top-Level flow, not in the Embedded
Boundary Scan flow.
• The BondingOption wrapper is repeatable, which enables you to define multiple
bonding options, each with its own unique BondingOptionName and corresponding
wrapper definition. The BondingOptionName should not be all, All, or ALL.
• The IDCODE of a device consists of 32 bits made up of four parts:
o 4 bits are the RevisionCode, which is the version number defined in the TAP
wrapper and which can be overridden with the value in the BondingOption wrapper.
o 16 bits are the DeviceIdCode, which is the part number defined in the TAP wrapper
and which can be overridden with the value in the BondingOption wrapper.
o 11 bits are the ManufacturersIdCode defined in the TAP wrapper and which cannot
be overridden.
o First bit is always a 1, as defined by the IEEE 1149.1 standard.
• To configure the boundary-scan chain (set the bypasses) and enable the correct device
ID, you must provide an active high signal per bonding configuration. See EnableSignal
for more information.
• You must specify the bypassed portions of the boundary-scan register based on
BGroups. Because BGroups can be bypassed only as a group, they must be contiguous.
Also, the TDI, TDO, TMS, TCK, and TRST pins are not allowed in the middle of a
BGroup. For more information, see the BypassedBGroups property.
• If pins are not bonded, and the boundary-scan cells for these pins are present, the
boundary-scan cells are converted to internal cells in the BSDL file.
• ETAssemble passes information about the bonding options to ETVerify via the .tcm
(Test Connection Map) file. ETVerify creates a test bench and test vectors for each
bonding option. For more information, see the BondingOption property in the ETVerify
Tool Reference.
• Figure 3-6 shows the tool flow with multiple bonding options:
Figure 3-6. Flow With Multiple Bonding Options
Example
The following example shows three different bonding options:
Configuration (myChip) {
TAP {
ManufacturersIdCode: 11’h0b2;
DeviceIdCode: 16’h001a;
RevisionCode: 4’h0;
}
BoundaryScan {
BondingOption (default) { //all cells available in boundary-scan
register and in BSDL file
}
BondingOption (package1) {
UnusedPins: L[*],T1,T3,T5,T7,T9,T11;
DeviceIdCode: 16’h001b;
RevisionCode: 4’h3;
BypassedBGroups: Left;
EnableSignal: /core/fusebox/enable1;
}
BondingOption (package2) {
UnusedPins: R[*],T6,T7,T8,T9,T10,T11;
BypassedBGroups: Right;
EnableSignal: /core/fusebox/enable2;
}
}
}
The bonding option default has no unused pins and no bypassed BGroups. Therefore, the
boundary-scan register contains all boundary-scan cells in the design; no boundary-scan cell is
converted to an internal cell. However, the BSDL file may contain internal cells from the
InternalBScanCells wrapper. Those cells are internal in all configurations as long as they are not
bypassed. The IDCODE is the standard value from the TAP wrapper: 32’h8b2001a0. Note that
the first bit of the 32-bit IDCODE must be 1 as defined by the IEEE 1149.1 standard.
The bonding option package1, shown in Figure 3-7, has several unused pins and a bypassed
BGroup, Left. Also, parts of the IDCODE are redefined. Both the new IDCODE and the bypass
require an enable signal. This signal, /core/fusebox/enable1, controls the muxes so that BGroup
Left is bypassed, and the IDCODE is changed to 32’h8b2001b3. The L[*] pins will not be
internal in the BSDL file because they are bypassed.
Figure 3-7. Bonding Option package1 Example
The bonding option package2, shown in Figure 3-8, has several unused pins and one bypassed
BGroup, Right. The bypass requires an enable signal, /core/fusebox/enable2, which controls the
muxes in the boundary-scan chain so that BGroup Right is bypassed. The IDCODE is the
default from the TAP wrapper, 32’h8b2001a0.
Figure 3-8. Bonding Option package2 Example
Note
In the example, defining the L[*] and R[*] pins as UnusedPins is redundant because those
pins are already bypassed. However, you may want to specify them as unused pins for
clarity.
Refer to the BondingOption property in ETVerify Tool Reference for an example showing the
resulting ETVerify configuration file.
BoundaryScan
The BoundaryScan wrapper conveys information to ETAssemble about how boundary-scan cell
groups in your design are configured. ETAssemble generates boundary-scan cells only when it
detects the presence of the BoundaryScan wrapper within the .etassemble configuration file.
For the embedded boundary scan, you must list the pins on the block that are connected to the
PadIO/FromIo/toIO pins of pad cells. Pins not listed here will be assumed to be internal pins
that are not interfacing with the device boundary. You will get a warning if a pin not listed here
is seen to be connected to a PadIO/FromIo/toIO pin of pad cells. The order of the pin list is used
as the order of the boundary-scan segments.
Issued pins can be listed with a range. For example:
gioa[4],gioa[8:5],gioa[1:3],gioa[0]
A sample BoundaryScan wrapper is provided in Figure 3-9.
Syntax
The wrapper has different contents depending on the flow. The following figures illustrate
syntax of this wrapper in the .etassemble configuration file for these flows:
• Figure 3-1: Complete syntax of .etassemble when running ETAssemble in -flow

EBScan.
• Figure 3-2: Complete syntax of .etassemble when running ETAssemble in -flow chip |
block.
Example
Figure 3-9 illustrates a sample BoundaryScan wrapper in the .etassemble file when running in
-flow chip.
Figure 3-9. Sample BoundaryScan Wrapper in the .etassemble File
Configuration (designName) {
BoundaryScan {
Overrides {
...
}
Sides {
Left: A[0];
Up: SETN;
Right: B[1];
Down: A[7];
}
AuxIn {
INB[2]:./CORE/GO_T,BIST_EN(5);
D[15:8] :./CORE/IN0_T[7:0],BIST_EN(3);
D[7:0]:./CORE/IN1_T[7:0],BIST_EN(3);
INB[1:0] :./CORE/UNITB_SOCKET_AUX_SI[1:0];
}
EnableBCell {
Name: myENcell1;
Ports {
OUT*;
}
}
EnableBCell {
Name: myEnableCell;
Ports {
IO%d(3:8);
}
}
}
}
BurstEnable
The BurstEnable property controls the port name that is used when an external burstEnable
scan port is needed on the core.
Syntax
BurstEnable: <portName>;
where <portName> is the name of a port.
Default Value
The default is LV_BurstEnable.
Usage Conditions
The BurstEnable property is used in the ExtScanPortNaming wrapper.
Example
The following example defines the port as LV_BE:
ExtScanPortNaming {
BurstEnable: LV_BE;
}
Bypass
The Bypass property specifies to ETAssemble that the generated WTAP controller has the
Bypass register inside.
Syntax
ByPass: Yes | No;
where the valid values are as follows:
• Yes — Specifies to have a Bypass register inside the WTAP controller.

• No — Specifies to have no Bypass register inside the WTAP controller.
Default
If either of these properties, DeviceIdCode, ManufacturersIdCode, RevisionCode, is specified,
the default value of Bypass property is forced to Yes. If none of these properties is specified, the
Bypass property defaults to No.
Usage Conditions
The Bypass property is used in the WTAP wrapper.
Example
The example below specifies that a Bypass register is generated inside the WTAP controller:
WTAP {
Bypass: Yes;
}
BypassedBGroups
The optional BypassedBGroups property defines the portions of the boundary-scan register that
are bypassed for the specified bonding option.
Syntax
where BGroupName is a boundary-scan cell grouping that is defined in the Pin Order List Input
File or in the BoundaryScan:Sides wrapper.
Default
None
Usage Conditions
The BypassedBGroups property is used in the BoundaryScan:BondingOption wrapper.
The following usage conditions apply:
• Only a complete BGroup can be bypassed. Therefore, the BGroups must be contiguous.
• If the BypassedBGroups property is specified, the EnableSignal property must be
defined in the BondingOption wrapper.
Example
Refer to the BondingOption wrapper for an example showing the BypassedBGroups property.
CaptureDisable
The CaptureDisable property controls the port name that is used when an external
CaptureDisable scan port is needed on the core.
Syntax
CaptureDisable: <portName>;
where portName is the name of a port.
Default Value
The default value is LV_CD.
Usage Conditions
The CaptureDisable property is used in the ExtScanPortNaming wrapper.
The specified port name must be a simple scalar name. The specified port name cannot be used
by another ExtScanPortNaming wrapper property, such as TestMode.
Example
The following example defines the port as LV_CaptureDisable:
ExtScanPortNaming {
CaptureDisable: LV_CaptureDisable;
}
CDLaunchAligned
The CDLaunchAligned property controls the port name that is used when an external
CaptureDisable launch aligned scan port is needed on the core.
Syntax
CDLaunchAligned: <portName>;
Default Value
The default is LV_CDLA.
Usage Conditions
The CDLaunchAligned property is used in the ExtScanPortNaming wrapper.
by any other property in the ExtScanPortNaming wrapper, such as TestMode.
Example
The following example defines the port as LV_CDLaunchAligned:
ExtScanPortNaming {
CDLaunchAligned: LV_CDLaunchAligned;
}
CDScanEnable
The CDScanEnable property controls the port name that is used when an external
CaptureDisable scan enable port is needed on the core.
Syntax
CDScanEnable: <portName>;
Default Value
The default is LV_CDSE.
Usage Conditions
The CDScanEnable property is used in the ExtScanPortNaming wrapper.
by any other property in the ExtScanPortNaming wrapper, such as TestMode.
Example
The following example defines the port as LV_CDSE:
ExtScanPortNaming {
CDScanEnable: LV_CDSE;
}
Cell
The Cell wrapper enables you to specify information for a particular internal boundary-scan cell
such as where to insert the cell inside the boundary-scan chain or the hierarchical path name of
a target design pin or net that will be controlled by the internal cell.
Syntax

}
where cellName is an arbitrary string that names your internal cell. This name is useful for
documenting the cell in the output BSDL and provides a way to control the cell in the ETVerify
Configuration File.
The cell name is exclusive to each internal boundary-scan cell. ETAssemble reports the cell
name to the BSDL file into a BSDL_extension attribute named
LV_INTERNAL_CELL_LABELS.
The following is an example of such an attribute in the BSDL file. The BSDL_EXTENSION
syntax convention is described in 1149.1 IEEE standard.
attribute LV_INTERNAL_CELL_LABELS: BSDL_EXTENSION;

attribute LV_INTERNAL_CELL_LABELS of top: entity is
-- Label Cell
"((SlewRate2 , 31 )," &
" (SlewRate1 , 30 )," &
" (SlewRate0 , 29 )," &
" (myControl , 28 ))";
Default Value
None
Usage Conditions
The Cell wrapper is used in the BoundaryScan: InternalBScanCells wrapper.
Specify a Cell wrapper for each internal cell that you want to insert in the design.
ChainOrdering
The ChainOrdering property specifies the order of the BISR chain segments. This includes
repairable memories from the memory BIST controllers in the current level as well as the child
BISR segments from lower blocks. Memories associated to a single memory BIST controller
are grouped together and cannot be inter-mixed with memories from other controllers or child
BISR segments.
You can run ETAssemble once without this property. The default ChainOrdering property
value will be echoed in the etassemble.log file. You can then simply cut and paste it into the
.etassemble file while reordering what you want.
Syntax
when listOfInstances specified instance path of memories within the current physical region and
hierarchical path to BIST_SI port on child blocks containing BISR segments.
Default Value
None
Usage Conditions
This property is used in the MemBISR wrapper.
• You specify this property to control the BISR chain ordering in order to minimize
routing congestion.
• If you specify a BISR segment in the DisableChildBisrChains property, you cannot

specify the same BISR segment in the ChainOrdering property.
Example
This example instructs ETAssemble to order the memories and child block BISR segments
within the current physical region. This example has 3 power domain groups and shows a
physical region having both repairable memories in the current level as well as child blocks with
BISR segments. Notice how the BISR SI pins on the child blocks are used to identify the
segments.
MemBISR {
ChainOrdering :
// PowerDomainGroup Label 'A4'
// Memories of Controller Block4_ck_MBIST1_cntrl
“u3/MEM0",
“u7/MEM1",
“u9/MEM2",
// PowerDomainGroup Label 'C4'
// Memories of Controller Block4_ck_MBIST2_cntrl
"Block1_I1/Block1/LV_BISR_SI",
"Block2_I2/LV_BISR_SI_A2",
“U5/MEM3",
...
“U5/MEM7",
“U5/Block2_I2/LV_BISR_SI_B2",
"Block2_I2 /LV_BISR_SI_A2",
// PowerDomainGroup Label 'C5'
"\Block2_I2 /LV_BISR_SI_B2";
}
}
ChildPowerDomainGroupMapping
The ChildPowerDomainGroupMapping wrapper specifies how to map Power Domain Group
labels used when creating a child block to a Power Domain Group label in the parent level. With
this syntax, you can map Power Domain Group labels of repeated instances of a single block
module to different power group labels with the parent level.
Syntax
<HierarchicalPathtoBisrSIPort>: <LabelInTop>;
}
where the following criteria represent the following:
• HierarchicalPathtoBisrSIPort — The hierarchical path to the BISR_SI port on child

blocks. The BISR_SI ports are used as the reference ID to the child segments.
• LabelInTop — The Power Domain Group Label you want to map the specified child
BISR segment to in the current parent module.
Default Value
None
Usage Conditions
This wrapper is used inside the MemBISR wrapper.
You use this wrapper when the current module contains child block modules with BISR
segments and the PowerDomainGroup label given to the Block segment does not match the
label you want them to be assigned to in the parent module.
Example
This example instructs ETAssemble to map the BISR segment with BISR_SI port LV_BISR_SI
on the first instance of Block1 to PowerDomainGroup label C4 and the second instance to C5.
MemBISR {
”Block1_I1/Block1/LV_BISR_SI": C4;
"Block1_I2/Block1/LV_BISR_SI": C5;
}
}
Clock
The Clock property identifies the inout port name of the design block.
Syntax
Clock: <inputPortName>;
where clockPortName specifies the name of the inout port of a module.
Default Value
None
Usage Conditions
The Clock property is used in the TAP: ScanConcatenation wrapper.
The following usage conditions apply to the Clock property:
• You must specify this property for each input port of the design block.
• The Clock property must point to an input port inside the design and must be before the
clock distribution macro.
Example
This example identifies a single scan clock port.
Clock:./clock_buf/A;
Code
The sections below provide detailed information on the following usage of the Code property:
• UserInstruction Usage
• UserSignal Usage
UserInstruction Usage
The Code property defines the opcode instruction that ETAssemble inserts in the
INSTRUCTION_OPCODE field of the BSDL file.
Syntax
UserInstruction (<instructionName>){
Code: <bitValue>;
}
where bitValue is a binary number that is loaded into the TAP’s instruction register and
specifies the most-significant-bit (MSB) to the least-significant-bit (LSB).
Default Value
None
Usage Conditions
The Code property is used in the UserInstruction wrapper.
• The binary length of the instruction code must match the length of the TAP’s instruction
register.
• You can specify multiple instructions
Example
In the following example, the syntax instructs ETAssemble to add the instruction MyInstr2 and
its associated values to the list of instructions within the .bsdl file.
UserInstruction (MyInstr2) {
Code: 17'b10000000000000001;
}
UserSignal Usage
The Code property specifies the opcode for decoding the user signal. Specify this property as a
binary number whose width is less than or equal to the number of IR or DR bits specified using
the NumberUserBits and NumberUserDRBits properties respectively.
Syntax
Code: <bitValue>;
{
where bitValue is a binary integer.
Default Value
None
Usage Conditions
The Code property is used in the UserSignal wrapper.
• When the number of bits of the code is smaller than the number of IR or DR bits, then
the least significant bits of the IR or DR bits are used for decoding purposes.
• You can specify this option multiple times to decode the bits of different user signals.
• Since there is an inversion between the UserIR bit port on the TAP controller and
UserIR register bit in the controller, you must specify user bits values that complement
those specified in the UserIRBit property of the configuration file for the ETVerify tool.
Example
This example instructs ETAssemble to create an output port called myPort on the TAP
controller. This port outputs an activeHigh signal (logic 1) when the decoded value is true.
ETAssemble uses the user-IR bits for decoding purposes and checks only the last two user-IR
bits. Finally, the TAP port is connected to the port u1/u2/u3/data[2] within the design.
UserSignal (TAPportName) {
Code : 5'bxxx00;
Polarity: activeHigh;
DecodeSource: IR;
Connection: u1/u2/u3/data[2];
}
ComponentCompliance
The ComponentCompliance property enables you to instruct the TAP and boundary scan to
conform to either one of these standards: IEEE 1149.1-1993 or IEEE 1149.1-2001.
Syntax
• 1993 — Indicates that the TAP and boundary scan are compliant with the IEEE 1149.1-
1993 standard and that the VHDL package STD_1149_1993 is used.
• 2001 — Indicates that the TAP and boundary scan are compliant with the IEEE 1149.1-
2001 standard and that the VHDL package STD_1149_2001 is used.
Default Value
The default value is 2001.
Usage Conditions
The ComponentCompliance property is used in the TAP wrapper.
• When you specify ComponentCompliance 1993, the all-zero instruction places the
TAP in EXTEST mode.
• When you specify ComponentCompliance 2001, the all-zero instruction selects the
BYPASS register.
Example
The following example indicates that the TAP and BSDL are to conform to the IEEE 1149.1-
2001 standard:
ComponentCompliance: 2001;
CompStatPort
The CompStatPort property is used to identify the default top-level pin(s) that are used as the
memoryBIST test result output port.
Syntax
CompStatPort: <pin>;
...
}
where pin is the top-level output or bidirectional pin.
Default Value
None
Usage Conditions
The pin names specified in the CompStatPort properties must be output or bidirectional pins.
You use the AllowedAuxiliaryPins property to specify the output or bidirectional pins. The pin
names you specify must be listed under the pinName column of the pin order list file, .pinorder.
If no CompStatPort properties are specified, ETAssemble automatically picks the pin to use.
You can use the AUX selection method or the NOAUX exclusion method in the .pinorder file to
instruct ETAssemble which pins can or cannot be used as Compstat output ports.
This property can be specified only when -flow is specified as chip.
Example
The following example designates the default top level pin to be used as the memoryBIST test
result output port:
CompStatPort: DIN{4];
Connection
The Connection property is used in the following wrappers:
• UserSignal Usage
• Cell Usage
UserSignal Usage
The Connection property specifies a complete hierarchical path to the port or net name to
which the TAP port must be connected.
Syntax
where hierachicalPath specifies the path name and is a valid character string.
Default Value
None
Usage Conditions
The Connection property is used in the UserSignal wrapper.
• You must specify a valid hierarchical path to a net that exists in the design.The specified
value is an input port of a module. The input port is first disconnected before the
connection from the TAP ‘s userSignal is made. This enables you to tie off these ports
until the TAP is merged into the chip and the connection from the user signals are made.
• You can specify this option multiple times for a port or a net that fanouts to different
input TAP ports.
Example
UserSignal (myPort) {
Code: 5'bxxx00;
DecodeSource: IR;
}
Cell Usage
The Connection property specifies the hierarchical path name of a target design pin or net that
will be controlled by the internal boundary-scan cell.
Syntax
where hierachicalPath specifies the path name and is a valid character string.
Default Value
None
Usage Conditions
This property is used in the BoundaryScan: InternalBScanCells: Cell wrapper.
Connections
The sections below provide detailed information on the following usage of the Connections
wrapper:
• TAP Usage
• WTAP Usage
• MemBISR Usage
TAP Usage
The Connections wrapper enables you to specify connections between the TAP controller and
other test logic in the design.
You can use the Create() construct with this option if you want to make a connection to a net
that does not already exist in the design. The hierarchical ports specified as Create(<hiernet>)
are not checked for existence nor are they validated by ETAssemble. ETAssemble will simply
create the net specified with the Create() keyword if it has does not already exist.
Syntax
Figure 3-10 illustrates the syntax of the Connections wrapper. Each of the properties in the
Connections wrapper is described in Table 3-10.
Figure 3-10. Syntax Summary of the Connections wrapper
TAP {
Connections {
BIST_EN (<x>): <Connection>;
BIST_HOLD: <Connection>;
BIST_SETUP0: <Connection>;
BIST_SETUP1_0: <Connection>;
BIST_SETUP2_0: <Connection>;
BIST_SHIFT: <Connection>;
BSCAN_ONLY: <Connection>;
CAPTURE_DR: <Connection>;
CAPTURE_DR_2EDGE: <Connection>;
CLK_DR_EN: <Connection>;
CLK_DR_EN_2_EDGE: <Connection>;
CLOCK_ISCAN: <Connection>;
CLOCK_ISCAN_EN: <Connection>;
DR_STATUS(<x>): <Connection>;
FORCE_DISABLE: <Connection>;
FROM_BIST(<x>): <Connection>;
FUNC_MODE (<polarity>): <Connection>;
INSTRUCTION(<x>): <Connection>;
INSTRUCTION_BIT(<x>): <Connection>;
INT_FI_BIT(<n>): <Connection>;
INT_FI_RESET(<n>): <Connection>;
INT_FI_RESET_EN(<n>): <Connection>;
IR_STATUS(<x>): <Connection>;
RESET_TEST: <Connection>;
SELECT_JTAG_INPUT: <Connection>;
SELECT_JTAG_OUTPUT: <Connection>;
SET_TEST: <Connection>;
SHIFT_DR: <Connection>;
SHIFT_DR_2EDGE: <Connection>;
SHIFT_ISCAN: <Connection>;
SHIFT_ISCAN_2EDGE: <Connection>;
STATE: <connection>;
TCK: <Connection>;
TCK_MODE: <Connection>;
TEST_LOGIC_RESET: <Connection>;
TEST_LOGIC_RESET_INV: <Connection>;
TEST_MODE: <Connection>;
TO_BIST_SI: <Connection>;
UPDATE_DR: <Connection>;
UPDATE_DR_EN: <Connection>;
UPDATE_IR: <Connection>;
UPDATE_IR_EN: <Connection>;
UPDATE_ISCAN: <Connection>;
USER_DR_BIT(<x>): <Connection>;
USER_DR_NL_BIT(<x>): <Connection>;
USER_DR_RESET: <Connection>;
USER_IR_BIT(<x>): <Connection>;
USER_IR_NL_BIT(<x>): <Connection>;
ET_CLOCK_ENABLE(<polarity>): <Connection>;
CPUInterface_Enable: <Connection>;
CPUInterface_DataIn: <Connection>;
CPUInterface_DataOut: <Connection>;
CPUInterface_WriteEnable: <Connection>;
CPUInterface_Clock: <Connection>;
CPUInterface_ResetN: <Connection>;
}
}
The following table displays the description of these properties inside the Connections
wrapper.
Table 3-1. Properties in the Connections Wrapper in the TAP Wrapper
Property Legal Value Description
BIST_EN(x) 1-bit net or port Connections from the TAP port
BIST_EN(x).
If a logicTest controller is being inserted
then BIST_EN(0) cannot be specified,
since it is reserved for the logicTest
controller. The TEST_MODE property
can be used in place of BIST_EN(0)
when a logicTest controller is being
inserted.
BIST_HOLD 1-bit net or port Connections from the TAP port holdBist
BIST_SETUP0 1-bit net or port Connections from the TAP port
setupMode[0]
setupMode[1]
setupMode[2]
BIST_SETUP1_0 2-bit net or port Connections from the TAP port
setupMode[1:0]
BIST_SETUP2_0 3-bit net or port Connections from the TAP port
setupMode[2:0]
BIST_SHIFT 1-bit net or port Connections from the TAP port shiftBist
BSCAN_ONLY 1-bit net or port Connections from the TAP port
bscanOnly
bscanOnly is active when the following
boundary-scan mode instructions are
loaded into the TAP instruction register:
SAMPLE, PRELOAD, and EXTEST.
Table 3-1. Properties in the Connections Wrapper in the TAP Wrapper (cont.)
CAPTURE_DR 1-bit net or port Connections from the TAP port
captureDR
Delayed capture for any user-defined test
data register
CAPTURE_DR_2EDGE 1-bit net or port Connections from the TAP port
captureDR2Edge
Delayed capture for any user-defined test
data register
CLK_DR_EN 1-bit net or port Connections from the TAP port
enableClkDR
Delayed enable CK for any user defined
test data register
CLK_DR_EN_2_EDGE 1-bit net or port Connections from the TAP port
enableClkDR2Edge
Enables CK for any user defined test data
register
CLOCK_ISCAN 1-bit net or port Connections from the TAP port
clockIscan
Clock for internal scan.
CLOCK_ISCAN_EN 1-bit net or port Connections from the TAP port
enableClkIscan
Enables clock for internal scan.
DR_STATUS(x) 1-bit net or port Connections from the TAP port
or constant DRStatus[x]
FORCE_DISABLE 1-bit net or port Connections from the TAP port forceDis
FROM_BIST(x) 1-bit net or port Connections from the TAP port fromBistx
FUNC_MODE (<polarity>) 1-bit net or port Connections from the TAP port
funcMode
INSTRUCTION n-bit net or port Connections from the TAP port
instruction[x]
Output of the JTAG Instruction Register
(IR)
The width of net must be the same as that
of IR.
INSTRUCTION_BIT n-bit net or port Connections to the TAP port
instruction[x] one bit at a time
IR_STATUS(x) 1-bit net or port Connections to the TAP port status[x]
RESET_TEST 1-bit net or port Connections from the TAP port resetTest
SELECT_JTAG_INPUT 1-bit net or port Connections from the TAP port
selectJtagInput
SELECT_JTAG_OUTPUT 1-bit net or port Connections from the TAP port
selectJtagOutput
SET_TEST 1-bit net or port Connections from the TAP port setTest
SHIFT_DR 1-bit net or port Connections from the TAP port shiftDR
Delayed shift for any user-defined test
data register
SHIFT_DR_2EDGE 1-bit net or port Connections from the TAP port
shiftDR2Edge
Shift for any user-defined test data
register.
SHIFT_ISCAN 1-bit net or port Connections from the TAP port shiftIscan
Delayed shift for internal scan
SHIFT_ISCAN_2EDGE 1-bit net or port Connections from the TAP port
shiftIscan2Edge
Shift for internal scan
CLOCK_ISCAN 1-bit net or port Connections from the TAP port
clockIscan
Clock for internal scan
STATE 4-bit Connections from the TAP port state
TCK 1-bit net or port Connections from the output of the TCK
input buffer
TCK_MODE 1-bit net or port Connections from the TAP port tckMode
TEST_LOGIC_RESET 1-bit net or port Connections from the TAP port
testLogicReset
Drives an activeHigh when TAP is in the
test logic reset state
TEST_LOGIC_RESET_INV 1-bit net or port Connections from the TAP port
testLogicResetInv
Drives an activeLow when TAP is in the
test logic reset state
TEST_MODE 1-bit net or port Connections from the TAP port testMode
Indicates that the circuit is in a special test
mode
Use the testMode port only when a
logicTest controller is not included in the
top-level embedded logic test. If a
logicTest controller exists, use the output
port INT_TM on the logicTest controller.
TO_BIST_SI 1-bit net or port Connections from the TAP port toIscan
UPDATE_DR 1-bit net or port Connections from the TAP port
updateDR
Update for any user-defined test Data
Register
UPDATE_DR_EN 1-bit net or port Connections from the TAP port
updateDREnable
Update enable for any user-defined test
Data Register
UPDATE_IR 1-bit net or port Connections from the TAP port updateIR
Update for any user-defined Instruction
Register bits
UPDATE_IR_EN 1-bit net or port Connections from the TAP port
updateIREnable
Update enable for any user-defined
Instruction Register bits
UPDATE_ISCAN 1-bit net or port Connections from the TAP port
updateIscan
Update for internal scan
USER_DR_BIT(x) 1-bit net or port Connections from the TAP port
userDRBits[x]
USER_DR_NL_BIT(x) 1-bit net or port Connections from the TAP port
userDRBitsNotLatched[x]
USER_DR_RESET 1-bit net or port Connections to the TAP port
userDRReset
USER_IR_BIT(x) 1-bit net or port Connections from the TAP port
userBits[x]
USER_IR_NL_BIT(x) 1-bit net or port Connections from the TAP port
userBitsNotLatched[x]
ET_CLOCK_ENABLE 1-bit net or port Connections from the TAP port—
userBits[x]
CPUInterface_Enable 1-bit net or port Defines the source of the TAP
CPUInterface_Enable port. This source
must be high then the CPU interface is to
take control of the TAP.
CPUInterface_DataIn n-bit net or port Defines the source of the TAP
CPUInterface_DataIn data bus. The
width of the source port must match the
size of the CPUInterface_DataIn port on
the TAP controller. The width of the
CPUInterface_DataIn data bus is user-
specified and matches the values
specified in the
CPUInterface:DataBusWidth property of
the .etplan file.
CPUInterface_DataOut n-bit net or port Defines the destination of the TAP
CPUInterface_DataOut data bus. The
width of the destination port must match
the size of the CPUInterface_DataOut
port on the TAP controller. The width of
the CPUInterface_DataOut data bus is
user-specified and matches the values
specified in the
CPUInterface:DataBusWidth property of
the .etplan file. If the specified
destination is a port, the port will be
disconnected first before being connected
to the CPUInterface_DataOut output port
of the TAP so you can tie it down in your
golden RTL and rely on ETAssemble to
remove the tie-down value.
CPUInterface_WriteEnable 1-bit net or port Defines the source of the TAP
CPUInterface_WriteEnable port. This
source must be a signal which rises at
least one clock cycle after the
CPUInterface_DataIn is valid and must
then remain high for at least 3 clock
cycles. The signal
CPUInterface_WriteEnable must also be
returned to 0 before the values on
CPUInterface_DataOut can be read.
The rising edge of
CPUInterface_WriteEnable is detected
with a no timing check synchronous cell
so it is not required that it be skew-
aligned to the CPUInterface_Clock. For
more information about the protocol used
by the TAP CPU interface, refer to The
CPU Interface in the manual Embedded
Test Hardware Reference.
CPUInterface_Clock 1-bit net or port Defines the source of the TAP
CPUInterface_Clock port. The source
must be a clock that operates in the
frequency range of TCK. You can design
your TAP to operate at any frequency but
it is not practical to operate TCK faster
than 50MHz.
CPUInterface_ResetN 1-bit net or port Defines the source of the TAP
CPUInterface_ResetN port. The
CPUInterface_ResetN port
asynchronously resets the CPUInterface
state machine of the TAP controller.
Each of these properties specifies a connection between the TAP controller ports and embedded
test controllers in core logic. All properties, except the DR_STATUS(x), FROM_BIST(x), and
IR_STATUS(x) properties, can be repeated to specify a connection for different controllers.
Usage Conditions
The Connections wrapper is used in the TAP wrapper.
Example 1
Figure 3-11 on page 83 shows the connections between the TAP controller and core modules
that contain memory BIST controllers.
Figure 3-11. Example Connections Between TAP Controller and Core Modules
Figure 3-12 contains the corresponding Connections wrapper that describes these connections.
Figure 3-12. Syntax for TAP Controller Connections
Connections {
// To Core Instance COREA
BIST_SHIFT : COREA/BIST_SHIFT;
BIST_HOLD: COREA/BIST_HOLD;
BIST_SETUP1: COREA/BIST_SETUP(1);
BIST_SETUP0 : COREA/BIST_SETUP(0);
TCK : COREA/TCK;
TCK_MODE : COREA/TCK_MODE;
TO_BIST_SI : COREA/BIST_SI;
// membistA Controller
BIST_EN(0) : COREA/CTLA_MBIST_EN;
FROM_BIST(0): COREA/CTLA_MBIST_SO;
IR_STATUS(0): COREA/CTLA_MBIST_GO;
IR_STATUS(1): COREA/CTLA_MBIST_DONE;
// membistB Controller
BIST_EN(1) : COREA/CTLB_MBIST_EN;
FROM_BIST(1): COREA/CTLB_MBIST_SO;
IR_STATUS(2): COREA/CTLB_MBIST_GO;
IR_STATUS(3): COREA/CTLB_MBIST_DONE;
// To Core Instance COREB

BIST_SHIFT : COREB/BIST_SHIFT;
BIST_HOLD : COREB/BIST_HOLD;
BIST_SETUP1 : COREB/BIST_SETUP(1);
BIST_SETUP0 : COREB/BIST_SETUP(0);
TCK : COREB/TCK;
TCK_MODE : COREB/TCK_MODE;
TO_BIST_SI : COREB/BIST_SI;
// membistC Controller
BIST_EN(2) : COREB/CTLC_MBIST_EN;
FROM_BIST(2): COREB/CTLC_MBIST_SO;
IR_STATUS(4): COREB/CTLC_MBIST_GO;
IR_STATUS(5): COREB/CTLC_MBIST_DONE;
}
Example 2
Figure 3-13 on page 85 contains a second example where the TAP controller was built with a
12-bit CPUInterface. The TAP: Connections wrapper is used to connect the CPU Interface of
the TAP to the CPU hardware within the chip. It is also used to connect 6 user data bits to allow
programming the feedback ratio of a PLL using the TAP. Bit 5 is used to control the select line
of the mux that gives control of the PLL ratio bits to the CPU register or to the TAP. At power
up, the PLL is under control of the CPU register but a simple TDR load can set the user data bit
to give control of the PLL ratio to the TAP, thus, making it easy to program the PLL feedback
ratio during manufacturing test.
Figure 3-13. Example Chip With a TAP Having a CPUInterface Connected to a

CPU Block
Figure 3-14 provides TAP: Connections in the .etassemble file for the example in Figure 3-13.
Figure 3-14. TAP Connections of CPUInterface and User Data Bits
TAP {
NumberUserDRBits: 6;
Connections {
CPUInterface_Enable : cpu2Tap_I1/to_CPUInterface_Enable;
CPUInterface_DataIn : cpu_I1/cpuWriteData[11:0];
CPUInterface_DataOut : cpu_I1/cpuReadData3[11:0];
CPUInterface_WriteEnable : cpu2Tap_I1/to_CPUInterface_WriteEnable;
CPUInterface_Clock : cpu2Tap_I1/to_CPUInterface_Clock;
CPUInterface_ResetN : cpu2Tap_I1/to_CPUInterface_ResetN;
USER_DR_BIT (0) : pllControl_I1/tap_dataBits[0];
USER_DR_BIT (1) : pllControl_I1/tap_dataBits[1];
USER_DR_BIT (2): pllControl_I1/tap_dataBits[2];
}
}
WTAP Usage
The Connections wrapper enables you to specify connections between the WTAP controller and
other test logic in your design.
Syntax
The syntax of the Connections wrapper is as follows:
Connections {
BIST_EN (<x>): <Connection>;
BIST_HOLD: <Connection>;
BIST_SHIFT: <Connection>;
CAPTURE_DR: <Connection>;
CAPTURE_DR_2EDGE: <Connection>;
CLK_DR_EN: <Connection>;
CLK_DR_EN_2_EDGE: <Connection>;
CLOCK_BIST_TCK: <Connection>;
FROM_BIST (<x>): <Connection>;
FUNC_MODE (<polarity>): <Connection>;
INSTRUCTION_BIT (<x>): <Connection>;
STATUS (<x>): <Connection>;
RESET_TEST: <Connection>;
SET_TEST: <Connection>;
SHIFT_DR: <Connection>;
SHIFT_DR_2EDGE: <Connection>;
TCK: <Connection>;
WSI: <Connection>;
UPDATEWR: <Connection>;
TCK_MODE: <Connection>;
TEST_MODE: <Connection>;
TEST_LOGIC_RESET: <Connection>;
TEST_LOGIC_RESET_INV: <Connection>;
TO_BIST: <Connection>;
TO_BIST_SI: <Connection>;
UPDATE_DR: <Connection>;
UPDATE_DR_EN: <Connection>;
UPDATE_IR: <Connection>;
UPDATE_IR_EN: <Connection>;
CAPTUREWR: <Connection>;
SHIFTWR (<x>): <Connection>;
USER_IR_BIT (<x>): <Connection>;
USER_NL_IR_BIT (<x>): <Connection>;
ET_CLOCK_ENABLE (<polarity>): <Connection>;
}
Descriptions of the above connections are provided in Figure 3-14.

Table 3-2. Descriptions of Valid Connections in the WTAP Wrapper
Table 3-2. Descriptions of Valid Connections in the WTAP Wrapper (cont.)

BIST_EN 1-bit net or port Connections from the WTAP port
BIST_EN(x).
If a logicTest controller is being inserted
then BIST_EN(0) cannot be specified, since
it is reserved for the logicTest controller. The
TEST_MODE property can be used in place
of BIST_EN(0) when a logicTest controller
is being inserted.
BIST_HOLD 1-bit net or port Connections from the WTAP port—holdBist
BIST_SETUP n-bit net or port Connections from the WTAP port—
setupMode
BIST_SHIFT 1-bit net or port Connections from the WTAP port—shiftBist
CAPTURE_DR 1-bit net or port Connections from the WTAP port—
captureDR
CAPTURE_DR_2EDGE 1-bit net or port Connections from the WTAP port—
captureDR2Edge
CLK_DR_EN 1-bit net or port Connections from the WTAP port—
enableClkDR
CLK_DR_EN_2_EDGE 1-bit net or port Connections from the WTAP port—
enableClkDR2Edge
CLOCK_BIST_TCK 1-bit net or port Connections from the WTAP port—
clkBistTck
FROM_BIST (<x>) n-bit port Connections from the WTAP port—
fromBist
FUNC_MODE (<polarity>) 1-bit net or port Connections from the WTAP port—
functMode
INSTRUCTION_BIT n-bit net or port Connections to the WTAP port instruction[x]
one bit at a time
STATUS n-bit net or port Connections from the WTAP port—status
RESET_TEST 1-bit net or port Connections from the WTAP port—
resetTest
SET_TEST 1-bit net or port Connections from the WTAP port—setTest
SHIFT_DR 1-bit net or port Connections from the WTAP port—shiftDR
SHIFT_DR_2EDGE 1-bit net or port Connections from the WTAP port—
shiftDR2Edge
TCK 1-bit net or port Connections from the WTAP port—WRCK
WSI 1-bit net or port Connections from the WTAP port—WSI
Table 3-2. Descriptions of Valid Connections in the WTAP Wrapper (cont.)

UPDATEWR 1-bit net or port Connections from the WTAP port—
updateWR
TCK_MODE 1-bit net or port Connections from the WTAP port—
tckMode
TEST_MODE 1-bit net or port Connections from WTAP port—extTM
The extTM port is only used when a
logicTest controller is not included. If a
logicTest controller does exist then the
output port INT_TM on the logicTest
controller will be used.
TEST_LOGIC_RESET 1-bit net or port Connections from the WTAP port—
testLogicReset
TEST_LOGIC_RESET_INV 1-bit net or port Connections from the WTAP port—WRSTN
UPDATE_DR 1-bit net or port Connections from the WTAP port—
updateDR
UPDATE_DR_EN 1-bit net or port Connections from the WTAP port—
updateDREnable
UPDATE_IR 1-bit net or port Connections from the WTAP port—
updateIR
USER_IR_BIT n-bit net or port Connections from the WTAP port—
userIRBits
USER_NL_IR_BIT n-bit net or port Connections from the WTAP port—
userIRBitsNotLatched
ET_CLOCK_ENABLE 1-bit net or port Connections from the WTAP port—
userBits[x]
Each of these properties specifies a connection between the WTAP controller ports and user
logic.
Usage Conditions
You have to verify that the specific WTAP’s functionality is conforming to your requirements
prior to connecting it using the Connections wrapper.
Example
This example shows the connections between the WTAP controller and COREA’s
USER_DEFINED_BIST_SHIFT port.
WTAP {
Connections {
// To Core Instance COREA
BIST_SHIFT: COREA/USER_DEFINED_BIST_SHIFT;
}
}
MemBISR Usage
The Connections wrapper inside the MemBISR wrapper of the .etassemble file enables you to
specify connections that need to be done to the BISR controller. Each Connections property
must point to a valid net or port in the netlist.
Syntax
The syntax of the Connections wrapper is as follows:
MemBISR {
Connections {
BisrDone: <Port>;
BisrGo: <Port>;
FuseBoxInterfaceReset: <Port>;
PowerDomainGroupBusy (<int> | <PdgLabel>): <Net> | <Port>;
PowerDomainGroupDone (<int> | <PdgLabel>): <Net> | <Port>;
PowerDomainGroupEnable (<int> | <PdgLabel>): <Net> | <Port>;
PowerDomainGroupReset (<int> | <PdgLabel>): <Net> | <Port>;
}
}
where the above criteria represent the following:
• Label — specifies a valid clock label.

• PdgLabel — specifies a valid power domain group label.
• Port — specifies an existing port inside the module.
• int — is an integer between 0 and the number of PowerDomainGroups supported by the
BISR controller minus one.
• Net|Port — is a internal pin or net in your power management unit.
Descriptions of the above properties are as follows:
• BisrDone — specifies an input port of a user module that should be connected to the
Done output of the BISR controller. This output indicates whether the execution of the
last autonomous operation performed by the BISR controller was completed. This
property is optional. It is also repeatable.
• BisrGo — specifies an input of a user module that should be connected to the Go output
of the BISR controller. This output indicates whether the execution of the last
autonomous operation performed by the BISR controller was successful. This property
is optional. It is also repeatable.
• FunctionalRepairClockLabel — specifies the functional clock source used by the BISR
controller to perform memory repair. Refer to Example 1.
• FunctionalRepairEnable — specifies the functional signal that initializes the BISR
controller and BISR registers and initiates memory repair. Typically, this signal is
derived from a power-on detector. Example 1.
• FuseBoxAccess — specifies the fuse box interface input port that initiates an access to
the external fuse box. The specified input port will be connected to the FuseBoxAccess
output of the BISR controller. This property is required if the MemBISR:
ExternalFuseBox property is set to Yes.
• FuseBoxAddress — specifies the input address port of an external fuse box interface.
The input address port will be connected to FuseBoxAddress output of the BISR
controller. The bus range must be specified as part of the port name and must have the
size specified with the FuseBoxAddress property. This property is required if the
MemBISR: ExternalFuseBox property is set to Yes.
• FuseBoxBufferTransfer — specifies the output initiating the final programming of the
fuse boxes using the Buffered programming method. This property is required if
MemBISR:ExternalFuseBox is set to Yes and MemBISR:
FuseBoxProgrammingMethod is set to Buffered. Refer to Example 2.
• FuseBoxClock — specifies the clock input port of an external fuse box interface. The
specified clock input port will be connected to the FuseBoxClock output of the BISR
controller. This property is required if the MemBISR: ExternalFuseBox property is set
to Yes.
• FuseBoxDone — specifies the output flag of the external interface that indicates when
the fuse box access has been completed. This property is required if the MemBISR:
• FuseBoxInterfaceReset — specifies the hierarchical path to the generic fuse box
interface reset port. A port must be specified with this property if the MemBISR:
ExternalFuseBox property is set to Yes and the fuse box interface has a reset port, in
which case FuseBoxInterfaceResetPresent: Yes is automatically inferred, and the fuse
box controller connects the FBreset output port to the specified port. The fuse box reset
signal is applied on the fuse box interface and released during the Autonomous and
FuseBoxAccess run modes.
If the ExternalFuseBox property is set to No, the name of the reset port on the generic
fuse box interface module must be FBreset.
• FuseBoxSelect — specifies the fuse box interface input port that selects (enables) the
external fuse box. The specified input select port will be connected to the FuseBoxSelect
output port of the BISR controller. This property is required if the MemBISR:
• FuseBoxValue — specifies the output data port of an external fuse box interface. The
output data port is connected to the fuseValue input of the BISR controller. This
property is required if the MemBISR: ExternalFuseBox property is set to Yes.
• FuseBoxWrite — specifies the input write port that configures the external fuse box in
write mode. The specified write input port will be connected to the FuseBoxWrite output
of the BISR controller. This property is required if the MemBISR: ExternalFuseBox
property is set to Yes.
• PowerDomainGroupBusy — specifies a connection for each PowerDomainGroupBusy
signal to your functional logic. The port is called bisrCEDis_<PdgLabel> on the BISR
controller and is used by your functional logic to inform that the loading of the BISR
chain associated with the given PowerDomainGroup is in process and that the
associated memories are busy. You use this to connect the bisrCEDis_<PdgLabel>
ports to your functional logic such that your powerup management unit knows when the
PowerDomainGroups are been loaded. Refer to Example 3.
• PowerDomainGroupDone — specifies a connection for each PowerDomainGroupDone
signal to your functional logic. The port is called PDGDone_<PdgLabel> on the BISR
controller and is used by your functional logic to inform that the loading of the BISR
chain associated with the given PowerDomainGroup is finished. You use this to connect
the PDGDone_<PdgLabel> ports to your functional logic such that your powerup
management unit knows when the PowerDomainGroups has been loaded. Refer to
Example 4.
• PowerDomainGroupEnable — specifies a connection for each
PowerDomainGroupEnable signal to your functional logic. The port is called
PowerDomainGroupEnable_<PdgLabel> on the BISR controller and is used by your
functional logic to inform the BISR controller which PowerDomainGroup to program.
You use this to connect the PowerDomainGroupEnable_<PdgLabel> ports to your
functional logic such that your powerup management unit can instruct which
PowerDomainGroup to load. Refer to Example 5.
• PowerDomainGroupReset — specifies a connection for each
PowerDomainGroupReset signal to your functional logic. The port is called
bisrRstn_<PdgLabel> on the BISR controller and is used by your functional logic to
know when the BISR chain associated to the given PowerDomainGroup has been
cleared. You use this to connect the bisrRstn_<PdgLabel> ports to your functional logic
such that your powerup management unit knows when the PowerDomainGroups are
being cleared. Refer to Example 6.
• ProgrammingVoltagePin — specifies the chip input pin used to program the fuse box.
This property is mandatory when inserting BISR at the chip level. Refer to Example 1.
• WriteDurationCounter — specifies the name of a 32-bit input bus of the external fuse
box interface that indicates the number of clock cycles required to perform a write
operation. This input bus will be connected to the WriteDurationCounter output port of
the BISR controller. The bus range must be specified as part of the specified name.
Usage Conditions
You have to verify that the specific BISR functionality is conforming to your requirements prior
to connecting it using the Connections wrapper in the MemBISR wrapper of the .etassemble
file.
Example 1
This example specifies to ETAssemble that the fuse box is internal to the BISR controller and
provides information on the functional connections to the BISR controller.
Configuration (BLOCK_A) {
MemBISR {
ExternalFuseBox: No;
Connections {
FunctionalRepairClockLabel: CLK;
FunctionalRepairEnable: sysRstn/SysRstOut;
ProgrammingVoltagePin: vddq_i;
}
}
}
Example 2
This example specifies to ETAssemble that the fuse box is external to the BISR controller and
that the programming method is buffered; the Connections:FuseBoxBufferTransfer property
specifies the pin on the fuse box interface that will activate the final fuse box programming.
MemBISR {
ExternalFuseBox: Yes;
FuseBoxAddressBits: 8;
FuseBoxSize: 256;
FuseBoxWriteDuration: 5.9us;
FuseBoxProgrammingMethod: Buffered;
FuseBoxAccessPipeline: Yes;
Connections {
FunctionalRepairClockLabel: CLK;
FunctionalRepairEnable: sysRstn_i;
ProgrammingVoltagePin: vddq;
FuseBoxClock: FB_inst/clock;
FuseBoxAddress: FB_inst/Address[7:0];
FuseBoxWrite: FB_inst/writeFB;
FuseBoxSelect: FB_inst/selectFB;
FuseBoxAccess: FB_inst/FBAccess;
FuseBoxValue: FB_inst/fuseValue;
FuseBoxDone: FB_inst/doneFB;
FuseBoxBufferTransfer: FB_inst/programFB;
WriteDurationCounter: FB_inst/strobeCntVal[31:0];
}
}
Example 3
This example instructs ETAssemble to connect the second PowerDomainGroupBusy signal to a
pin called myPUUnit/PDa_busy. The association between (1) and the bisrCEDis_<PdgLabel>
port on the controller is done using the label order specified with the
PowerDomainGroupPriority property.
MemBISR {
Connections {
PowerDomainGroupBusy (1): myPUUnit/PDa_busy;
}
}
Example 4
This example instructs ETAssemble to connect the second PowerDomainGroupDone signal to
a pin called myPUUnit/PDa_done. The association between (1) and the
PDGDone_<PdgLabel> port on the controller is done using the label order specified with the
MemBISR {
Connections {
PowerDomainGroupDone (1): myPUUnit/PDa_done;
}
}
Example 5
This example instructs ETAssemble to connect the second PowerDomainGroupEnable signal
to a pin called myPUUnit/PDa_en. The association between (1) and the
PowerDomainGroupEnable_<PdgLabel> port on the controller is done using the label order

specified with the PowerDomainGroupPriority property.
MemBISR {
Connections {
PowerDomainGroupEnable (1): myPUUnit/PDa_done;
}
}
Example 6
This example instructs ETAssemble to connect the second PowerDomainGroupReset signal to
a pin called myPUUnit/PDa_resetn. The association between (1) and the
bisrRsrn_<PdgLabel> port on the controller is done using the label order specified with the
MemBISR {
Connections {
PowerDomainGroupReset (1): myPUUnit/PDa_reset;
}
}
ConnectionStatus
The ConnectionStatus wrapper is used with the ExplicitAuxPortConnections wrapper only
when the TCMGen tool is used in the flow instead of designExtract. ConnectionStatus enables
you to add the needed supporting information for the top-level ports mapped to the instance pins
pointed to by the AuxIn(#)/AuxOut(#)/AuxEn properties from the
ExplicitAuxPortConnections wrapper.
Syntax
ConnectionStatus {
AuxIn(#) : <TopLevelInputPin>;
AuxOut(#) : <TopLevelOutputPin>;
AuxEn : <TopLevelOutputPin>;
}
where:
• TopLevelInputPin and TopLevelOutputPin are chip-level pin names.

Default Value
None
Usage Conditions
The ConnectionStatus wrapper is used in the LogicTest: ExplicitAuxPortConnections
wrapper.
This wrapper only needs to be applied when the TCMGen tool is used instead of designExtract.
Example
The following example instructs ETAssemble to connect the AuxIn(0) input pin of the logic test
controller to a dedicated output port of a multiplexer inside the inst1 instance (inst1/mux_i/o1).
The additional mapping of AuxIn(0) in the ConnectionStatus wrapper informs the TCMGen
tool that this internal pin (inst1/mux_i/o1) can be traced to the top-level pin test_aux_in.
Similarly, the AuxOut(0) output pin of the logic test controller instance will be connected to the
inst1/buf3/i0 internal input pin, which can be traced to the test_aux_out top-level pin. Finally,
the AuxEn output will be connected through the inst1/buf4/i0 internal input pin to the
test_aux_en top-level pin.
Configuration (myDesign) {
LogicTest {
AuxIn(0) : ./inst1/mux_i/o1;
AuxOut(0) : ./inst1/buf3/i0;
AuxEn : ./inst1/buf4/i0;
ConnectionStatus {
AuxIn(0) : test_aux_in;
AuxOut(0) : test_aux_out;
AuxEn : test_aux_en;
}
}
}
}
ConstantConnections
The ConstantConnections wrapper specifies the pin name and function of a hierarchical port
or net on the test-collared core.
Syntax
ConstantConnections {
LogicLow: hierarchicalPort | hierarchicalNet;
LogicHigh: hierarchicalPort | hierarchicalNet;
OPEN: hierarchicalPort;
}
• hierarchicalPort and hierarchicalNet are any valid Verilog or VHDL identifier that
specifies an input, output, or select pin of the test-collared core.
• LogicLow indicates that the pin of the test-collared core’s port or net is logic 0.
• LogicHigh indicates that the pin of the test-collared core’s port or net is logic 1.
• OPEN indicates that the pin of the test-collared core’s port or net is floating.
Default Value
None
Usage Conditions
• You can use the Create() construct with this option to determine test port connections
before they exist on the logic block. The hierarchical ports specified as
Create(<hiernet>) are not checked for existence nor are they validated by ETAssemble.
Use this feature only with the Top-Down approach in the Hierarchical Embedded Logic
Test.
• You must identify the input, output, and select pins of the block using the pin functions
described above.
• In the LV Flow, the connections specified in the ConstantConnections wrapper are
implemented in the first pass of the Two-Pass approach.
Example
In this example, the syntax instructs ETAssemble to determine all ports and nets in the
ConstantConnections wrapper before they actually exist on the specified logic sub-blocks and
to make the connections at the end of the first pass of the Two-Pass approach.
ConstantConnections {
LogicLow: Create(UNITB_I1/ESE_CLKB);
LogicLow: Create(UNITB_I1/ESI_CLKB);
LogicLow: Create(UNITB_I1/ESI_CLKB1);
LogicLow: Create(UNITB_I1/ESI_CLKB2);
LogicLow: Create(UNITB_I1/LV_SE_LBIST);
LogicLow: Create(UNITB_I1/LV_SI_LBIST_F1);
Open: Create(UNITB_I1/ESO_CLKB);
Open: Create(UNITB_I1/ESO_CLKB1);
Open: Create(UNITB_I1/ESO_CLKB2);
Open: Create(UNITB_I1/LV_SO_LBIST_F1);
Open: Create(UNITB_I1/LV_SO0_CKB1_F2_ext);
Open: Create(UNITB_I1/LV_SO0_CKB2_F4_ext);
Open: Create(UNITB_I1/LV_SO0_CKB_F1_ext);
}
ConstantLogic0Inputs
The ConstantLogic0Inputs property specifies pins which must be asserted to 0 for the
Embedded Boundary Scan JtagVerify simulation to work. Those can be VSS pins connected to
the pad buffers or other configuration pins needed to be driven low for the pad drivers to work
properly. Do not list such pins in the PadIOPins list even if those are VSS pins. Only when you
reach the top level of the chip, will you declare your VSS pins such that they get documented as
such in the BSDL file.
If the Embedded Boundary Scan block is sub-physical region which you will process using the
ELTCore or Block flow, those constant 0 pins will be forwarded to designExtract as logic 0 pins
through the .etassemble Configuration File Structure. Those pins will be asserted low in all
testbenches created at the Block or ELT level but it will be your responsibility to make sure that
those pins are driven low when the block or ELT is instantiated at the top level. You often will
do this by declaring your VSS and CE0 pins using the .etassemble Configuration File Structure
property when running ETChecker at the top.
Syntax
ConstantLogic0Inputs: VCC, Ten3[2:1], Ten4[2]a;
where valid values are pins found on the block containing embedded pads which needs to be
asserted low for the pads to operate correctly.
Default Value
None
Usage Conditions
This property is used in the BoundaryScan wrapper when used in the Embedded Boundary Scan
flow.
• This property is used when running ETAssemble in -flow EBScan.

• If the pin is part of a bus with ascending order, you can use the letter a at the end to
signify that the pin is part of an ascending bus.
Example
In this example, the syntax instructs ETAssemble that pins VSS1, Ten1[2:1], and Ten4[2] are to
be asserted low during Embedded Boundary Scan simulation. It also instructs ETAssemble that
pin Ten4 is part of an ascending order bus.
BoundaryScan {
ConstantLogic0Inputs: VSS1, Ten3[2:1], Ten4[2]a;
}
ConstantLogic1Inputs
The ConstantLogic1Inputs property specifies pins which must be asserted to 1 for the
Embedded Boundary Scan JtagVerify simulation to work. Those can be VDD pins connected to
the pad buffers or other configuration pins needed to be driven high for the pad drivers to work
properly. Do not list such pins in the PadIOPins list even if those are VDD pins. Only when you
reach the top level of the chip, will you declare your VDD pins such that they get documented as
such in the BSDL file.
If the Embedded Boundary Scan block is sub-physical region which you will process using the
ELTCore or Block flow, those constant 1 pins will be forwarded to designExtract as logic 1 pins
through the .lvbscan Input File. Those pins will be asserted high in all testbenches created at the
Block or ELT level but it will be your responsibility to make sure that those pins are driven high
when the block or ELT is instantiated at the top level. You often will do this by declaring your
VDD and CE1 pins using the lv.JTAGOption property when running ETChecker at the top.
Syntax
ConstantLogic1Inputs: VDD1, Ten3[2:1], Ten4[2]a;
where valid values are pins found on the block containing embedded pads which needs to be
asserted high for the pads to operate correctly.
Default Value
None
Usage Conditions
This property is used in the BoundaryScan wrapper when used in the Embedded Boundary Scan
flow.
• This property is used when running ETAssemble in -flow EBScan.

• If the pin is part of a bus with ascending order, you can use the letter a at the end to
signify that the pin is part of an ascending bus.
Example
In this example, the syntax instructs ETAssemble that pins VDD1, Ten1[2:1], and Ten4[2] are
to be asserted high during Embedded Boundary Scan simulation. It also instruct ETAssemble
that pin Ten4 is part of an ascending order bus.
BoundaryScan {
ConstantLogic0Inputs: VSS1, Ten3[2:1], Ten4[2]a;
}
CreateScalarPortsOnly
The CreateScalarPortsOnly property indicates whether scalarized ports are to be created for
all external test ports added at the ELT level.
When set to Yes, ETAssemble scalarizes all test ports and external scan ports that are created on
the module (extCD, extSI, extSO, AuxIn, AuxOut, AuxEn, WSO, enableWR, and so on).
Syntax
CreateScalarPortsOnly: Yes | (No);
• Yes — specifies the created ports are to be scalarized.

• No — specifies bussed port to be created.
Default Value
The default value is No.
Usage Conditions
This property is used in the Configuration wrapper.
CustomObject
The CustomObject wrapper specifies any custom cells instantiated into the design. You can
use this wrapper during the assembly phase of the top-level module.
Syntax
The following syntax specifies this custom object script:
CustomObject(<objectName>) {
Var(VariableName): <value>;
}
where the following syntax represents the above criteria:
• The custom object script is performed at the end of the assembly phase of the
ETAssemble run.
• objectName — specifies the name of the custom object script.
• Var(VariableName): <value> — specifies the variable name and value expected by
the custom object script.
Default Value
None
Usage Conditions
None
Example
In the following example, the syntax instructs ETAssemble to execute the custom object scripts
during the assembly phase.
CustomObject(Gate1Connect) {
Var(ModuleName) : IV110;
Var(InstanceName) : myInv;
Var(OutputPin) : Y;
Var(Input0Pin) : A;
Var(Input0Connection): U1/ABC;
Var(OutputConnection): Net2;
}
CustomObject(Gate1InterceptDestination) {
Var(ModuleName): IV110;
Var(InstanceName): ABC_INV;
Var(OutputPin) : Y;
Var(Input0Pin) : A;
Var(InterceptPort): U1/ABC;
}
CustomObject(ModuleInstantiate) {
Var(ModuleName): COUNTER;
Var(InstanceName): myCounter;
}
Var(ModuleName) : OR210;
Var(InstanceName) : FM_OR1;
Var(OutputPin) : Y;
Var(Input0Pin) : A;
Var(Input1Pin) : B;
Var(InterceptPort): U1/FUNC_MODE;
Var(Input1Connection): LVISION_JTAP_INST/
userDRBits[2];
}
CustomObject (ConnectLogicHighToPort)
The ConnectLogicHighToPort custom object script connects the specified input port to
logicHigh.
Syntax
CustomObject(ConnectLogicHighToPort) {
Var(Port): <HierarchicalInputPortName>;
}
where Port specifies the hierarchical input port to be connected to logicHigh.
Default Value
None
Usage Conditions
The ConnectLogicHighToPort custom object script is used in the CustomObject wrapper.
Example
In the following example, myMux1/A is to be connected to logicHigh.
CustomObject(ConnectLogicHighToPort) {
Var(Port): myMux1/A;
}
CustomObject (ConnectLogicLowToPort)
The ConnectLogicLowToPort custom object script connects the specified input port to
logicLow.
Syntax
CustomObject(ConnectLogicLowToPort) {
Var(Port): <HierarchicalInputPortName>;
}
where valid variables are as follows:
• Port — specifies the hierarchical input port to be connected to logicLow.

Default Value
None
Usage Conditions
The ConnectLogicLowToPort custom object script is used in the CustomObject wrapper.
Example
In the following example, myMux1/A is to be connected to logicLow.
CustomObject(ConnectLogicLowToPort) {
Var(Port): myMux1/A;
}
CustomObject (ConnectNetToPort)
The ConnectNetToPort custom object script creates a connection between the specified net
and port.
Syntax
CustomObject(ConnectNetToPort) {
Var(Net): <HierarchicalNetName>;
Var(Port): <HierarchicalPortName>;
}
• Net — specifies the hierarchical net to be connected.

• Port — specifies the hierarchical port to connect the net to.
Default Value
None
Usage Conditions
The ConnectNetToPort custom object script is used in the CustomObject wrapper.
Example
In the following example, Net2 is to be connected to the AND gate myAND2/A.
CustomObject(ConnectNetToPort) {
Var(Net): Net2;
Var(Port): myAND2/A;
}
CustomObject (ConnectPortToPort)
The ConnectPortToPort custom object script creates a connection between the two specified
ports.
Syntax
CustomObject(ConnectPortToPort) {
Var(Port1): <HierarchicalPortName>;
Var(Port2): <HierarchicalPortName>;
}
• Port1 — specifies the hierarchical port1.

• Port2 — specifies the hierarchical port2.
Default Value
None
Usage Conditions
The ConnectPortToPort custom object script is used in the CustomObject wrapper.
Example
In the following example, myMux1/Y is to be connected to the AND gate myAND2/A. If there is
already a connection to the myAND2/A input port or myMux1/Y, then those connections will be
maintained after connecting the input port A of myAND2 to the output Y of myMux1.
CustomObject(ConnectPortToPort) {
Var(Port1): myMux1/Y;
Var(Port2): myAND2/A;
}
CustomObject (CreateInputPort)
The CreateInputPort custom object script creates the specified input port.
Syntax
CustomObject(CreateInputPort) {
}
• Port — specifies the hierarchical port to be created.

Default Value
None
Usage Conditions
The CreateInputPort custom object script is used in the CustomObject wrapper.
Example
In the following example, the port A is to be created on the instance U123.
CustomObject(CreateInputPort) {
Var(Port): U123/A;
}
CustomObject (CreateOutputPort)
The CreateOutputPort custom object script creates the specified output port.
Syntax
CustomObject(CreateOutputPort) {
}
• Port — specifies the hierarchical port to be created.

Default Value
None
Usage Conditions
The CreateOutputPort custom object script is used in the CustomObject wrapper.
Example
In the following example, the port Y is to be created on the instance U123.
CustomObject(CreateOutputPort) {
Var(Port): U123/Y;
}
CustomObject (DisconnectPort)
The DisconnectPort custom object script disconnects any nets connected to the specified port.
Syntax
CustomObject(DisconnectPort) {
}
• Port — specifies the hierarchical port to be disconnected.

Default Value
None
Usage Conditions
The DisconnectPort custom object script is used in the CustomObject wrapper.
Example
In the following example, the net connected to port Y on instance U123 is to be disconnected.
CustomObject(DisconnectPort) {
Var(Port): U123/Y;
}
CustomObject (Gate1Connect)
The Gate1Connect custom object script instantiates and connects a one-input logic gate
specified by the ModuleName variable.
Syntax
Var(ModuleName): <ModuleName>;
Var(InstanceName): <InstanceName>;
Var(OutputPin): <OutputPinName>;
Var(Input0Pin): <Input0PinName>;
Var(Input0Connection): <HierarchicalNetName>;
Var(OutputConnection): <HierarchicalNetName>;
}
• ModuleName — specifies the name of the library cell to be instantiated.

• InstanceName — specifies the name to be given to the library cell instantiated by the
custom object script.
• OutputPin — specifies the name of the output pin on ModuleName.
• Input0Pin — specifies the name of the input0 pin on ModuleName.
• Input0Connection — specifies the net or port to be connected to the input0 pin.
• OutputConnection — specifies the net or port to be connected to the output pin.
Default Value
None
Usage Conditions
The Gate1Connect custom object script is used in the CustomObject wrapper.
Example
In the following example, U1/ABC is connected to the output port IV110. If U1/ABC is an
input port, it is disconnected before being connected.
Var(ModuleName) : IV110;
Var(InstanceName): myInv;
Var(OutputPin) : Y;
Var(Input0Pin) : A;
Var(Input0Connection): U1/ABC;
Var(OutputConnection) : Net2;
}
CustomObject (Gate1InterceptDestination)
The Gate1InterceptDestination custom object script intercepts a net driving a given input port
specified by the InterceptPort variable. The input port is then driven by OutputPinName of the
ModuleName gate, and the original net driving InterceptPort is then connected to
Input0PinName of the ModuleName gate.
Syntax
CustomObject (Gate1InterceptDestination) {
Var(InterceptPort): <HierarchicalInputPorttName>;
}

• InterceptPort — specifies the name of the hierarchical port to be intercepted.
Default Value
None
Usage Conditions
The Gate1InterceptDestination custom object script is used in the CustomObject wrapper.
Example
In the following example, an inverter is added between the input port U1/ABC and the net
currently driving the port.
CustomObject (Gate1InterceptDestination) {
Var(OutputPin): Y;
Var(Input0Pin): A;
}
CustomObject (Gate1InterceptSource)
The Gate1InterceptSource custom object script intercepts a net driven by a given output port
specified by the InterceptPort variable. The net is then driven by OutputPinName of the
ModuleName gate. Then, the original output port InterceptPort is connected to the
Input0PinName port of the ModuleName gate.
Syntax
CustomObject (Gate1InterceptSource) {
Var(InterceptPort): <HierarchicalOutputPortName>;
}

Default Value
None
Usage Conditions
The Gate1InterceptSource custom object script is used in the CustomObject wrapper.
Example
In the following example, an inverter is added between the output port U1/ABC and the net
currently being driven by the port.
CustomObject (Gate1InterceptSource) {
Var(OutputPin): Y;
Var(Input0Pin): A;
}
CustomObject (Gate2Connect)
The Gate2Connect custom object script instantiates and connects an two-input logic gate
specified by ModuleName variable.
Syntax
Var(OutputPin): <OutputPin>;
Var(Input1Pin): <Input1PiName>;
}

• Input0Connection — specifies the net or port to be connected the input0 pin.
Default Value
None
Usage Conditions
The Gate2Connect custom object script is used in the CustomObject wrapper.
Example
In the following example, if U1/ABC is an input port, it is first disconnected before being
connected to the output port OR210.
Var(ModuleName): OR210;
Var(InstanceName): Gate2Connect1;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(Input0Connection): Net2;
Var(Input1Connection): U1/DEF;
Var(OutputConnection): U1/ABC;
}
CustomObject (Gate2InterceptDestination)
The Gate2InterceptDestination custom object script intercepts a net driving a given input port
specified with the InterceptPort variable. The input port is then driven by OutputPinName of
the ModuleName gate. Then, the original net driving InterceptPort is connected to
Input0PinName of the ModuleName gate. The second input, Input1PinName, is connected to
the net specified by Input1Connection.
Syntax
Var(InterceptPort): <HierarchicalInputPort>;
}


Default Value
None
Usage Conditions
The Gate2InterceptDestination custom object script is used in CustomObject wrapper.
Example
In the following example, the FUNC_MODE signal is intercepted going to U1 with an OR gate
and connects the other input of the OR gate to an user-DR-bit of the TAP.
Var(ModuleName): OR210;
Var(InstanceName): FM_OR1;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(InterceptPort): U1/FUNC_MODE;
userDRBits[2];
}
CustomObject (Gate2InterceptSource)
The Gate2InterceptSource custom object script intercepts a net driven by a given output port
ModuleName gate. Then, the original output port InterceptPort is connected to the
Input0PinName port of the ModuleName gate, and Input1PinName will be driven by the net
specified in Input1Connection.
Syntax
CustomObject(Gate2InterceptSource) {
}

Default Value
None
Usage Conditions
The Gate2InterceptSource custom object script is used in CustomObject wrapper.
Example
In this example, the Gate2InterceptSource custom object script intercepts the forceDis output
of the TAP with a 2-input OR gate and connects the other input to the output of an input pad
buffer.
CustomObject(Gate2InterceptSource) {
Var(InstanceName): FD_OR;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(InterceptPort): LVISION_JTAP_INTS/forceDis;
Var(Input1Connection): TRIEN_BUF/Y;
}
CustomObject (InterceptTopLevelPort)
The InterceptTopLevelPort custom object script intercepts a top-level port and provides a new
driver specified by the NewDriver variable.
Syntax
CustomObject(InterceptTopLevelPort) {
Var(NewDriver): <HierarchicalNetName>;
Var(TopLevelPort): <HierarchicalPortName>;
}
• NewDriver — specifies what the new driver will be for the TopLevelPort’s fanout.
• TopLevelPort — specifies the top-level port to be intercepted.
Default Value
None
Usage Conditions
The InterceptTopLevelPort custom object script is used in the CustomObject wrapper.
Example
In the following example, myMux1/Y is to be the new driver for the top-level port DIN.
CustomObject(InterceptTopLevelPort) {
Var(NewDriver): myMux1/Y;
Var(TopLevelPort): DIN;
}
CustomObject (ModuleInstantiate)
The ModuleInstantiate custom object script instantiates the module specified by the
ModuleName variable.
Syntax
}

Default Value
None
Usage Conditions
The ModuleInstantiate custom object script is used in the CustomObject wrapper.
Example
In the following example, the ModuleInstantiate custom object script instantiates the module
COUNTER with the instance name myCounter.
Var(ModuleName): COUNTER;
Var(InstanceName): myCounter;
}
CustomObject (MoveConnection)
The MoveConnection custom object script moves a net to a new port.
Syntax
CustomObject(MoveConnection) {
Var(Source): <HierarchicalNetName>;
Var(Destination): <HierarchicalPortName>;
}
• Source — specifies the hierarchical net to be moved.

• Destination — specifies the hierarchical port the Source net is to be moved to.
Default Value
None
Usage Conditions
The MoveConnection custom object script is used in the CustomObject wrapper.
Example
In the following example, the MoveConnection custom object script moves the port net tlb_i1/
fifo_inst/rst to the AND gate tlb_i1/fifo_rst_gate/I0.
CustomObject(MoveConnection) {
Var(Source): tlb_i1/fifo_inst/rst;
Var(Destination): tlb_i1/fifo_rst_gate/I0;
}
CustomObject (Mux2Connect)
The Mux2Connect custom object script instantiates and connects the multiplexer you specified
using the ModuleName variable.
Syntax
CustomObject(Mux2Connect) {
Var(SelectPin): <SelectPinName>;
Var(SelectConnection): <HierarchicalNetName>;
}

• SelectPin — specifies the name of the select pin on ModuleName.
• SelectConnection — specifies the net or port to be connected to the select pin.
Default Value
None
Usage Conditions
The Mux2Connect custom object script is used in the CustomObject wrapper.
Example
In the following example, the Mux2Connect custom object script instantiates and connects
myMux1. (If U1/ABC is an input port, it is first disconnected before being connected to the
output port of MU111.)
CustomObject(Mux2Connect) {
Var(ModuleName): MU111;
Var(InstanceName): myMux1;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(SelectPin): S;
Var(SelectConnection): Net3;
Var(OutputConnection): U1/ABC;
}
CustomObject (Mux2InterceptDestination)
The Mux2InterceptDestination custom object script intercepts a net driving a given input port
you specified using the InterceptPort variable. The input port is driven by OutputPinName of
the ModuleName gate. Then, the original net connected to InterceptPort is connected to
Input0PinName of the ModuleName gate. The second input, Input1Piname, and the select input,
SelectPinName, are connected to the nets specified by Input1Connection and
SelectConnection.
Syntax
CustomObject(Mux2InterceptDestination) {
Var(InterceptPort): <HierarchicalInputPortName>;
}

Default Value
None
Usage Conditions
The Mux2InterceptDestination custom object script is used in the CustomObject wrapper.
Example
In the following example, the Mux2InterceptSource custom script intercepts input port U1/A
with a multiplexer. The B and the S inputs of the multiplexer are connected to user-DR bits of
the TAP controller.
CustomObject(Mux2InterceptDestination) {
Var(InstanceName): MyMux1;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(SelectPin): S;
Var(InterceptPort): U1/A;
userDRBit[0];
Var(SelectConnection): LVISION_JTAP_INST/
userDRBit[1];
}
CustomObject (Mux2InterceptSource)
The Mux2InterceptSource custom object script intercepts a net driven by a given output port
ModuleName gate. Then, the original output port InterceptPort is connected to Input0PinName
of the ModuleName gate. The second input, Input1PinName, and the select input,
SelectPinName, are connected to the nets specified by Input1Connection and
SelectConnection.
Syntax
CustomObject(Mux2InterceptSource) {
Var(OutputPin): <OutputPinNAme>;
}

Default Value
None
Usage Conditions
The Mux2InterceptSource custom object script is used in the CustomObject wrapper.
Example
In the following example, the Mux2InterceptSource custom script intercepts the output port
U1/FM with a multiplexer. The B and the S inputs of the multiplexer are connected to user-DR-
bits of the TAP controller.
CustomObject(Mux2InterceptSource) {
Var(InstanceName): FM_MUX;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(SelectPin): S;
Var(InterceptPort): U1/FM;
userDRBit[0];
Var(SelectConnection): LVISION_JTAP_INST/
userDRBit[1];
}
CustomObject (PortToPortConnect)
The PortToPortConnect custom object script first disconnects any nets connected to the
Destination port, and then it creates a connection between the two specified ports.
Syntax
CustomObject(PortToPortConnect) {
Var(Source): <HierarchicalPortName>;
Var(Destination): <HierarchicalPortName>;
}
• Source — specifies the hierarchical port that will be connected to Destination.

• Destination — specifies the hierarchical port that is to be disconnected and then
connected to the Source port.
Default Value
None
Usage Conditions
The PortToPortConnect custom object script is used in the CustomObject wrapper.
Example
In the following example, myMux1/Y is to be connected to the AND gate myAND2/A. If there is
already a connection to the myAND2/A input port, then that connection will be broken. If there
is already a connection to the myMux1/Y, then that connection will be maintained after
connecting the input port A of myAND2 to the output Y of myMux1.
CustomObject(PortToPortConnect) {
Var(Source): myMux1/Y;
Var(Destination): myAND2/A;
}
DecodeSource
The DecodeSource property specifies whether or not the specified opcode to be decoded is
from user-IR bits or from user-DR bits.
Syntax
DecodeSource: (IR) | DR;
• IR — specifies that the opcode to be decoded is from the user-IR bits in the TAP
instruction register.
• DR — specifies that the opcode to be decoded is from user-DR bits in the TAP data
register.
Default Value
The default value is IR.
Usage Conditions
The DecodeSource property is used in the UserSignal wrapper.
IR or DR are the only valid options.
Example
Code: 5'bxxx00;
DecodeSource: IR;
}
DedicatedBGroupName
The optional DedicatedBGroupName property creates a new boundary-scan group for a user
data register that you want to bypass with the multiple bonding option feature. If a mux is
necessary at the beginning of this boundary-scan group, an RTL Verilog module description is
created and will be instantiated along with the BScanShiftIn pin of the register instance.
Syntax
where BGroupName is a new identifier that is used only in the BondingOption:

BypassedBGroups property.
Default
None
Usage Conditions
The DedicatedBGroupName property is used in the BoundaryScan: InternalBScanSegment
wrapper of the .etassemble configuration file.
• The dedicated boundary-scan group cannot be used in the .pinorder file or in the Sides
wrapper of the .etassemble configuration file.
• If a dedicated boundary-scan group is not created, the user data register will go into the
boundary-scan group of the pin that precedes the user data register in the boundary-scan
register.
• Tessent BoundaryScan does not create a corresponding Verilog RTL file for the user
data register contained in the dedicated boundary-scan group because no new hardware
is created. The user data register must already exist in the design.
Example
Refer to the InternalBScanSegment wrapper and the InsertBeforePin property for examples
showing the DedicatedBGroupName property.
DefaultBSDLUserIRbitCode
The DefaultBSDLUserIRbitCode property enables you to specify to which value userIRBits
should default for boundary-scan related instruction opcodes in the BSDL file.
Syntax
where x is a string of user bits that defines the default userIRBit values.
Default Value
The default value is x'bl, where x is the number of userIRBits.
Usage Conditions
The DefaultBSDLUserIRbitCode property is used in the TAP wrapper.
• You can use this property to define the default userIRBit values used by boundary-scan
related instructions, such as EXTEST and SAMPLE.
• When you specify this property, the code is automatically picked up by ETAssemble as
it creates the.bsdl file.
• When the code is smaller than the number specified for NumberUserBits property, the
code is applied to the least significant userIRBits, while the remaining unspecified
userIRBits default to 1.
Example
If the DefaultBSDLUserIRbitCode property is set to 3'b010 and the NumberUserBits property
is set to 5, then userIRBits[2:0] in the BSDL file is 010 and userIRBits[4:3] defaults to 11. The
resulting BSDL file contains an INSTRUCTION_OPCODE as follows:
attribute INSTRUCTION_OPCODE of TOP: entity is

"IDCODE (111111111111111111111110)," &
"BYPASS (000000000000000000000000, 111111111111111111111111)," &
"EXTEST (110101111111111111101000)," &
"SAMPLE (110101111111111111111000)," &
"PRELOAD (110101111111111111111000)," &
"HIGHZ (110101111111111111001111)," &
"CLAMP (110101111111111111101111) " ;
DeviceIdCode
The DeviceIdCode property specifies the value representing the 16-bit device ID code field
within the IEEE 1149.1-compliant device ID register.
Syntax
DeviceIdCode: 16'b<deviceId> | (16'h<deviceId>);
Default Value
The default value is 16'h0000.
If the properties DeviceIdCode, ManufacturersIdCode, and RevisionCode are not specified,

then the IEEE 1149.1 ID register is not generated and the bypass register is selected when the
TAP register resets.
Usage Conditions
The DeviceIdCode property is used in the TAP and WTAP wrappers and in the
BoundaryScan:BondingOption wrapper.
In the TAP and WTAP wrappers, the following usage conditions apply:
• If the device ID information is specified in both the .pinorder and .etassemble files, the
value in the .etassemble file has the highest priority.
• If the device ID information is not specified in either file, the default value is all 0’s.
In the BoundaryScan:BondingOption wrapper, the following usage conditions apply:
• If you specify DeviceIdCode, you also must specify EnableSignal.

• The DeviceIdCode value is used in the TAP RTL description and the BSDL file,
overriding the DeviceIdCode specified in the TAP wrapper.
• If you do not specify DeviceIdCode, the default value is the DeviceIdCode in the TAP
wrapper.
Example
The example below specifies that a device ID register is generated for the design:
DeviceIdCode: 16’ha5f0;
Refer to the BondingOption wrapper for an example using the DeviceIdCode property to
override an existing device ID code value.
DICellMapping
The DICellMapping wrapper enables you to specify the instance path to where you want
ETAssemble to instantiate specific Dedicated Isolation (DI) cells.
Syntax
Configuration(xxx) {
LogicTest {
DICellMapping {
...
}
}
}
• ELTCore_Port_RE — is a scalar, a bus element, a bus range, or a regular expression

whose corresponding DI cell is to be instantiated in the provided instance. If the port is a
bus it must be specified with a single bit, as a bus range, or as a regular expression.
• DICell_Location — is a valid Verilog or VHDL instance name where the DI cells will
be instantiated.
Default Value
If a pin is not specified, the DI cell location will be “.”, meaning, the root module, unless the
ETPlanner DICellParentInstance property is specified.
Usage Conditions
The DICellMapping wrapper is used in the LogicTest wrapper of the .etassemble file.
Specified ports that do not have a DI cell are ignored.
Example
In this example, the following identifies that the DI cells inserted for pins ENA and DIN1[31:0]
are to be instantiated within the instances blockA_inst and blockB_inst/subBlock respectively.
DICellMapping {
ENA : blockA_inst;
DIN1[31:0] : blockB_inst/subModule;
}
Note
If the specified regular expression contains special matching characters, such as parentheses
'()', then the regular expression should be within double quotes. This is illustrated in the
example below.
This example shows how regular expressions can be used to match some or all of the ports
DIN[31:0], DOUT[31:0], and address[7:0].
DICellMapping {
"D(IN|OUT)\[0\]" : blockB_inst; // matches DIN[0] and DOUT[0]
add.* : blockB_inst; // matches address[7:0]
}
DirectScanEnablePin
The DirectScanEnablePin property specifies the top-level enable pin that will be used gain
access to the multi-chains through a direct scan protocol.
Syntax
DirectScanENablePin (<polarity>) : <pinName>;
where the valid values are as follows:
• pinName — specifies the top-level pin that will be used as the direct scan-enable pin.
• polarity — specifies the polarity of the direct scan-enable pin. Specify 1 for an active
high pin and 0 for an active low pin.
Default
None
Usage Conditions
The DirectScanEnablePin property is used in the LogicTest wrapper.
The property can only be specified when logic test is being added and when running
ETAssemble on the Top module of the chip. The pin is added to the .etassemble Configuration
File Structure wrapper in the .rulea overrides file and to the Assert wrapper in the .designe
override file.
Example
The example below specifies that the top-level pin DSEN is an active high direct-scan enable
pin:
LogicTest {
DirectScanEnablePin (1): DSEN;
}
DisableChildBisrChains
The DisableChildBisrChains property specifies the list of the BISR chain segments from
lower-level block modules that are not used in the current design hierarchy. By default, all BISR
segments from lower-level block modules are connected automatically to the parent block
module and up to the BISR controller in the top-level. The BISR chain segments listed in the
DisableChildBisrChains property are tied off at the child module instance boundary and are not
used for memory repair. If the lower-level block module has multiple power domain groups, the
BISR chain segments for each power domain group can be disabled individually.
The DisableChildBisrChains property takes the same instance list format as the ChainOrdering
property. If you run ETAssemble once without the DisableChildBisrChains property, the
default ChainOrdering property value is echoed in the etassemble.log file. Then you can copy
selected lower-level block BISR segments from the etassemble.log file and paste them into the
.etassemble configuration file.
Note
Once you specify a BISR segment in the DisableChildBisrChains property, you cannot
specify the same BISR segment in the ChainOrdering property.
Syntax
where listOfInstances specifies a comma-separated list of hierarchical paths to the scan-in ports
of BISR segments on child blocks containing BISR chains.
Default Value
None
Usage Conditions
Example
The following example instructs ETAssemble to disable the lower-level module BISR chains
identified by their BISR scan-in port Block1_I1/Block1/LV_BISR_SI and Block2_I2/
LV_BISR_SI_A2; all other BISR chains inside Block1_I1 and Block2_I2 will be connected to
the top-level BISR controller:
MemBISR {
DisableChildBisrChains:
"Block2_I2/LV_BISR_SI_A2";
…
}
EmbeddedBScanPortNaming
The EmbeddedBScanPortNaming wrapper is used in the EBScan (Embedded Boundary Scan)
flow and enables you to specify the names of the ports related to the embedded boundary scan.
This wrapper is only used by ETAssemble when run with the command line option -
genTemplate On to create an .etassemble file to be used in the EBScan (Embedded Boundary
Scan) flow.
Syntax
The following syntax specifies EmbeddedBScanPortNaming wrapper and its properties:
ForceDisable: <ForceDisable>;
ClockBscan: <ClockBscan>;
UpdateBscan: <UpdateBscan>;
ShiftBscan: <ShiftBscan>;
ShiftBscan2Edge: <ShiftBscan2Edge>;
SelectJtagInput: <SelectJtagInput>;
SelectJtagOutput: <SelectJtagOutput>;
BscanSelect: <BscanSelect>;
BscanShiftIn: <BScanSI>;
BscanShiftOut: <BScanSO>;
ExternalAuxOut: <AuxOut>;
ExternalAuxOutEn: <AuxOutEn>;
ExternalAuxIn: <AuxIn>;
ExternalAuxInEn: <AuxInEn>;
InitClk: <InitClk>;
ACSignal: <ACSignal>;
ACMode: <ACModePor>;
}
where each property specifies the name of the primary input embedded boundary-scan port.
Default Value
For each property, the default value is shown in the table below:
Table 3-3. EmbeddedBScanPortNaming Defaults
Property Name Default Value
ForceDisable ForceDisable
ClockBscan ClockBScan
UpdateBscan UpdateBscan
ShiftBscan ShiftBscan
ShiftBscan2Edge ShiftBscan2Edge
SelectJtagInput SelectJtagInput
SelectJtagIOutput SelectJtagOutput
Table 3-3. EmbeddedBScanPortNaming Defaults (cont.)

BscanSelect BscanSelect
BscanShiftIn BScanSI
BscanShiftOut BScanSO
ExternalAuxOut AuxOut
ExternalAuxOutEn AuxOutEn
ExternalAuxIn AuxIn
ExternalAuxInEn AuxInEn
InitClk InitClk
ACSignal ACSignal
ACMode ACMode
ACModeSel ACModeSel
Usage Conditions
The EmbeddedBScanPortNaming wrapper is located in the BoundaryScan wrapper.
Unless the default names interfere with design port names, the default values should be used.
Example
The following example shows how to use myInitClk as the port carrying the function InitClk.
InitClock: myInitClk;
}
EnableBCell
The EnableBCell wrapper allows you to specify the output pin connections of an enable cell.
Syntax
EnableBCell {
Name: <blibname>;
Ports {//Repeatable
<portName>;
}
}
• Name: blibName — specifies the name of an enable cell. blibName can be generic class
(subclass) reference, such as EN, EN(M), or the name of your custom enable cell (which
is the name of the Cell wrapper in your custom .blib file description).
• Ports — specifies the name of the output pins controlled by this enable cell. Only one
enable cell of type blibName is instantiated for each Ports wrapper. This enable cell
controls all output pins listed in the wrapper.
• portName — specifies the name of the output pin to which the enable cell is connected.
portName supports wildcard expressions such as OUT*, OUT%d[3:8], or OUT[7:0].
Default Value
None
Usage Conditions
The EnableBCell wrapper is used in the BoundaryScan wrapper.
Example
The following syntax specifies the output pin connections to enable cells myENcell1 and
EN(H).
BoundaryScan {
EnableBCell {
Name: myENcell1;
Ports {
OUT*;
}
}
EnableBCell {
Name: EN(H);
Ports {
IO%d(3:8);
}
}
}
EnableSignal
The following sections provide information on the usage of the EnableSignal property:
• BoundaryScan Usage
• BoundaryScan:BondingOption Usage
BoundaryScan Usage
The optional EnableSignal property enables you to assign a specific name to an enable
boundary-scan cell so that it can be referenced in the Overrides wrapper. While the boundary-
scan cells associated with the data path of an output or inout pad can be referenced by
specifying the corresponding top-level pins, this is the only mechanism available to reference
the boundary-scan cell associated with the control path of an output or inout pad.
Syntax
EnableSignal (<enableName>): <hierEnableName>;
• enableName — is any valid HDL identifier that serves as a name for an enable
boundary-scan cell intercepting your net which controls the enable on an output or an
inout pad.
• hierEnableName — is an existing output port in your design which drives the Enable
signal going to an output or inout pad.
Default Value
None
Usage Conditions
The EnableSignal property is used in the BoundaryScan wrapper.
• Use this property to reference an enable boundary-scan cell in the Overrides wrapper.
Normally, the enable boundary-scan cells are automatically assigned a name by
chiptestAssemble.
• enableName cannot be specified as EN<x> where x is a positive integer. For example,
you may not specify enableName as EN2.
Example
In this example, the boundary-scan cell connected to the pad enable net core1/DOUT_EN is
given a label MyEnable. In the Overrides wrapper, this boundary-scan cell is specified to be
belonging to UpdateGroup 3 and having the subclass H.
BoundaryScan {
EnableSignal (MyEnable): core1/DOUT_EN;
Overrides {
MyEnable: UpdGroup(3), SubClass(H);
}
}
BoundaryScan:BondingOption Usage
The EnableSignal property defines an active high signal that enables a bonding option. You
must specify this property if the BondingOption wrapper has at least one BypassedBGroups,
DeviceIdCode, or RevisionCode property.
Syntax
where InternalNet is an existing signal in the design that will be connected to the TAP.
Default Value
None
Usage Conditions
The EnableSignal property is used in the BoundaryScan:BondingOption wrapper.
• This property is mandatory if the BondingOption wrapper has at least one

BypassedBGroups, DeviceIdCode, or RevisionCode property. Otherwise, the
EnableSignal property has no effect and a warning is issued.
• If the enable signals of all bonding options are low, the complete chain is visible to the
TAP, and the IDCODE defaults to the IDCODE defined in the TAP wrapper. Enable
signals must be internal to the design (for example, the output ports of a fuse box), and
therefore, they must be defined by their hierarchical names in the design.
Example
For an example of the EnableSignal in the BoundaryScan:BondingOption wrapper, see the
BondingOption wrapper.
ExplicitAuxPortConnections
The ExplicitAuxPortConnections wrapper in the .etassemble file enables you to specify the
instance paths to which you want ETAssemble to connect the AuxIn, AuxOut, and AuxEn pins.
Syntax
Configuration (xxx) {
LogicTest {
AuxIn(#) : <TopLevelInputPin>;
AuxOut(#) : <TopLevelOutputPin>;
AuxEn : <TopLevelOutputPin>;
}
AuxIn(#) : <InputPinInstancePath>;
AuxOut(#) : <OutputPinInstancePath>;
AuxEn : <OutputPinInstancePath>;
}
}//End of LogicTest
}
...
InstancePath (<instanceRelativeToRootModule>){ ExplicitAuxPortConnections
{
AuxIn(#) : <InputPinInstancePath>;
AuxOut(#) : <OutputPinInstancePath>;
AuxEn : <OutputPinInstancePath>;
}
}
}//End of LowerBlockModule
}
Where:
• InputPinInstancePath and OutputPinInstancePath are valid Verilog or VHDL instance

names.
• TopLevelInputPin and TopLevelOutputPin are chip-level pin names.
Default Value
None
Usage Conditions
This property is used in the following two wrappers in the .etassemble file:
• LogicTest
• The ConnectionStatus wrapper is only required when the TCMGen tool is used in the
flow and is not necessary for designExtract.
• The LogicTest: ExplicitAuxPortConnections wrapper handles the top-level AuxIn/

AuxOut/AuxEn ports. The LowerBlockModule: InstancePath:
ExplicitAuxPortConnections wrapper takes care of auxiliary ports from lower-level
ELT cores or blocks:
o For lower-level blocks, you can request that AuxOut(0) have no connection by
specifying an empty ExplicitAuxPortConnections wrapper. However, you must
also define the DESIGNE_ERROR_TO_WARNING environment variable to prevent
a tracing error from this unconnected port by designExtract.
o For ELT cores, all AuxIn, AuxOut, and AuxEn pins must be connected.
• The ExplicitAuxPortConnections wrapper cannot be used when the AuxInPortList or
AuxOutPortList property is specified in either the .etassemble or .etplan files.
Example
The following example instructs ETAssemble to make the connection of the AuxIn(0) input pin
of the tlb_inst1/elt_inst lower-level instance to a dedicated output port of a multiplexer
(tlb_inst1/mux_i/o1). Similarly, the AuxOut(0) output pin of the same ELT instance will be
connected to the tlb_inst1/buf3/i0 internal input pin and the AuxEn output will be connected to
the tlb_inst1/buf4/i0 internal input pin.
LowerBlockModule (elt) {
InstancePath (./tlb_inst1/elt_inst) {
AuxIn(0) : ./tlb_inst1/mux_i/o1;
AuxOut(0) : ./tlb_inst1/buf3/i0;
AuxEn : ./tlb_inst1/buf4/i0;
}
}
}
}
ExplicitCompStatConnection
The ExplicitCompStatConnection property enables you to specify the instance path to which
you want to connect the memory BIST test result port (CMP_STAT or MBIST_GO).
Syntax
ExplicitCompStatConnection: <InputPinInstancePath>;
Where:
• InputPinInstancePath is a valid Verilog or VHDL instance name.
Default Value
None
Usage Conditions
The ExplicitCompStatConnection property is used in the Configuration global wrapper of the
.etassemble file.
• The specified instance must exist in the design before running ETAssemble.
• The ExplicitCompStatConnection property can not be used together with the
CompStatPort property. Any module-specific settings of CompStatPort defined in
ETPlanner will also collide with this property and will result in an error issued by
designExtract.
• When the TCMgen tool is used instead of designExtract, you must specify the
ExplicitCompStatConnectionStatus property. This property provides supporting
information about the top-level pin mapped to the instance pin pointed to by the
ExplicitCompStatConnection property.
• The ExplicitCompStatConnection property only affects memory BIST controllers
inserted by the current make embedded_test target. Any CMP_STAT or AuxOut/AuxEn
ports of child memory BIST blocks are not affected. To affect child memory BIST block
connections, use the ExplicitAuxPortConnections wrapper.
Example
The following example instructs ETAssemble to connect the MemoryBIST CompStat port to a
specific input pin, in0, of the tlb_inst0 instance. In this case, the
ExplicitCompStatConnectionStatus property has been also specified describing the top-level
port comp_stat that is mapped with the tlb_inst0/in0 instance. When designExtract is used, this
extra information is not necessary.
ExplicitCompStatConnection: ./tlb_inst0/in0;
ExplicitCompStatConnectionStatus: comp_stat; // Optional.
// Only for TMCGen.
...
}
ExplicitCompStatConnectionStatus
The ExplicitCompStatConnectionStatus property provides supporting information about the
top-level pin mapped to the instance pin pointed to by the ExplicitCompStatConnection
property.
Syntax
ExplicitCompStatConnectionStatus: <TopLevelOutputPin>;
Where:
• TopLevelOutputPin is a chip-level pin name.

Default Value
None
Usage Conditions
The ExplicitCompStatConnectionStatus property is used in the Configuration global wrapper
of the .etassemble file.
• The ExplicitCompStatConnectionStatus property is used with the

ExplicitCompStatConnection property and is only needed when the TCMgen tool is
used instead of designExtract.
Example
The following example instructs ETAssemble to connect the MemoryBIST CompStat port to a
specific input pin in0 of the tlb_inst0 instance. In this case, the
ExplicitCompStatConnectionStatus property is also specified to describe the top-level port
comp_stat that is mapped with the tlb_inst0/in0 instance. When designExtract is used, this extra
information is not necessary.
ExplicitCompStatConnection: ./tlb_inst0/in0;
ExplicitCompStatConnectionStatus: comp_stat; // Optional.
// Only for TMCGen.
...
}
ExternalAuxInPins
The ExternalAuxInPins property is used when running ETAssemble with -flow EBScan on a
module that you want to use as a pad-boundary-scan combo cell. You list pins that you want to
be equipped with AuxIn logic. Such AuxIn pins will be usable as AuxSI and AuxIn pins by
ETAssemble during the normal top-level Boundary Scan Insertion process. You can also use the
ExternalAuxInPins property when running ETAssemble with -flow EBScan on a sub-physical
region that you will later use as a Siemens EDA LV Block or ELTCore module. Those
ExternalAuxInPins will not be used for the internal AuxIn connections but rather by test mode
logic found outside the physical region. This might be useful if your top-level does not have
pins available for AuxIn connections.
An AuxIn will connect to newly created pins on the module. The name of the AuxIn Data pin is
specified with the AuxIn property and the name of the optional AuxIn Enable pin is specified
with the AuxInEn property in the EmbeddedBScanPortNaming wrapper.
Syntax
ExternalAuxInPins:<Input/InoutPinName> \
where Input/inoutPinName specifies the name of an input or inout pin listed in the PadIOPins
list.
Usage Conditions
This property is used in the BoundaryScan wrapper when running ETAssemble in EBScan
flow.
• This property is only used when running ETAssemble with -flow EBScan.
• A pin can be both listed as an InternalAuxInPins and an ExternalAuxInPins.
• An ExternalAuxInPins can also be an ExternalAuxOutPins.
Example
The following example specifies that the pin A1 and the four bused pins B[3] to B[0] are to be
equipped with AuxIn logic available from outside the module.
BoundaryScan {
ExternalAuxInPins: A1, B[3:0];
}
ExternalAuxOutPins
The ExternalAuxOutPins property is used when running ETAssemble with -flow EBScan on a
module that you want to use as a pad-boundary-scan combo cell. You list pins that you want to
be equipped with AuxOut logic. Such AuxOut pins will be usable as AuxSO and AuxOut pins by
ETAssemble during the normal top-level Boundary Scan Insertion process. You can also use the
ExternalAuxOutPins property when running ETAssemble with -flow EBScan on a sub-
physical region that you will later use as a Siemens EDA LV Block or ELTCore module. Those
ExternalAuxOutPins will not be used for the internal AuxOut connections but rather by test
mode logic found outside the physical region. This might be useful if your top level does not
have pins available for AuxOut multiplexing.
An AuxOutPin will connect to newly created pins on the module. The name of the AuxOut
Data pin is specified with the AuxOut property and the name of the AuxOut Enable pin is
specified with the AuxOutEn property of the EmbeddedBScanPortNaming wrapper.
Syntax
ExternalAuxOutPins: <Output/InoutPinName> \
where Output/InoutPinName specifies the name of an output or inout pin listed in the
PadIOPins list.
Usage Conditions
This property is used in the BoundaryScan wrapper when running ETAssemble in EBScan
(Embedded Boundary Scan) flow.
• A pin can be both listed as an InternalAuxOutPins and an ExternalAuxOutPins.
• An ExternalAuxOutPins can also be an ExternalAuxInPins.
Example
The following example specifies that the pin A1 and the four bused pins B[3] to B[0] are to be
equipped with AuxOut logic.
BoundaryScan {
ExternalAuxOutPins: A1, B[3:0];
}
ExtScanPortNaming
The ExtScanPortNaming wrapper is used to override the default external scan port names
created on the core or block.
Syntax
ExtScanPortNaming {
TestMode: <string>;
CaptureDisable: <string>;
CDLaunchAligned: <string>;
CDScanEnable: <string>;
ScanIn: <string>;
ScanOut: <string>;
ShiftPhase: <string>;
BurstEnable: <string>;
TestFlopReset: <string>;
SetTest: <string>;
IddqEnable: <string>;
Default Value
None
Usage Conditions
The specified port names must be simple scalar names. Specified port names can be used only
once in this wrapper.
Example
The following example shows the use of the ExtScanPortNaming wrapper:
ExtScanPortNaming {
TestMode: LV_TM;
CaptureDisable: LV_CD;
CDLaunchAligned: LV_CDLA;
CDScanEnable: LV_CDSE;
ScanIn: LV_SI;
ScanOut: LV_SO;
ShiftPhase: LV_shiftPhase;
BurstEnable: LV_burstEnable;
TestFlopReset: LV_testFlopReset;
ResetTest: LV_ResetTest;
SetTest: LV_SetTest;
SetResetTest: LV_SetResetTest;
IddqEnable: LV_IddqEnable;
TestPointEnable: LV_TREN;
}
ExternalFuseBox
The ExternalFuseBox property specifies where the fuse box is located with respect to the BISR
controller module:
• When the fuse box ExternalFuseBox is set to Yes, ETAssemble makes the connections
between the BISR controller and the fuse box interface. The fuse box interface must
exist in the design before ETAssemble is executed. All inputs of the fuse box interface
must be initially tied down, and all outputs must be left open.
• When the fuse box is internal to the BISR controller, no extra connections are required.
Syntax
• Yes — specifies that the fuse box is instantiated outside the BISR controller.
• No — specifies that the fuse box is instantiated inside the BISR controller.
Default Value
Usage Conditions
This property is used in the MemBISR wrapper of the .etassemble file.
• The ExternalFuseBox property is required if at least one memory in the design has self-
repair capability.
• If ExternalFuseBox is set to Yes and FuseBoxProgrammingMethod is set to Buffered,
you must specify the MemBISR: Connections: FuseBoxBufferTransfer property.
• If ExternalFuseBox is set to Yes and the fuse box interface has a reset port, a port must
be specified with the Connections: FuseBoxInterfaceReset property, in which case
FuseBoxInterfaceResetPresent: Yes is automatically inferred. If the ExternalFuseBox
property is set to No and the FuseBoxInterfaceResetPresent property is set to Yes, the
name of the reset port on the generic fuse box interface module must be FBreset.
Example
This example specifies to ETAssemble that the fuse box is instantiated outside the BISR
controller.
MemBISR {
}
}
EXTESTPulseMinDuration
The EXTESTPulseMinDuration property specifies the minimum duration in seconds of the
Idle TAP state when the TAP instruction EXTEST_PULSE is executed.
Syntax
ACMode{
}
where real number is a real number expressed with an exponent—for example, 1.0e-3, 4.7e-04.
Default Value
None
Usage Conditions
The EXTESTPulseMinDuration property is used in the ACMode wrapper in the
BoundaryScan wrapper.
ETAssemble copies this value into the AIO_EXTEST_Pulse_Execution attribute within the
generated .bsdl file.
The omission of this property indicates that there is no requirement on the Pulse length.
Note
IEEE 1149.6 permits the value to be TCK, followed by an integer indicating the number of
TCK cycles. Generally, this method is not used to specify a real time number since it
depends on the actual TCK frequency. ETAssemble supports only the real time alternative.
Example
The following example shows the EXTESTPulseMinDuration property:
EXTTestPulseMinDuration: 1.14e-3;
EXTESTTrainExecution
The EXTESTTrainExecution wrapper specifies the minimum number of TCK pulses (Train)
and the maximum duration in seconds of the Idle TAP state when the TAP instruction
EXTEST_TRAIN is executed.
Syntax
ACMode{
Train: <N>;
}
}
• N — is an integer number greater than zero.

• real number — is a real number expressed with an exponent—for example, 1.0e-3, 4.7e-
04.
Default Value
None
Usage Conditions
The EXTESTTrainExecution wrapper is used in the ACMode wrapper in the BoundaryScan
wrapper.
Note that if you do not specify the EXTESTTrainExecution wrapper, ETAssemble will not
generate the AIO_EXTEST_Train_Execution attribute in the .bsdl file, and the Dot6ACInput
and Dot6ACOutput tests will not attempt to run the TRAIN instruction
Example
The following example shows the EXTESTTrainExecution wrapper:
Train: 4;
}
FeedThroughMux
The FeedThroughMux property allows you to specify ports on your blocks that are to be treated
as feed-throughs for designExtract when a corresponding input port is enabled. This is useful if
you are tiling the ELT core modules at the top and using feed through wires in other ELT core
modules to connect the BIST and auxiliary ports of an ELT module to the central TAP module
and/or boundary-scan cells.
Syntax
FeedThroughMux (<PO>): <PI_in>, <PI_en>[, <PI_in>. <PI_en>]*;
Default Value
None
Usage Conditions
This property is used in the main Configuration wrapper of the .etassemble file.
• The FeedTroughMux property is repeatable.

• PI and PO in the list cannot be reused in other FeedTroughMux propeties or in the
FeedThroughs wrappers.
• The width of the PO and PI_in pins must be equal.
• PI_en must only have a width of 1.
• PI_in must be followed by its corresponding PI_en.
Example
This example specifies to ETAssemble that the input pins FTIN1[2:0] and FTIN2[2:0] feed
through to the output pins FTOUT[2:0] then the corresponding input pins FTEN1 and FTEN2
are enabled.
FeedThroughMux (FTOUT[2:0]): FTIN1[2:0], FTEN1, FTIN2[2:0], FTEN2;
}
FeedThroughs
The FeedThroughs wrapper allows you to specify ports on your blocks that are to be treated as
feed throughs for designExtract. This is useful if you are tiling the ELT core modules at the top
and using feed through wires in other ELTCore modules to connect the BIST and auxiliary
ports of an ELT module to the central TAP module and/or boundary-scan cells.
Syntax
Configuration (designName) {
FeedThroughs {
<inPins> : <outPins>;
}
}
where inPins and outPins can be a scalar, a bus element, or a bus range .
Default Value
None
Usage Conditions
This wrapper is used in the main Configuration wrapper of the .etassemble file.
The width between inPins and outPins must be equal.
Example
This example specifies to ETAssemble that the input pins DIN[3:0], FT1, and FT2[0] are fed
through to the output pins DOUT[3:0], FTOUT1, and FTOUT2[0], respectively.
FeedThroughs{
DIN[3:0] : DIN[3:0];
FT1: FTOUT1;
FT2[0] : FTOUT2[0];
}
}
ForceExternalLTest
The ForceExternalLTest wrapper allows you to force a clock domain to be equipped or not for
external test mode.
Syntax
LogicTest {
}
}
If a domain has a periphery flop count of 0, and it is listed in the ForceExternalLTest wrapper
as Yes then ETAssemble treats it as if it had a periphery flop count greater than 0.
If a domain has an periphery flop count greater than 0, and it is listed in the
ForceExternalLTest wrapper as No then ETAssemble treats it as if it had a periphery flop
count of 0. Also, any Dedicated Isolation cells declared using the same label are modified to use
another domain.
Default Value
None
Usage Conditions
This wrapper is used in the LogicTest wrapper.
You might have to use this wrapper is if you have memory IO pins feeding directly to pins of an
ELTCore. Since ETChecker is run on the netlist before memory BIST has been inserted, it does
not see the periphery flops that will be inserted on the path of the memory IO pins to the pins of
the ELTCore.
Example
This example specifies that the clock domain with label CLK1 should be prepared for external
testing.
LogicTest {
CLK1: Yes;
}
}
FuseBoxAccessPipeline
The FuseBoxAccessPipeline property instructs ETAssemble to pipeline the FuseBoxAccess
signal. The insertion of a pipeline register provides one extra clock cycle delay for the
FuseBoxAccess signal that goes to the fuse box. The pipeline register also aligns
FuseBoxAccess to the corresponding FuseBoxAddress. In absence of pipelining,
FuseBoxAccess rises one clock cycle ahead of FuseBoxAddress. This property can only be
specified when ExternalFuseBox: Yes; has already been specified.
Syntax
FuseBoxAccessPipeline: (Yes) | No;
• Yes — specifies that one pipeline stage is added on the FuseBoxAccess signal to the
external fuse box interface.
• No — specifies that no pipeline stages are added on the FuseBoxAccess signal to the
external fuse box interface.
Default Value
The default value is Yes.
Usage Conditions
This property is used in the MemBISR wrapper of the .etassemble file when ExternalFuseBox:
Yes; has been specified.
Example
This example specifies to ETAssemble that no pipeline stages are added on the FuseBoxAccess
signal to the external fuse box interface.
MemBISR {
FuseBoxAccessPipeline: No;
}
}
FuseBoxAddressBits
The FuseBoxAddressBits property specifies the size of the fuse box address bus. This property
is used to generate the BISR controller circuitry and assembly instructions.
Syntax
FuseBoxAddressBits: <size>;
where size is an integer number that specifies the fuse box address bits.
Default Value
Usage Conditions
Example
This example specifies to ETAssemble that the fuse box has 9 address bits. Therefore, a
maximum of 512 can be used for FuseBoxSize.
MemBISR {
FuseBoxAddressBits: 9;
}
}
FuseBoxInterfaceResetPresent
The FuseBoxInterfaceResetPresent property indicates whether a reset signal is present on the
fuse box interface module. When Yes, the fuse box controller connects the FBreset output port
to the port specified with the MemBISR: Connections: FuseBoxInterfaceReset property. The
fuse box reset signal is applied on the fuse box interface and released during the Autonomous
and FuseBoxAccess run modes.
Syntax
FuseBoxInterfaceResetPresent: Yes | (No);
• Yes — indicates that a reset signal is present on the fuse box interface module.
• No — indicates that a reset signal is not present on the fuse box interface module.
Default Value
The default is No.
Usage Conditions
• If the ExternalFuseBox property is set to Yes and the fuse box interface has a reset port,
a port must be specified with the Connections: FuseBoxInterfaceReset property, in
which case FuseBoxInterfaceResetPresent: Yes is automatically inferred.
• If the FuseBoxInterfaceResetPresent property is set to Yes, and the ExternalFuseBox
property is set to No, the name of the reset port on the generic fuse box interface module
must be FBreset.
Example
The following example specifies that the fuse box is located inside the fuse box controller and
that the fuse box interface module has an interface reset signal. The example instructs
ETAssemble to connect the fuse box controller’s reset signal to the fuse box interface FBreset
port.
MemBISR {
FuseBoxInterfaceResetPresent: Yes;
...
}
FuseBoxProgrammingMethod
The FuseBoxProgrammingMethod property supports fuse boxes that do not allow
programming of individual fuses at randomly specified addresses. Because each fuse bit cannot
be addressed directly, all fuse bits must be read or programmed as a group. When this property
is set to Buffered, a signal called programFB is generated by the BISR controller and connected
to the fuse box interface. This signal is used to initiate the final fuse box programming. Extra
steps are also added to the patterns to transfer and program the fuses during the
SelfFuseBoxProgram and FuseBoxAccess programming modes.
Syntax
where Buffered indicates that the fuse box values are first written to a fuse buffer located in the
fuse box interface before performing the actual programming of the fuses.
Default Value
The default value is Unbuffered.
Usage Conditions
If FuseBoxProgrammingMethod is set to Buffered and ExternalFuseBox is set to Yes, you

must specify the MemBISR:Connections:FuseBoxBufferTransfer property.
Example
The following example specifies that the fuse box values are first written to a fuse buffer before
the actual programming occurs:
MemBISR {
FuseBoxProgrammingMethod: Buffered;
}
}
FuseBoxSize
The FuseBoxSize property specifies the maximum number of fuses that are available in the fuse
box for memory self-repair. The FuseBoxSize value can be less than the actual fuse box size
when the fuse box is shared for other purposes in the design. The FuseBoxSize value must be
large enough to accommodate repair information for all repairable memories in your design.
Syntax
where size is an integer number that specifies the maximum number of fuses that will be used to
store memory repair information.
Default Value
The default value is 2 FuseBoxAddressBits.
Usage Conditions
The FuseBoxSize value must not exceed the maximum number of fuses addressable with the
number of address bits specified by the FuseBoxAddressBits property. The maximum available
fuse box address is calculated using the following formula:
FuseBoxSize < 2 FuseBoxAddressBits
The BISR controller always stores memory repair information starting at address 0. All other
user information must be stored starting at address <size>. Fuses at address <size> and up to
2FuseBoxAddressBits can be accessed through the TAP (RunMode: FuseBoxAccess;) or a
user-defined mechanism. If you want to map the fuse box controller addresses to a different
portion of the address space, you must manually modify the fuse box interface.
Example
The following example specifies to ETAssemble that up to 512 fuses can be used to store
memory repair information:
MemBISR {
FuseBoxSize: 512;
}
}
FuseBoxWriteDuration
The FuseBoxWriteDuration property allows you to specify the fuse box write duration. This
property is used to set the starting delay value in the delay counter register inside the BISR
controller. The fuse box write duration delay should be provided in the fuse box datasheet.
Syntax
FuseBoxWriteDuration: <time> < s | ms | us | (ns)

| ps>;
where time specifies an integer number corresponding to the write duration delay.
Default Value
The default value is 7000ns.
Usage Conditions
Example
This example specifies that BISR controller should pause for 8us for each value written to the
fuse box.
Configuration {
MemBISR {
FuseBoxWriteDuration: 8us;
Connections {
...
}
}
}
IddqEnable
The IddqEnable property controls the port name that is used when an external scan IddqEnable
port is needed on the core.
Syntax
IddqEnable: x;
where x is a string.
Default Value
The default value is LV_IddqEnable.
Usage Conditions
The IddqEnable property is used in the ExtScanPortNaming wrapper.
The specified port name must be a simple scalar name.
Example
The following example defines the port name as LV_extTM.
ExtScanPortNaming {
IddqEnable: LV_IddqEnable;
}
InjectTCKOnClockSources
The sections below provide detailed information on the following usage of the
InjectTCKOnClockSources property in the following wrappers:
• WTAP Wrapper Usage

• TAP Wrapper Usage
WTAP Wrapper Usage
The InjectTCKOnClockSources property specifies which clocks inside block modules should
be equipped with a TCK multiplexer in order to support memory BIST Compstat diagnostics.
Syntax in the WTAP Wrapper

WTAP {
}
• Always — indicates that all clock sources defined in ETChecker and used by memory
BIST controllers inside block modules should be equipped with a TCK multiplexer.
• InternalSourceOnly — indicates that all clock sources defined in ETChecker, used by
memory BIST controllers, and not driven by a primary input of the block modules
should be equipped with a TCK multiplexer. This option assumes the TCK multiplexer
will be inserted in the top level for the clock sources driven by a primary input of the
block modules.
• Never — indicates that no clock sources defined in ETChecker should be equipped with
a TCK multiplexer inside block modules.
Default Value
The default value is InternalSourceOnly.
Usage Conditions
This property is used in the WTAP wrapper.
The logic test mode is not implemented. Specifying this property in the presence of the
LogicTest wrapper has no effects.
Example
The following example requests that all clocks be equipped with a TCK multiplexer.
WTAP {
InjectTCKOnClockSources: Always;
}
TAP Wrapper Usage

The InjectTCKOnClockSources property specifies which clocks inside in top level of the chip
should be equipped with a TCK multiplexer in order to support memory BIST Compstat
diagnostics.
Syntax
TAP {
InjectTCKOnClockSources: All | (TopMemBistClocks) | None;
}
• All — indicates that all clock sources defined in ETChecker should be equipped with a
TCK multiplexer. You only need to set it to All when you have clocks used for memory
BIST controllers inside child blocks. Those clocks are not used for top-level memory
BIST controllers, and you have not already injected a TCK mux for those clocks inside
the blocks. The presence of the TCK mux inside the child blocks is controlled by the
InjectTCKOnClockSourcesInBlocks property in the EmbeddedTestDefaults wrapper of
the .etplan File or the InjectTCKOnClockSources property in the WTAP wrapper of
the .etassemble file.
• TopMemBistClocks — indicates that all clock sources defined in ETChecker and used
by memory BIST controllers in the top level should be equipped with a TCK
multiplexer. It assumes that memory BIST controllers inside child blocks are already
equipped with a TCK multiplexer, or that their clock source is also used by top-level
memory BIST controllers.
None — indicates that no clock sources defined in ETChecker should be equipped with
a TCK multiplexer.
Default Value
The default value is TopMemBistClocks.
Usage Conditions
This property is used in the TAP wrapper.
The logic test mode is not implemented. Specifying this property in the presence of the
LogicTest wrapper has no effects.
Example
The following example request that all clocks be equipped with a TCK multiplexer.
TAP {
InjectTCKOnClockSources: All;
}
InsertAfterPin
The following sections provide information on the usage of the InsertAfterPin property:
• BoundaryScan: InternalBScanCells: Cell Usage

• BoundaryScan: InternalBScanSegment Usage
BoundaryScan: InternalBScanCells: Cell Usage
The InsertAfterPin property indicates where to insert the cell inside the boundary-scan chain.
InsertAfterPin means insert the cell one position closer to TDI (TDO?) than the boundary-scan
cell(s) that belong to the specified pinName.
Syntax
where pinName is the name of a top-level pin.
Default Value
None
Usage Conditions
The InsertAfterPin property is used in the BoundaryScan: InternalBScanCells: Cell wrapper
of the .etassemble configuration file.
If many cells are specified with the same InsertAfterPin value, they are inserted in the same
order as they are listed under the InternalBScanCells wrapper. The top-most specified cell is
the cell closest to the TDI (TDO?) pin; the bottom-most cell is the cell closest to TDO (TDI?).
BoundaryScan: InternalBScanSegment Usage

For boundary-scan segments that consist entirely of internal boundary-scan cells, the
InsertAfterPin property or the InsertBeforePin property must be specified to determine the
position of the boundary-scan segment in the user data register.
Syntax
Default Value
None
Usage Conditions
The InsertAfterPin property is used in the BoundaryScan: InternalBScanSegment wrapper of
the .etassemble configuration file.
Example
The following example, which shows how to use the InsertAfterPin property, adds four internal
segments to the boundary-scan register. All four instances can be of the same module or
different modules as long as each module is described in a .lvbscan file.
BoundaryScan {
InternalBScanSegment(reg_i) {
InsertBeforePin: IN2;
}
InternalBScanSegment(core_i/reg_i) {
}
InternalBScanSegment(reg_i2) {
InsertBeforePin: OUT6;
DedicatedBGroupName: REG2;
}
InsertAfterPin: OUT5;
}
BondingOption(default) {
}
BondingOption(withoutReg) {
EnableSignal: fuse_i/en;
BypassedBGroups: REG3;
}
…
}
…
}
The registers reg_i and core_i/reg_i are inserted into the boundary-scan register before the
boundary-scan cell belonging to IN2. First is reg_i followed by core_i/reg_i.
The other two registers, reg_i2 and reg_i3, are inserted into the boundary-scan register between
the boundary-scan cells belonging to OUT5 and OUT6. First is reg_i3 followed by reg_i2.
Registers reg_i2 and reg_i3 have boundary-scan groups assigned to them, and register reg_i3 is
bypassed in the bonding option withoutReg.
InsertBeforePin
The following sections provide information on the usage of the InsertBeforePin property:
• BoundaryScan: InternalBScanCells: Cell Usage

• BoundaryScan: InternalBScanSegment Usage
BoundaryScan: InternalBScanCells: Cell Usage
The InsertBeforePin property indicates where to insert the cell inside the boundary-scan chain.
InsertBeforePin means insert the cell one position closer to TDI than the boundary-scan cell(s)
that belong to the specified pinName.
Syntax
Default Value
None
Usage Conditions
The InsertBeforePin property is used in the BoundaryScan: InternalBScanCells: Cell wrapper
of the .etassemble configuration file.
If many cells are specified with the same InsertBeforePin value, they are inserted in the same
order as they are listed under the InternalBScanCells wrapper. The top-most specified cell is
the cell closest to the TDI pin; the bottom-most cell is the cell closest to TDO.
BoundaryScan: InternalBScanSegment Usage

For boundary-scan segments that consist entirely of internal boundary-scan cells, the
InsertBeforePin property or InsertAfterPin property must be specified to determine the position
of the boundary-scan segment in the user data register.
Syntax
Default Value
None
Usage Conditions
The InsertBeforePin property is used in the BoundaryScan: InternalBScanSegment wrapper of
the .etassemble configuration file.
Example
The following example, which shows how to use the InsertBeforePin property, adds four
internal segments to the boundary-scan register. All four instances can be of the same module or
different modules as long as each module is described in a .lvbscan file.
BoundaryScan {
InternalBScanSegment(reg_i) {
}
InternalBScanSegment(core_i/reg_i) {
}
InsertBeforePin: OUT6;
}
InsertAfterPin: OUT5;
}
BondingOption(default) {
}
BondingOption(withoutReg) {
EnableSignal: fuse_i/en;
BypassedBGroups: REG3;
}
…
}
…
}
The registers reg_i and core_i/reg_i are inserted into the boundary-scan register before the
boundary-scan cell belonging to IN2. First is reg_i followed by core_i/reg_i.
The other two registers, reg_i2 and reg_i3, are inserted into the boundary-scan register between
the boundary-scan cells belonging to OUT5 and OUT6. First is reg_i3 followed by reg_i2.
Registers reg_i2 and reg_i3 have boundary-scan groups assigned to them, and register reg_i3 is
bypassed in the bonding option withoutReg.
InstanceName
The InstanceName property enables you to specify the instance name of a TAP/WTAP.
ETAssemble uses this value as the instance name of the TAP/WTAP module in the assembled
design.
Syntax
where instanceName is a valid Verilog or VHDL instance name.
Default
The default value is LVISION_WTAP_INST for a WTAP controller and LVISION_JTAP_INST
for a TAP controller.
Usage Conditions
The InstanceName property is used in the WTAP and TAP wrappers.
The instance name must be unique and should not clash with any other module.
The TopLVHWParentInstance specified in the ETPlanner step is ignored for this property. The
specified InstanceName value is an absolute path in the current design. If you want to have the
TAP's instance inside TopLVHWParentInstance, you have to pass a hierarchical path to
InstanceName property.
Example
The example creates an instance of the WTAP controller named MyWTAP:
WTAP {
InstanceName: MyWTAP;
}
InstancePath
The InstancePath wrapper specifies the instance path of a lower block module. ETAssemble
uses this value as the instance path of the lower block module in the assembled design.
Syntax
InstancePath (<instancePath>) {
AuxIn(#) : <pin>;
AuxOut(#) : <pin>;
AuxEn : <pin>;
}
}
where instancePath is a valid Verilog or VHDL instance name.
Default
None
Usage Conditions
The InstancePath wrapper is used in the LowerBlockModule wrapper.
Example
The following example shows LowerBlockModule TLB_INS/BOB_INST within instance
BOB:
LowerBlockModule (TLB_INS/BOB_INST) {
InstancePath (BOB) {
AuxInPortList: A,B[4:2],C%[1:0];
AuxOutPortList: A,B[4:2],C%[1:0];
}
InternalAuxInPins
The InternalAuxInPins property is used when running ETAssemble with -flow EBScan on a
sub-physical region that you will later use as a Siemens EDA LV block or ELTCore module.
You list pins that you want to be equipped with AuxIn logic. Such AuxIn pins will be usable as
AuxSI pins for your embedded logicTest multi-scan ATPG mode. The use of local AuxIn pins is
optional but when used prevents having to route the AuxIn pins to pad found outside the
physical region, thus, saving your precious top-level routing resources for your functional
mode. The AuxIn and AuxEn pins will be tied down on the pins on the BGroup and will be
reconnected later when running ETAssemble in a Block or ELTCore.
Syntax
InternalAuxInPins: <Input/InoutPinName> \
where Input/InoutPinName specifies the name of an input or inout pin listed in the PadIOPins
list.
Usage Conditions
This property is used inside the BoundaryScan property when running ETAssemble in EBScan
• This property is optional and only used when running ETAssemble with -flow EBScan.
• If you are running on a module that you just want to use as a pad-boundary-scan combo
cell rather than on a sub-physical region, use the ExternalAuxInPins list instead.
• A pin can be both listed as an InternalAuxInPins and an ExternalAuxInPins.
• An InternalAuxInPins cannot also be an ExternalAuxOutPins.
Example
BoundaryScan {
InternalAuxInPins: A[3:0],B2,B1;
}
InternalAuxOutPins
The InternalAuxOutPins property is used when running ETAssemble with -flow EBScan on a
sub-physical region that you will later use as a Siemens EDA LV block or ELTCore module.
You list pins that you want to be equipped with AuxOut logic. Such AuxOut pins will be usable
as AuxSO pins for your embedded logicTest multi-scan ATPG mode or as your CompStat output
for memory BIST diagnostic. The use of local AuxOut pins is optional but when used prevents
having to route the AuxOut pins to pad found outside the physical region, thus, saving your
precious top-level routing resources for your functional mode. The AuxOut and AuxEn pins will
be tied down on the pins on the BGroup and will be reconnected later when running
ETAssemble in a Block or ELTCore.
Syntax
InternalAuxOutPins: <Output/InoutPinName> \
[, <output/InoutPinName>,...];
where Output/InoutPinName specifies the name of an output or inout pin listed in the
PadIOPins list.
Usage Conditions
This property is used in the BoundaryScan wrapper when running ETAssemble in the EBScan
• If you are running on a module that you just want to use as a pad-bscan combo cell
rather than on a sub-physical region, use the ExternalAuxOutPins list instead.
• A pin can be both listed as an InternalAuxOutPin and an ExternalAuxOutPin.
• An InternalAuxOutPin cannot also be an ExternalAuxOutPin.
Example
The following example specifies that pin A1 and the four bused pins B[3] to B[0] are to be
equipped with AuxOut logic.
BoundaryScan {
InternalAuxOutPins: A1, B[3:0];
}
InternalBScanCells
The InternalBScanCells wrapper enables you to insert boundary-scan cells anywhere on the
boundary-scan chain and use them to control specified internal signals.
The advantages of controlling an internal signal with an internal boundary-scan cell, as opposed
to a userIRbit or a userDRbit, are as follows:
• The specified name of the boundary-scan cell is documented in your output BSDL file
so that third-party JTAG-based test tools can access them.
• If your target control signals belong to special IO pad control inputs, such as enabling a
pull-up or changing the output slew rate, the internal boundary-scan cell can be placed
close to the pad to avoid congestion problems between the TAP controller and the target
pad.
• You can specify for the cell to intercept a functional signal and replace it with its test
value when running in boundary-scan mode (TAP instruction is EXTEST or SAMPLE).
You do not need to add this interception logic manually.
Syntax
}
}
Default
None
Usage Conditions
The InternalBScanCells wrapper is used in the BoundaryScan wrapper.
Specify one InternalBScanCells: Cell wrapper per internal cell that you want to insert in the
design.
Example
The following wrapper creates two internal boundary-scan cells and connects them to existing
netlist library cells. Arbitrary meaningful names are given to these cells — SlewRate0,
SlewRate1, and myControl. The names are used by the cell’s instance name in the BSDL file
information and in the ETVerify configuration file (JtagVerify wrapper test specifications).
BoundaryScan {
....
Cell(SlewRate1) {
InsertBeforePin: DOUT[1];
SafeValue: 0;
Connection: DOUT_1_pad/SL1;
}
Cell(SlewRate0) {
InsertBeforePin: DOUT[1];
SafeValue: 0;
Connection: DOUT_1_pad/SL0;
}
Cell(myControl) {
InsertBeforePin: JOE;
SafeValue: 1;
Connection: myCore/BiasControl/CTL;
SJOMuxPresent: Off;
}
}
}
InternalBScanSegment
For a .lvbscan file description of a boundary-scan segment consisting entirely of internal cells,
the mandatory InternalBScanSegment wrapper defines the position of the new boundary-scan
segment in the boundary-scan register. The InternalBScanSegment wrapper also specifies
whether Tessent BoundaryScan should create a dedicated boundary-scan group for the segment.
Note
If the user data register does not need to be in the boundary-scan segment, the user data
register should be connected directly to the TAP and activated with a user instruction.
Syntax
InternalBScanSegment (<instancePath>) { // repeatable

}
where instancePath is mandatory and specifies the instance containing the user data register.
The .lvbscan file is then associated with the instance via its module name and describes the pins
that must be hooked up. This enables a design to use the same .lvbscan file and the same module
multiple times.
Default
None
Usage Conditions
The InternalBScanSegment wrapper is used in the BoundaryScan wrapper of the .etassemble
configuration file.
Example
The following example includes a sample .pinorder file and .lvbscan file, and shows how to add
a boundary-scan register with the InternalBScanSegment wrapper.
Example .pinorder file

//PinName PinNumber PinType Side
//------- --------- ------- ----
TDI 1 - North
TDO 2 - -
TCK 3 - -
TMS 4 - -
TRST 5 TRST -
IO1 6 - -
IO1N 7 - -
IO2 8 - South
IO3 9 - -
The design has two boundary-scan groups: North with one differential IO pin and South with
two IO pins.
Example .lvbscan file

/* handmade file for a register to be hooked up into the boundary-scan
chain as internal cells */
BScanCells {
BScanCell(register) {
// Combo cell ports

ClockBscan: clk;
ShiftBScan: se;
BScanSegment(0) {
BScanShiftIn: si;
BScanShiftOut: so;
BScanShiftInRetime: Off;
BSDLInfo (reg0) {
Function: internal;
CellInfo: BC_0;
SafeValue: 0;
}
BSDLInfo (reg1) {
Function: internal;
CellInfo: BC_0;
SafeValue: X;
}
BSDLInfo (reg2) {
Function: internal;
CellInfo: BC_0;
SafeValue: 1;
}
BSDLInfo (reg3) {
Function: internal;
CellInfo: BC_0;
SafeValue: 0;
}
} // End of BScanSegment
} // End of BScanCell
} // End of BScanCells
The example .lvbscan file describes a four-bit register inside the module register.
To add the four-bit register into the boundary-scan register, specify the following in the
.etassemble configuration file:
BoundaryScan {
InternalBScanSegment(core_i/register_i) {
InsertBeforePin: IO2;
DedicatedBGroupName: Register0;
} // End of InternalBScanSegment
…
} // End of BoundaryScan
…
} // End of Configuration
The four-bit register on the instance path core_i/register_i is inserted into the boundary-scan
register before the boundary-scan cell(s) belonging to IO2. The four internal cells are in a new
boundary-scan group called Register0. The IO2 pin is the start of a new boundary-scan group
called South so that no boundary-scan group is interrupted with the boundary-scan group
Register0. The design now has three boundary-scan groups—North, Register0, and South—in
that order, in the boundary-scan register.
LocalAuxInPinList
The LocalAuxInPinList property is used when running ETAssemble on a Siemens EDA LV
block or ELTCore module. You list pins that are already equipped with AuxIn logic. The
LocalAuxInPinList will be used as AuxSI pins for your embedded logicTest multi-scan ATPG
mode contained within the block or ELTCore module. Using LocalAuxInPinList is optional
but, when used, prevents having to route the AuxIn pins to a pad found outside the physical
region, therefore saving your precious top-level routing resources for your functional mode.
You can use ETAssemble with -flow EBScan to pre-equip your pads with boundary-scan cells
and auxiliary input logic.
Syntax
LocalAuxInPinList: <Input/InoutPinName> \
where Input/InoutPinName specifies the name of an input or inout pin on the block or ELTCore
module which is pre-equipped with internal AuxIn logic.
Usage Conditions
This property is used in the Configuration wrapper when running ETAssemble with -flow
Block on a block or ELTCore module.
If you specify one pin with the LocalAuxInPinList property, you must specify enough pins to
supply all of your AuxIn requirements within the block or ELTCore module.
Example
Configuration {
LocalAuxInPinList: A[3:0],B2,B1;
}
LocalAuxOutPinList
The LocalAuxOutPinList property is used when running ETAssemble on a Siemens EDA LV
block or ELTCore module. You list pins that are already equipped with AuxOut logic. The
LocalAuxOutPinList will be used as AuxSO pins for your embedded logicTest multi-scan
ATPG mode contained within the block or ELTCore module or as your CompStat output for
memory BIST diagnostic. Using LocalAuxOutPinList is optional but, when used, prevents
having to route the AuxOut pins to a pad found outside the physical region, therefore saving
your precious top-level routing resources for your functional mode.
You can use ETAssemble with -flow EBScan to pre-equip your pads with boundary-scan cells
and auxiliary output logic
Syntax
LocalAuxOutPinList: <Output/InoutPinName> \
where Output/InoutPinName specifies the name of an output or inout pin on the block or
ELTCore module which is pre-equipped with internal AuxOut logic.
Usage Conditions
If you specify one pin with the LocalAuxOutPinList property, you must specify enough pins to
supply all of your AuxOut requirements within the block or ELTCore module.
Example
Configuration {
LocalAuxOutPinList: A[3:0],B2,B1;
}
LogicTest
The LogicTest wrapper groups properties that define some specific logic test options, such as
auxiliary scan inputs and outputs for the multi-chain logic test configuration.
Syntax
LogicTest {
DirectScanEnablePin (<polarity>): <pin>;
}
DICellMapping {
...
}
}
AuxIn(#) : <pin>;
AuxOut(#) : <pin>;
AuxEn : <pin>;
}
AuxIn(#) : <pin>;
AuxOut(#) : <pin>;
AuxEn : <pin>;
}
...
}
}
Usage Conditions
The LogicTest wrapper is used in the main Configuration wrapper.
LowerBlockModule
The LowerBlockModule wrapper groups properties that define some specific logic test
options, such as auxiliary scan input and outputs for the multi-chain logic test configuration.
Syntax
InstancePath (<instanceRelativeToRootModule>){
AuxIn(#) : <pin>;
AuxOut(#) : <pin>;
AuxEn : <pin>;
}
}
}
where instanceRelativeToRootModule is a valid Verilog or VHDL instance name.
Usage Conditions
The LowerBlockModule wrapper is used in the main Configuration wrapper.
ManufacturersIdCode
The ManufacturersIdCode property specifies the value representing the 11-bit manufacturer
ID code field within the IEEE 1149.1-compliant device ID register.
Syntax
ManufacturersIdCode: 11'b<mfgId> | (11'h<mfgId>);
Default Value
Usage Conditions
The ManufacturersIdCode property is used in the TAP and WTAP wrappers.
If the properties DeviceIdCode, ManufacturersIdCode, and RevisionCode are not specified, the
IEEE 1149.1 ID register is not generated and the bypass register is selected when the TAP
register resets.
Example
ManufacturersIdCode: 11'h07A;
ManufacturersIdCode: 11'b00001111010;
MaximumTime
The MaximumTime property specifies the maximum duration in seconds of the Idle TAP state
when the TAP instruction EXTEST_TRAIN is executed The MaximumTime value is copied
into the AIO_EXTEST_Train_Execution attribute within the generated .bsdl file.
Syntax
BoundaryScan {...
ACMode{
EXTESTTrainExecution{...
MaximumTime: <realNumber>;
}
}
}
where realNumber is a real number expressed with an exponent—for example, 1.0e-3, 4.7e-04.
Default Value
None
Usage Conditions
The MaximumTime property is used in the EXTESTTrainExecution: BoundaryScan wrapper.
Example
In the following example sets the maximum duration to 25 nanoseconds:
MaxBisrChainLength
The MaxBisrChainLength property specifies the maximum BISR chain length you want the
BISR controller to support. This property is optional. The default value of this property
automatically adjusts to either 4 * (2ZeroCounterBits) or ((2 16 - 1) = 65535), whichever is larger.
The value is intentionally set much larger than the actual maximum BISR chain length to
accommodate an arbitrarily large ECO inside a child block without having to regenerate the
BISR controller at the top. The controller automatically adjusts to the new length every time a
power-up operation or power-up emulation operation is performed.
Syntax
where int is an integer.
Default Value
The default value automatically adjusts to either 4 * (2ZeroCounterBits) or ((2 16 - 1) = 65535),
whichever is larger.
Usage Conditions
• You rarely need to specify this property; normally, the default value is correct. If you do
specify a value, you must make sure it is equal to or larger than the actual BISR chain
length of the circuit. Otherwise, the circuit will not be functional. MaxBisrChainLength
determines how long the BISR controller will wait for the header bit that is used to
measure the actual BISR chain length. If the header bit is not detected after this period of
time, the controller sets the DONE output to 1 and the GO output to 0.
• You may need to use this property if you are building your chip top level and some or all
of your child blocks are not yet equipped with BISR segments. In this case, the
computed longest BISR chain length may not reflect the proper future length because
ETAssemble assigns a default value to incomplete blocks. If not set, the default
MaxBisrChainLength value is calculated as described in the summary description
above. For more information, see the “Performing Parent Memory BIST Insertion
Before Child Regions” section in the “Flow Variations” appendix of the Tessent
MemoryBIST User’s and Reference Manual.
Example
The following example instructs ETAssemble to build a BISR controller that supports a BISR
chain length of up to 30k bits:
MemBISR {
MaxBisrChainLength: 30k;
}
MaxFuseBoxProgrammingSessions
The MaxFuseBoxProgrammingSessions property enables hard incremental repair in more than
one test insertion (for example, wafer probe, package test, final test, or system test). This
property is useful for increasing the yield of circuits exhibiting parametric defects under certain
process, voltage, or temperature conditions.
Syntax
where int is the maximum number of times the fuses can be programmed.
Default Value
Usage Conditions
• Typically, MaxFuseBoxProgrammingSessions is set to a relatively small value (2 to 4,

for example) to minimize the number of fuses required.
• A rule check determines if the test insertion flags plus the test insertion pointers require
more fuses than the FuseBoxSize. For more information, refer to “Incremental Repair
Case” in the “Determining the Fuse Box Size” section of the Tessent MemoryBIST
User’s and Reference Manual.
Example
The following example specifies that the fuse box can be programmed up to four times:
MemBIST {
...
MaxFuseBoxProgrammingSessions: 4;
...
}
MaxScanChainSize
The MaxScanChainSize property enables you to segment the boundary-scan register by
specifying a maximum segment length if LogicBIST is not used.
Syntax
where int is an integer less than the length of the boundary-scan register.
Default Value
None
Usage Conditions
This property is used in the BoundaryScan wrapper.
If you use this property along with LogicBIST, you will receive a warning that the boundary-
scan chain is segmented according to the MaxChainLength property setting in the .etplan file.
Example
The following example divides the boundary-scan register into segments with a maximum
length of 13 boundary-scan cells:
BoundaryScan {
MaxScanChainSize: 13;
Overrides {
}
}
...
}
MaxTCKFreq
The MaxTCKFreq property specifies the upper limit for the TCK frequency at which the chip
is guaranteed to work. This information does not influence the generation of the hardware
objects; the information is simply recorded in the BSDL file. The specified TCK frequency is
also used in the synthesis script of the TAP controller.
Syntax
MaxTCKFreq: x;
where x is a real number.
Default Value
The default value is 10.0e6.
Usage Conditions
The MaxTCKFreq property is used in the TAP wrapper.
When ETAssemble generates the BSDL file, it includes the following line in the BSDL file:
Attribute TAP_SCAN_CLOCK of TCK:signal is

(<clockRecord>)
where clockRecord, as defined by IEEE 1149.1 standard, is a pair of values
• The first value is a real number that gives the maximum operating frequency for TCK in
Hertz. You can control the value by specifying the MaxTCKFreq property.
• The second value is always set to both values, which means that both edges of the clock
are used in the 1149.1 TAP protocol.
Example
This example specifies that the maximum TCK frequency is limited to 20 MHz.
MaxTCKFreq: 20.0e6;
MaxWRCKFreq
The MaxWRCKFreq property specifies the upper limit for the WTAP clock (WRCK) frequency
at which the chip is guaranteed to work. This information does not influence the generation of
the RTL version of the hardware objects. The specified WRCK frequency is used in the
synthesis script of the WTAP controller.
Syntax
MaxWRCKFreq: <x>;
where x is a real number.
Default
The default value is 10.0e6.
Usage Conditions
The MaxWRCKFreq property is used in the WTAP wrapper.
The operating speed (frequency) of the WTAP can be controlled using this property. The value
is a real number that gives the maximum operating frequency for WRCK in Hertz.
Example
This example specifies that the maximum WRCK frequency is limited to 20 MHz.
WTAP {
MaxWRCKFreq: 20.0e6;
}
MemBISR
The MemBISR wrapper inside the .etassemble file includes syntax specific to built-in self-
repair.
Syntax
MemBISR {
Connections {
BisrDone: <Port>;
BisrGo: <Port>;
FuseBoxInterfaceReset: <Port>;
PowerDomainGroupBusy (<int>): <Net|Port>;
PowerDomainGroupDone (<int>): <Net|Port>;
PowerDomainGroupEnable (<int>): <Net|Port>;
PowerDomainGroupReset (<int>): <Net|Port>;
}
}
FuseBoxAccessPipeline: (On) | Off;
FuseBoxAddressBits: <size>
FuseBoxInterfaceResetPresent: Yes | (No); //Yes is inferred when
FuseBoxInterfaceReset is specified and
ExternalFuseBox is Yes
FuseBoxWriteDuration: <time>;
PowerDomainGroupPriority: <string>;
}
Usage Conditions
This wrapper is used in the .etassemble file.
Example
This example instructs ETAssemble that the fuse box is internal to the BISR controller and
provides information on the connections between the fuse box and the controller.
MemBISR {
Connections {
FunctionalRepairClockLabel: CLK_i;
FunctionalRepairEnable: sysRstn/SysRstOut;
ProgrammingVoltagePin: vddq_i;
}
}
}
NumberBistPorts
The NumberBistPorts property specifies the number of controllers connected to the TAP. If
you are using more than five controllers in your design, then you must specify a valid value for
this property.
Syntax
NumberBistPorts: x;
where x is an integer between 1 and 1024 for a WTAP controller and larger than or equal to 5
for a TAP controller.
Default Value
Usage Conditions
The NumberBistPorts property is used in the TAP and WTAP wrappers.
Example
The example below specifies that seven controllers are connected to the TAP:
NumberBistPorts: 7;
NumberOfInternalScanChains
The NumberOfInternalScanChains property specifies the number of internal scan chains that
are to be created.
Syntax
where int is a number of internal scan chains.
Default Value
The default value is 0, i.e. ETAssemble calculates a value based on the max chain size
calculated by ETPlanner.
Usage Conditions
This property is used in the LogicTest wrapper.
Example
The example below specifies that 2 internal scan chains are to be created:
LogicTest {
NumberOfInternalScanChains: 2;
...
}
NumberOfPeripheryScanChains
The NumberOfPeripheryScanChains property specifies the number of periphery scan chains
that are to be created.
Syntax
where int is a number of periphery scan chains.
Default Value
The default value is 0, i.e. ETAssemble calculates a value based on the max chain size
calculated by ETPlanner.
Usage Conditions
This property is used in the LogicTest wrapper.
Example
The example below specifies that 2 periphery scan chains are to be created:
LogicTest {
NumberOfPeripheryScanChains: 2;
...
}
NumberUpdateGroups
The optional NumberUpdateGroups property specifies the number of groups into which the
boundary-scan cells are organized for update purposes.
Syntax
NumberUpdateGroups: x;
where x is an integer number.
Default Value
The default value is 1, indicating that the boundary-scan cells are not organized into separate
update groups.
Usage Conditions
These usage conditions apply to NumberUpdateGroups:
• You use this option to control ground-bounce problems. When a value greater than 1 is
specified for the NumberUpdateGroups property, ETAssemble creates multiple
updateBscan and selectJTAGOutput signals with staggered delays in the TAP controller
and equally distributes these signals among the boundary-scan cells. As a result, each
group of boundary-scan cells is updated at a slightly different time during the update
cycle.
• The technology-dependent delay cell must be specified using the
UpdateGroupDelayElement wrapper in the input cell library file.
Example
The following syntax specifies 4 as the number of update groups.
BoundaryScan {
NumberUpdateGroups: 4;
}
NumberUserBits
The NumberUserBits property specifies the number of additional bits by which ETAssemble
changes the size of the TAP instruction register. The minimum width of the TAP instruction
register is 18-bits. More IR bits can be added if a logicTest controller is present in the design, or
if the NumberBistPorts property is greater than 5.
Syntax
NumberUserBits: x;
where x is an integer that specifies the number of user bits.
Default Value
Usage Conditions
The NumberUserBits property is used in the TAP wrapper.
There is no upper limit for user bits. Any positive integer can be used.
Example
The example below specifies that the user requires two instruction register bits.
NumberUserBits: 2;
NumberUserDRBits
The NumberUserDRBits property enables you to customize the number of data register (DR)
bits in the TAP controller.
Syntax
Default Value
Usage Conditions
The NumberUserDRBits property is used in the TAP wrapper.
There is no upper limit for user DR bits. Any positive integer can be used.
Example
The example below specifies that the user requires two data register bits:
NumberUserIRBits
The NumberUserIRBits property specifies the number of bits ETAssemble adds to the WTAP
instruction register. ETAssemble automatically extracts the number of user IR bits in your
WTAP.
Syntax
NumberUserIRBits: <x>;
Default
Usage Conditions
The NumberUserIRBits property is used in the WTAP wrapper.
There is no upper limit for user IR bits. Any positive integer can be used.
Example
The example below specifies that the user requires two instruction register bits:
WTAP {
NumberUserIRBits: 2;
}
OutputsPerEnableCell
The optional OutputsPerEnableCell property specifies the maximum number of output pads
that a single, enable boundary-scan cell controls. ETAssemble uses this information during the
generation of the enable boundary-scan cells for output and bidirectional pads.
Syntax
OutputsPerEnableCell: x;
where x is a positive integer.
Default Value
Usage Conditions
Example
The following syntax specifies 4 as the maximum number of output pins that share a common
enable cell:
BoundaryScan {
OutputsPerEnableCell: 4;
}
Overrides
The Overrides wrapper is optional and can be left empty. This wrapper allows you to override
the following default values to guide you through the boundary-scan insertion process:
• A set of pin type options that are applicable for a particular pin or group of pins—using
Option. These options are usually specified directly within the Pin Order List Input File.
However, specifying the pin options in the Overrides wrapper provides you flexibility
of the pin names regular expressions.
• A name of a custom boundary-scan cell used for a specific pin—using Bcell. Typically,
this is not necessary since the pad input library provides a mechanism to specify a
custom boundary-scan cell used for a specific type of pad. This property can be used to
override the default value.
• A set of subclasses applicable to the boundary-scan cell associated with a particular
pin—using Subclass. Note that ETAssemble automatically assigns a default boundary-
scan cell based on the corresponding pad cell associated with a pin. This option provides
advance design flexibility that allows you to specify a different boundary-scan cell from
the default selection.
• A name of a pin—using pinNameRegExp. Specify the pin name by using the complete
pin name string or by using the wildcard character (*). The wildcard character (*)
matches zero or more characters of the pin name. The resultant name must be a valid pin
name that can be found under the pinName column of the input .pinorder file.
• The pin name regular expression can also include the %d syntax to specify pin names
that share common numerical suffix. For example, the specification name%d[3:0]
expands into name3, name2, name1 and name0
• An update group to which a boundary-scan cell, connecting to a particular pin,
belongs—using UpdGroup. The ETAssemble automatically groups the boundary-scan
cells into separate update groups based on the NumberUpdateGroups property. This
option can be used to override that grouping by explicitly specifying a desired grouping
for a pin.
Syntax
Overrides {
<pinNameRegExp>: Option (option1,option2,...optionN);
<pinNameRegExp>: Bcell (<bcellNAme>);
<pinNameRegExp>: SubClass(subclass1,
subclass2,...subclassn);
<pinNameRegExp>: <alphaNumericString>;
<pinNameRegExp>: UpdGroup (<updateGroupNum>);
}
Option Values
Valid values for Option are as follows:
• PWR, GND, NC — specifies that the package pin has a power source connection, a
ground source, or is unconnected to the chip.
• CE0, CE1 — specifies that the pin is always tied to logic 0 or logic 1 when the chip is
configured into an IEEE 1149.1-compliant mode.
• NJTAG — specifies that this pin should not be connected to a boundary-scan cell.
• DontTouch — specifies that the pin should not be connected to a boundary-scan cell.
This value is similar to the NJTAG value. However, it is more restrictive—when
specified for output or bidirectional pads, the pad enable is not gated with the
forceDisable signal from the TAP.
For details on usage of this option, refer to the description of the
ForceNonAuxPinsDontTouch option of the ETPlanner configuration files.
• CLK — specifies that the pin is either an input or output clock pin. Specifying this value
alters the RTL and the BSDL definition of the generated boundary-scan cells associated
with this pin.
• If the pin is an Input clock, then the boundary-scan cell will have a BSDL function of
clock and no JTAG multiplexer is inserted along the functional input path.
• If the pin is an Output clock, then the boundary-scan cell is modified to capture itself
during logicBIST operation.
• ANLG — specifies the analog pin as a linkage pin in BSDL.
• SAMPLE — specifies that the pin requires a SampleOnly boundary-scan cell.
• FIN — (functional input) forces ETAssemble to process the pin as an input-only pin
during boundary-scan insertion even if the actual pin direction is inout in the netlist and
the pin is connected to a bidirectional pad cell. The generated BSDL file will document
the pin as input, and the pin will connect to an input-type boundary-scan cell.
• FOUT — (functional output) forces ETAssemble to process the pin as an output-only

pin during boundary-scan insertion even if the actual pin direction is inout in the netlist
and the pin is connected to a bidirectional pad cell. The generated BSDL file will
document the pin as output, and the pin will connect to an output-type boundary-scan
cell.
• FIO — (functional inout) specifies that the pin is used as an IO. FIO is valid only for
inout pins.
Bcell Values
bcellName must be described in a .lvbscan file using the runtime option -userLib.
Subclass Values
Valid values for Subclass are as follows:
• S — inks the functional pin name associated with the pad cell containing a JTAG
multiplexer to a Sample-only boundary-scan cell.
• H — always captures the output of its own update latch in all possible modes, including
SAMPLE, EXTEST, scan, and logicBist. (A normal output boundary-scan cell captures
the value that comes from the core in scan and logicBist modes.) Note that a
bidirectional boundary-scan cell with subclass H captures its update latch output in scan
and logicBist modes, and captures the pin value in SAMPLE and EXTEST modes. Use
this option to specify free-running output or bidirectional clock pins.
PinName Regular Expression Values
alphaNumericString is a valid HDL character string. The following table illustrates some
examples of the pin name regular expression.
Table 3-4. Examples of PinName Regular Expression
PinName Examples of Matching Names
Regular
Expression
DATA DATA
PWR* PWR1, PWR2, PWRA, PWR[4]
D*TA DATA,DTA
*_NC UN1_NC,UN2_NC
ADD*[0:3] ADDRESS[0],ADDRESS{1],ADDRESS[2],ADD
RESS[3]
REG%d[0:3] REG0, REG1, REG2, REG3
G*D%d[3:1] GND3, GND2, GND1, GUARD3, GUARD2,
GUARD1
UpdGroup Values
pinNameRegExp is a valid HDL character string that corresponds to one or more pins in the pin
order list and updateGroupNum is an integer.
Usage Conditions
This wrapper is used in the BoundaryScan wrapper.
• You can specify more than one option for a pin by inserting a comma between each
option in the list.
• You also can specify the above options in the pin order list file.
• Use the SubClass override to specify a different boundary-scan cell from the default cell
for a pin or group of pins.
• If you specify the Option(CLK) override, you do not need to specify SubClass(S). The
Option(CLK) override generates a boundary-scan cell that is the same as the one for the
SubClass(S) override.
• If you are using update groups in your design, you must specify a number between 0 and
the number you specified using the NumberUpdateGroups property minus 1.
• The following usage conditions apply to the Option values FIN, FOUT, and FIO:
• The FIN and FOUT options are used only in chip design flows that force all top-level
pin directions to inout and connect to pad cells with bidirectional capabilities (bidir
pads) even when some pins are used as input-only or output-only in functional mode. In
the netlist, such input-only pins would tie off their bidir pad’s driver-enable control pin,
and output-only pins would leave their pad’s fromPad pin unconnected.
By default, ETAssemble inserts boundary-scan cells whose functions match their
associated netlist top-level pin directions. That means ETAssemble would insert a
bidirectional boundary-scan cell for an inout pin. If you want an input-type boundary-
scan cell when the pin is a functional input or an output-type boundary-scan cell when
the pin is a functional output, you can specify the Option value FIN or FOUT,
respectively, to force insertion of that direction. The generated BSDL will then closely
reflect the chip’s functional mode pin directions.
Note
Keeping all top-level pins bidirectional is useful if you want to implement wafer-
based minimum pin count IO tests or if you want to add more diagnostic capabilities
to your board-level interconnect test.
• The FIN, FOUT, and FIO values are mutually exclusive; you cannot specify more than
one for the same pin.
• When using FIN, FOUT, or FIO, you must specify complete buses as either input,
output, or inout; you cannot specify different directions for individual bus members.
• To define pins on a pad cell that is configured only with constants, use the Usage
wrapper of the pad library file instead of the Option values FIN, FOUT, or FIO in the
Overrides wrapper.
Example 1
The following example shows the use of the Option override for specific pins in the design.
Overrides {
iddt*: Option(CE0);
PWR*: Option(PWR);
INB[3:0]: Option(CE1);
}
Example 2
The following example specifies the overrides to be used to configure the specific boundary-
scan cells in the design:
Overrides {
iddt*: Option(CE0);
clk*: SubClass(S),Option(CLK);
PWR*: Option(PWR);
REGB[2:1]: UpdGroup(2);
INA[3:0]: BCell(myBcell);
}
Example 3
The following example specifies the use of the Subclass overrides property for particular pins
in the design.
Overrides {
iddt*: Option(CE0);
clk*: SubClass(S);
PWR*: Option(PWR);
INA[3:0]: Bcell(myBcell);
myInoutPin: SubClass(C2);
}
Example 4
The following example specifies the overrides data for particular boundary-scan cells in the
design using the UpdGroup property.
Overrides {
PWR*: Option(PWR);
}
Example 5
The following example shows the use of the Option values FIN, FOUT, and FIO to specify top-
level IO pins as input only, output only, or inout. The IO pins io_io[0] and io_io[1] are not
asserted.
BoundaryScan {
Overrides {
io_in[0]: Option (FIN);
io_out[0]: Option (FOUT);
io_io[2]: Option (FIO);
io_io[3]: Option (FIO);
PadIOPins
The PadIOPins property is used in the Embedded Boundary Scan flow (EBScan) to define the
list of pins which connect to device IO pins, and you want to be equipped with boundary-scan
logic. It is a comma-separated list, and the order of the pins is used to order the boundary-scan
cells where the left-most pin is closest to TDI, and the right-most pin is closest to TDO.
Syntax
BoundaryScan {
PadIOPins: <pinList>;
}
where pinList is an ordered list of pins identifying the device IO pins. The order of the pins is
used for ordering the boundary-scan elements.
Default
None
Usage Conditions
The PadIOPins property is used in the BoundaryScan wrapper when running ETAssemble in
EBScan flow.
• This property is used and is mandatory when running in -flow EBScan.
• This property replaces the pin.order file that is normally used.

• Do not list the pins on the block which are not connected to the padIO or padIOInv pin
of an embedded pad cell.
• Order the pin list in the way the pads are physically placed. The boundary-scan segment
will be build following this order to minimize routing.
Example
BoundaryScan {
....
PadIOPins: A0, A1, A2, A3, B[0:3], B[7:4];
}
Pins
The Pins wrapper specifies the AC grouping list that enables AC mode on a selected subset of
your design’s AC-mode output pins while one of two AC EXTEST instructions is in effect.
Each AC group has one internal boundary-scan cell - the AC Select cell - that supplies a gated
version of the ACMode signal to all AC-mode output boundary-scan cells in that group. The
specified groupName is used for naming the AC Select cell and its connecting nets in the output
netlist. When an AC group output pin is not specified in a Pins wrapper, it is controlled by the
non-gated global ACMode signal.
Syntax
Pins {
<list of pin names>
}
Default Value
None
Usage Conditions
The Pins wrapper is used in the ACGroup: ACMode: BoundaryScan wrapper.
Example
The following example shows the Pins wrapper:
Pins {
BUS_A[63:0]
}
Polarity
The Polarity property specifies whether the user signal goes low (activeLow) or high
(activeHigh) when the correct opcode is loaded into the user IR bits or user DR bits as specified
by the Code property.
Syntax
Polarity: (activeHigh) | activeLow;
• activeHigh—indicates that a logic 1 on a port activates the function.

• activeLow—indicates that a logic 0 on a port activates the function.
Default Value
The default value is activeHigh.
Usage Conditions
The Polarity property is used in the UserSignal wrapper.
You can specify either activeHigh or activeLow as valid values for this option.
Example
UserSignal (TAPport) {
Code: 5'bxxx00;
DecodeSource: IR;
}
PowerDomainGroupPriority
The PowerDomainGroupPriority property specifies the order that the Power Domain groups
are programmed when more than one is selected during a PowerUp programming phase.
Syntax
PowerDomainGroupPriority: <ListOfLabels>;
where ListOfLabels is an ordered list of Power Domain Group Labels. The first label has higher
priority.
Default Value
None
Usage Conditions
• The default priority order is random and depends on the order of the memories and their
associated PowerDomainGroup labels in the .etCheckerInfo file. If you care about the
priority, then you must specify this property.
• If you need some memories to be repaired quicker at power up, specify their
PowerDomainGroup labels first.
• You can even separate memories into fake power domain groups if you need some
memories to be repaired very quickly at power up.
• Use Label “-” when referencing the group of memory you have not provided a
PowerDomainGroupLabel in the .etchecker file.
Example
This example instructs ETAssemble to prioritize Power Domain Group Label A, then B, then
the memories with no labels.
MemBISR {
PowerDomainGroupPriority: A, B,-;
}
Private
The Private property enables you to specify whether the user-defined TAP instruction is
marked as “private” in the BSDL file using the BSDL attribute INSTRUCTION_PRIVATE.
According to the IEEE 1149.1-2001 specification: “Private instructions enable the component
manufacturer to use the TAP and test logic to gain access to test features embedded in the
design for design verification, production testing, or fault diagnosis. The component
manufacturer may require test performed using these features to give results that differ between
variants of the component, for example, that would render documentation and use by
component purchasers difficult.”
Syntax
TAP {
UserInstruction (<instructionName>) {
Private: Yes | (No);
}
}
Default Value
Usage Conditions
The Private property is used in the UserInstruction wrapper.
Example
TAP {
RegisterAccess: UserReg[3];
Private: Yes;
}
}
The above specification in the UserInstruction wrapper of the TAP wrapper in the .etassemble
file results in the generation of the following BSDL segment:
attribute INSTRUCTION_PRIVATE of ETC: entity is “MyInstr2”;
RegisterAccess
The RegisterAccess property enables you to identify which user-defined register is selected for
a specific instruction.
Syntax
TAP {
RegisterAccess: <registerName>;
}
}
where registerName is the name of the test-data register selected when any of the listed
instructions specified by instructionName are loaded into the TAP instruction register.
Default Value
None
Usage Conditions
The RegisterAccess property is used in the UserInstruction wrapper.
• You can specify only one user-defined register for each UserInstruction wrapper.
• You must specify registerName using the following format, which is required by BSDL:
<VHDLIdentifier>[<registerLength>]
• where registerLength is a positive integer value representing the length of the design-
specific test-data register; for example, MyRegister[4].
• If registerName is specified as INT_DR but with no register length, ETAssemble
automatically inserts the correct INT_DR register length.
• If RegisterAccess property is not specified, ETAssemble examines bits [2:0] of the
opcode and attempts to determine what register is to be accessed:
o If opcode [2:0]=3'b000 then the BOUNDARY register is selected.
o If opcode [2:0]=3'b101 then the INT_DR register is selected.
o If opcode [2:0]=3'b110 then the DEVICE_ID register is selected.
o If opcode [2:0]=3'b111 then the BYPASS register is selected.
Example
This example specifies that the test-data register UserReg is selected when MyInstr3 is loaded
into the TAP’s instruction register:
TAP {
}
}
RepairWordSize
The RepairWordSize property is rarely used and is automatically adjusted to match the largest
repair word or BISR register that you have in your design. A BISR register is associated with a
single spare element (row, IO, or column) and is typically 6 to 12 bits long. You can use this
property to override the value to a smaller value if the largest repair word is truly an exception,
and the large majority of your repair word size is much smaller. The value assigned to this
property has an impact on the number of fuses required to store memory repair information.
Syntax
where int is the size of the repair word size you want.
Default Value
The default value is automatically adjusted to match the largest repair word size of all memories
found within your design.
Usage Conditions
• You rarely need to specify this property because the default value is automatically
adjusted to match your design. This value does not need to be exact; the BISR controller
will be functional even if the value is slightly higher or lower than the optimal value.
However, more fuses might be required to store the memory repair information. For
example, if RepairWordSize is set to 8 for a circuit with varying BISR register lengths
of between 6 and 10, two repair words (that is, 2 * 8 = 16 fuses) are needed to store the
contents of BISR registers of length 9 and 10 instead of one. On the other hand, BISR
registers of length 6 and 7 do not need the full width of the repair word. The impact on
the number of fuses depends on the number of times all those registers contain repair
information. Because larger registers are usually associated with larger memories, the
probability of those registers being used is higher.
• You may need to set this property if you are performing memory BIST insertion on the
parent region before inserting memory BIST into the child regions. For more
information, see the “Performing Parent Memory BIST Insertion Before Child Regions”
section in the “Flow Variations” appendix of the Tessent MemoryBIST User’s and
Reference Manual.
Example
This example specifies to ETAssemble to build a BISR controller where the repair word is set to
7 bits.
MemBISR {
RepairWordSize: 7;
}
ResetTest
The ResetTest property controls the port name that is used when an external flop asynchronous
reset scan port is needed on the block.
Syntax
Default Value
The default value is LV_ResetTest.
Usage Conditions
This property is used in the ExtScanPortNaming wrapper.
by any other properties of the ExtScanPortNaming wrapper, such as the TestMode property.
Example
The following syntax defines a port as LV_ResetTest.
ExtScanPortNaming (cntrlA) {
ResetTest: LV_ResetTest;
...
}
RevisionCode
The RevisionCode property specifies the value representing the 4-bit revision ID code field
within the IEEE 1149.1-compliant device ID register.
Syntax
RevisionCode: 4'b<revId> | (4'h<revId>);
Default Value
If the DeviceIdCode, ManufacturersIdCode, and RevisionCode properties are not specified, the
IEEE 1149.1 ID register is not generated and the bypass register is selected when the TAP
register resets.
Usage Conditions
The RevisionCode property is used in the TAP and WTAP wrappers and in the
BoundaryScan:BondingOption wrapper.
In the BoundaryScan:BondingOption wrapper, the following usage conditions apply:
• If you specify RevisionCode, you also must specify EnableSignal.

• The RevisionCode value is used in the TAP RTL description and the BSDL file,
overriding the RevisionCode specified in the TAP wrapper.
• If you do not specify RevisionCode, the default value is the RevisionCode in the TAP
wrapper.
Example
RevisionCode: 4'h1;
Refer to the BondingOption wrapper for an example using the RevisionCode property to
override an existing revision code value.
SafeValue
The SafeValue property specifies the value that is stored in the cell’s SafeValue column of the
BOUNDARY_REGISTER attribute in the generated BSDL file. The ETVerify tool (JtagVerify
wrapper) systematically picks up that value from the BSDL file and loads the value into the
internal boundary-scan cell during standard IO tests. The same is true for third-party PCB
testers. Specify SafeValue to make your circuit compatible with the IO tests.
Syntax
Default Value
The default is X.
Usage Conditions
Example
The following example specifies for ETAssemble to use 1 as a safe value for the internal
boundary-scan cell in the generated BSDL file:
SafeValue: 1;
SampleOnly
The SampleOnly property, when set to On, creates an internal boundary-scan cell that only
observes the point specified by the Connection property. When set to Off, the internal boundary-
scan cell actually takes control of the specified connection. See the SJOMuxPresent property for
examples.
Syntax
Default Value
The default is Off.
Usage Conditions
When the SampleOnly property is set to On, the SJOMuxPresent property is silently ignored.
ScanChain
The ScanChain wrapper specifies the scan-input and scan-output ports in the design.
Syntax
The following syntax specifies this wrapper and its properties:
ScanChain {
SI: <ScanInputPort>;
SO: <ScanOutputPort>;
}
• ScanInputPort—identifies the scan-input ports.

• ScanOutputPort—identifies the scan-output ports.
Default Value
None
Usage Information
This wrapper is used in the TAP: ScanConcatenation wrapper
• You must include this wrapper for each internal scan chain in the design. For each scan
chain, identify the scan-input and scan-output port by specifying a full hierarchical path
to that port.
• The SI property must point to an input port inside the design, and the SO property must
point to a port or a net that exist inside the design.
Example
This example identifies a scan chain in the design.
ScanChain {
SI:./u1d1/TI;
SO:./ur8/Q;
}
ScanConcatenation
The ScanConcatenation wrapper specifies scan-chain concatenation information to
ETAssemble. For each scan chain in the design, you must specify scan-input and scan-output
ports of the design block, as well as the scan-enable ports. You must also specify the clock ports
in this wrapper.
The connections from the top-level chip pins to the ports of the design block corresponding to
scan input, scan enable, and clocks are intercepted with 2:1 multiplexers. You can specify these
multiplexers in the pad library file.
Syntax
The following syntax shows the ScanConcatenation wrapper and its contents:.
ScanConcatenation {
Select: <NetName>;
ScanChain {
SI: <ScanInPort>;
S0: <ScanOutPort>;
}
}
Usage Conditions
The ScanConcatenation wrapper is used in the TAP wrapper.
The following usage conditions apply to the ScanConcatenation wrapper:
• Do not use this wrapper if you are using the LV Flow because the scan port information
is automatically forwarded to ETAssemble using the scaninfo files generated by the
ruleAnalyze tool.
• Use the ScanConcatenation wrapper only if you are using a third party scan-insertion
tool to implement a multi-chain scan test and you want ETAssemble to concatenate
those scan chains into a single scan-through-TAP chain for system-level diagnostic
purposes.
• Note that the inter-domain capture problems that the LV Flow automatically resolves,
using its patented capture-by-domain technique, is not addressed with the
ScanConcatenation wrapper. You may need to program your ATPG software to mask
all capture results coming from a different domain while using a third party ATPG tool.
Example
This example identifies two scan chains in the design and three clock sources. A single scan-
enable port is identified.
ScanConcatenation {
ScanChain {
SI:./add1_cp_buf/A;
SO:./scan_en_buf/A;
}
ScanEnable
The ScanEnable property identifies the scan-enable ports of the design block.
Syntax
ScanEnable: <ScanEnablePort>;
where ScanEnablePort specifies the name of the scan-enable port of a module.
Default Value
None
Usage Conditions
The ScanEnable property is used in the ScanConcatenation wrapper.
You must specify this property for each scan-enable port of the design block The ScanEnable
property must point to an input port inside the design block.
Example
This example identifies a single scan-enable port.
ScanEnable:./scan_en_buf/A;
ScanIn
The ScanIn property controls the port name that is used when an external ScanIn scan port is
needed on the core.
Syntax
ScanIn: x;
where x is a scalar port name.
Default Value
The default value is LV_SI.
Usage Conditions
The ScanIn property is used in the ExtScanPortNaming wrapper.
by any other ExtScanPortNaming wrapper property, such as the TestMode property.
Example
The following example defines the port name as LV_scanIn:
ExtScanPortNaming {
ScanIn: LV_scanIn;
}
ScanOut
The ScanOut property controls the port name that is used when an external scanOut port is
needed on the core.
Syntax
ScanOut: x;
where x is a scalar port name.
Default Value
The default value is LV_SO.
Usage Conditions
The ScanOut property is used in the ExtScanPortNaming wrapper.
by any other ExtScanPortNaming wrapper property, such as the TestMode property.
Example
The following example defines the port name as LV_scanOut:
ExtScanPortNaming {
ScanOut: LV_scanOut;
}
Select
The Select property identifies the select signal for the 2:1 multiplexer inserted at each ScanInput
port specified by the SI, scanEnable, and the ScanClock properties. By default, the select
signal connects to the selectJtagInput port of the TAP controller.
Syntax
Select: <signalName>;
where signalName is the name of the 2:1 select signal.
Default Value
None
Usage Conditions
The Select property is used in the ScanConcatenation wrapper.
Specify the Select property to identify the select signal for the 2:1 multiplexer inserted at each
of the ports specified by the SI, ScanEnable, and Clock properties.
Example
This example is identical to the default value for the Select property.
Select:./LVISION_JTAP_INST/selectJtagInput;
SetResetTest
The SetResetTest property controls the port name that is used when an external flop
asynchronous set/reset scan port is needed on the block.
Syntax
Default Value
The default value is LV_SetResetTest.
Usage Conditions
by any other properties of the ExtScanPortNaming wrapper, such as TestMode.
Example
The following syntax defines a port as LV_SetResetTest.
SetTest: LV_SetresetTest;
...
}
SetTest
The SetTest property controls the port name that is used when an external flop asynchronous set
scan port is needed on the block.
Syntax
SetTest: <string>;
Default Value
The default value is LV_SetTest.
Usage Conditions
by any other properties of the ExtScanPortNaming wrapper, such as TestMode.
Example
The following syntax defines a port as LV_SetTest.
SetTest: LV_SetTest;
...
}
SJOMuxPresent
The generated internal cell default includes a multiplexer that multiplexes the boundary-scan
stored value with your functional input as shown in Figure 3-15. Similar to Tessent’s output and
control boundary-scan types, ETAssemble will move the target pin’s original connection net to
its funcDataIn input and replace that one with a connection to its DataOut pin. If your target pin
needs to be tied to a constant during functional mode, then tie it to that constant inside your pre-
layout netlist.
Figure 3-15. Internal Boundary-Scan Cell Schematic
Syntax
The following syntax specifies the SJMuxPresent property:
If you specified SJOMuxPresent to Off, then the output from the cell’s updateLatch will
connect directly to your specified connection point. Specify this property to Off only when you
already inserted your own multiplexer in your pre-ETAssemble circuit, and you only want the
internal boundary-scan cell to provide the test data input for it. ETAssemble then generates the
internal bscan cell as shown in Figure 3-16 on page 199.
Figure 3-16. Internal Bscan Cell Without a SJO Mux
Default Value
The default is On.
Usage Conditions
The Cell wrapper is used in the BoundaryScan: InternalBScanCells: Cell wrapper.
ShiftPhase
The ShiftPhase property controls the port name that is used when an external ShiftPhase scan
Syntax
ShiftPhase: x;
Default Value
The default value is LV_ShiftPhase.
Usage Conditions
The ShiftPhase property is used in the ExtScanPortNaming wrapper.
The specified port name cannot be used by any other ExtScanPortNamingwrapper property,
such as TestMode.
Example
The following example defines the port name as LV_SP:
ExtScanPortNaming {
ShiftPhase: LV_SP;
}
Sides
The Sides wrapper enables you to specify a boundary-scan group.
Syntax
Sides {
<bgroupName1>: <pin1>;
<bgroupName2>: <pin2>;
...
<bgroupNameN>: <pinN>;
}
The following optional form of the syntax enables you to specify that the created boundary-scan
group is to be placed in a particular hierarchical block:
Sides {
<bgroupName1> (<hierarchicalPath1>): <pin1>;
<bgroupName2> (<hierarchicalPath2>): <pin2>;
...
<bgroupNameN> (<hierarchicalPathN>): <pinN>;
}
Valid values are as follows:
• bgroupNameN — is an instance name that you want to give to the boundary-scan group.
This name is also used to create the boundary-scan group RTL file name in
ETAssemble's output directory, as in
<designName>_LV_BGROUP_<bgroupName>.<rtlExtension>.
• pinN — is the first pin that will be included in the boundary-scan group. All other pins
listed after that one in the Pin Order List Input File—.pinorder—will also be included in
that boundary-scan group, until a pin has another boundary-scan group declaration.
• hierarchicalPathN — is the hierarchical path of the block into which the boundary-scan
group is to be placed. This hierarchical path and enclosing parentheses are optional for a
given boundary-scan group. That is, within the Sides wrapper, some boundary-scan
groups may have a hierarchical path and others may not. Refer to the “Examples”
section below.
Usage Conditions
The Sides wrapper is used in the BoundaryScan wrapper.
Specifying the Sides wrapper with a hierarchical path has some tool limitations. For more
information, see the “Known Problems and Workarounds for the LV Flow Infrastructure”
section of the LV Flow Infrastructure and Timing Constraints Release Notes.
Example
The following example defines the following boundary scan:
BoundaryScan {
Sides {
Left: A[0];
Up: SETN;
Right: B[1];
Down: A[7];
}
}
You can also specify to push the created boundary-scan group inside a given hierarchical block
that exists in the pre-ETAssemble netlist, like in the following example:
BoundaryScan {
Sides {
Left: A[0];
Up (Core1/block1): SETN;
Right (Core2/block2): B[1];
Down: A[7];
}
}
Boundary-scan group Up will be inserted inside the hierarchical cell Core1/block1. Boundary-
scan group Right will be pushed inside the hierarchical cell Core2/block2.
SubClass
The SubClass override option specifies a set of subclasses applicable to the boundary-scan cell
associated with a particular pin. Note that ETAssemble automatically assigns a default
boundary-scan cell based on the corresponding pad cell associated with a pin. This option
provides advance design flexibility that enables you to specify a different boundary-scan cell
from the default selection.
Syntax
<pinNameRegExp>:SubClass(subclass1, subclass2,...subclassn);
where pinNameRegExp is a valid HDL character string that corresponds to one or more pins in
the pin order list file, and the valid SubClass values are as follows:
• S — links the functional pin name associated with the pad cell containing a JTAG
multiplexer to a Sample-only boundary-scan cell.
• H — always captures the output of its own update latch in all possible modes, including
SAMPLE, EXTEST, scan, and logicBist. (A normal output boundary-scan cell captures
the value that comes from the core in scan and logicBist modes.) Note that a
bidirectional boundary-scan cell with subclass H captures its update latch output in scan
and logicBist modes, and captures the pin value in SAMPLE and EXTEST modes. Use
this option to specify free-running output or bidirectional clock pins.
• C2 — specifies a bidirectional boundary-scan cell that features one input and one output
data boundary-scan register for each direction instead of one bidir register for both
directions. By default, ETAssemble generates a cell with one bidir register.
Default Value
None
Usage Conditions
• Use the SubClass option to specify a different boundary-scan cell from the default cell
for a pin or group of pins.
• If you specify the Option(CLK) override, you do not need to specify SubClass(S). The
Option(CLK) override generates a boundary-scan cell that is the same as the one for the
SubClass(S) override.
Example
The example below specifies the use of the SubClass override property for particular pins in the
design.
Overrides {
iddt*: Option(CE0);
clk*: SubClass(S);
PWR*: Option(PWR);
REGB[2:1]: updGroup(2);
INA[3:0]: Bcell(myBcell);
myInoutPin: SubClass(C2);
}
TAP
The TAP wrapper conveys information about the configuration of the TAP controller generated
by ETAssemble. The syntax of the TAP wrapper is illustrated in Figure 3-17.
Note
If you do not specify the .etassemble configuration file, ETAssemble generates a
configuration for a default TAP. In fact, ETAssemble generates this embedded test structure
as if you provided a configuration file with an empty TAP wrapper.
Figure 3-17. TAP Wrapper Syntax in the User-Configuration File
TAP {
DeviceIdCode: <binaryNumber>;
ManufacturersIdCode: <binaryNumber>;
MaxTCKFreq: x;
NumberBistPorts: x;
NumberUserBits: x;
RevisionCode: <binaryNumber>;
InjectTCKOnClockSources: All |
(TopMemBistClocks) | None;
Connections {
<ConnectionsProperties>
}
ScanConcatenation{
Select: <NetName>;
ScanChain {
SI: <ScanInPort>;
S0: <ScanOutPort>;
}
}
<Properties>
}
UserBitAliases{
<UserBitAliases>
}
<UserSignalProperties>
}
<TestPortConnectionsProperties>
}
}
Example
In the following example, the syntax specifies a customized TAP:
TAP {
DeviceIdCode: 16'h3;
ManufacturersIdCode: 11'h001;
RevisionCode: 4'h2;
NumberBistPorts: 7;
NumberUserBits: 3;
UserBitAliases {
UserBitAlias(n): UserDRBit[n-1:0];
UserBitAlias(n): UserIRBit[n-1:0];
Connections {
// TO Instance CORE
BIST_SHIFT: CORE/BIST_SHIFT;
BIST_HOLD: CORE/BIST_HOLD;
BIST_SETUP2: CORE/BIST_SETUP[2];
TCK: CORE/TCK;
TCK_MODE: CORE/TCK_MODE;
TO_BIST_SI: CORE/BIST_SI;
}
ScanConcatenation {
ScanChain {
SI: SCAN_CHAIN_DEMO/SI1;
SO: SCAN_CHAIN_DEMO/SO1;
}
ScanChain {
}
ScanChain {
}
Select: SCAN_CHAIN_DEMO/SELECT;
ScanEnable: SCAN_CHAIN_DEMO/SE1;
ScanEnable: SCAN_CHAIN_DEMO/SE2;
Clock: SCAN_CHAIN_DEMO/CLK;
}
TestPortConnections{
TCK: tck;
TRST: trst;
TMS: tms;
TDI: tdi
TDO: tdo;
}
Code: 17'b10000000000000000;
RegisterAccess: myReg[2];
}
UserSignal(mySignal) {
Code: 3'b100;
DecodeSource: DR;
Connection:./mySignal;
}
}
}
TCMGenClockSource
The TCMGenClockSource wrapper specifies the mapping between a clock port of a sub-
module (child ET-inserted block or ELTCore module) and a clock port of the current module.
This is useful if you specified the BypassDesignExtract property in your .etplan file and have
clock schemes that TCMGen does not directly support.
Syntax
The following syntax specifies the TCMGenClockSource wrapper and its properties:
TCMGenClockSource(<subModuleInstancePathName.clockPortName>) {
ReferencePin: <currentModuleClockPortName>;
ReferencePinInv: <currentModuleClockPortNameInv>;
FreqRatio: <real>;
}
where:
• <subModuleInstancePathName.clockPortName> — specifies the clock port name and

the instance path of the sub-module.
• ReferencePin: <currentModuleClockPortName> — specifies the clock port name of
the current module.
• ReferencePinInv: <currentModuleClockPortNameInv> — specifies the inverted clock
port name of the current module.
• FreqRatio: <real> — specifies the frequency ratio between the clock of the sub-module
instance and the clock of the current module. The default value is 1.
Usage Conditions
The TCMGenClockSource wrapper is in the main Configuration wrapper of the .etassemble
file.
• The BypassDesignExtract property in the .etplan file must be set to Yes.

• Use the TCMGenClockSource wrapper when either
• the tool fails to get the clock port of the current module that is connected to the clock
port of the lower block or
• you want to override the clock mapping between the current module and the lower
block.
Example
In the following example, CK33MHz is the clock port of the sub-module instance
dashboard_INST, and CK33MHz is connected to the clock port CLKTEST of the current
module. The frequency ratio between CK33MHZ and CLKTEST is 2.
// In car.etassemble file
Configuration (car) {
BoundaryScan {
Overrides {
}
}
TAP {
InjectTCKOnClockSources: All;
Connections {
...
}
}
TCMGenClockSource (dashboard_INST.CK33MHz){
ReferencePin: CLKTEST;
FreqRatio: 2;
}
}
TestFlopReset
The TestFlopReset property controls the port name that is used when an external Testpoint flop
reset scan port is needed on the core.
Syntax
TestFlopReset: x;
Default Value
The default value is LV_TFResetNot.
Usage Conditions
The TestFlopReset property is used in the ExtScanPortNaming wrapper.
The specified port name cannot be used by any other ExtScanPortNaming wrapper property,
such as TestMode.
Example
The following example defines the port as LV_TPFlopReset.
ExtScanPortNaming {
TestFlopReset: LV_TPFlopReset;
}
TestMode
The TestMode property controls the port name that is used when an external TestMode scan
Syntax
TestMode: x;
Default Value
The default value is LV_TM.
Usage Conditions
The TestMode property is used in the ExtScanPortNaming wrapper.
The specified port name cannot be used by any other ExtScanPortNaming wrapper property,
such as TestFlopReset.
Example
The following example defines the port name as LV_extTM.
ExtScanPortNaming {
TestMode: LV_extTM;
}
TestPortConnections
The TestPortConnections wrapper enables you to override where the IEEE 1149.1-compliant
TAP ports are connected. When specified, it overrides the normal connection that would be
made to the pad cell.
Syntax
The following syntax specifies TestPortConnections wrapper and its properties:
TCK: <hierarchicalOutputPortName>;
TMS: <hierarchicalOutputPortName>;
TRST: <hierarchicalOutputPortName>;
TDI: <hierarchicalOutputPortName>;
TDO: <hierarchicalInputPortName>;
TDO_EN(1|0): <hierarchicalInputPortName>;
}
where each property specifies the name of the internal port that should be used instead of the
corresponding IEEE 1149.1 TAP pad cell.
Default Value
None.
Usage Conditions
The TestPortConnections wrapper is located in the TAP wrapper.
• The TDO_EN property identifies an internal port that controls the TDO pad enable
signal. This property must be specified if the TDO property is specified. The polarity
values are as follows:
o 0 specifies that the polarity is low (activeLow)
o 1 specifies that the polarity is high (activeHigh)
• If you do not plan to specify a TRST primary pin in your design, you must set the TRST
property in the TestPortConnections wrapper to point to the output pin of your
embedded power-on reset circuit. This is an IEEE 1149.1 requirement.
Example
In the following example, all of the TAP ports are being overridden:
TCK : tapLinker_inst/TCK;
TMS : tapLinker_inst/TMS;
TRST: tapLinker_inst/TRST;
TDI : tapLinker_inst/TDI;
TDO : tapLinker_inst/TDO;
TDO_EN(0): tapLinker_inst/TDO_EN;
}
TestPointEnable
The TestPointEnable property controls the port name when functional testpoints are used for
external logic. You can re-map this input to a specific input port of an ELT core inside the
.etassemble file.
Syntax
Default Value
The default value is LV_TPEN.
Usage Conditions
The TestPointEnable property is used in the ExtScanPortNaming wrapper.
• The specified port name must be a simple scalar name.

• The specified port name cannot be used by any other property in the
ExtScanPortNaming wrapper.
Example
The following example defines the port name as i_LV_tren.
ExtScanPortNaming {
TestPointEnable: i_lv_tpen;
}
TestPortNaming
The TestPortNaming wrapper enables you to specify the names of the ports related to the
WTAP that is created on the core. These ports form the interface between the WTAP and the
top-level JTAP.
Syntax
The following syntax specifies TestPortNaming wrapper and its properties:
TestPortNaming {
WRSTN: <corePortName>;
WRCK: <corePortName>;
WSI: <corePortName>;
WSO: <corePortName>;
UpdateWR: <corePortName>;
ShiftWR: <corePortName>;
CaptureWR: <corePortName>;
SelectWIR: <corePortName>;
EnableWR: <corePortName>;
AuxOut: <corePortName>;
AuxIn: <corePortName>;
AuxEn: <corePortName>;
TestClockPort (<oldPortName>): <newPortName>;
TestClockPortFreqUnificationSuffix:
<suffixToTestClockPortName>; // Defaults to _extF
ETClockEnable: <ETClockEnablePortName>;
BISR_SI: <corePortName>;
BISR_SO: <corePortName>;
BISR_CLOCK: <corePortName>;
BISR_SCAN_ENABLE: <corePortName>;
BISR_CLEAR: <corePortName>;
BISR_SELECT: <corePortName>;
BISR_MEM_DISABLE: <corePortName>;
BISR_GO: <corePortName>;
BISR_DONE: <corePortName>;
}
where each property specifies the name of the core primary input test port that connects, inside
the core, to the WTAP input that has the same name as the property.
The TestClockPortFreqUnificationSuffix property defines a suffix that is used to uniquify a

TestClockPort when it turns out that the same test clock port was specified for multiple clock
domains of different frequencies. When this situation occurs, the specified suffix is appended to
the TestClock port name followed by an integer starting at 2. You can use this property to
change the string used for this suffix.
Default Value
For each property, the default value is shown in the table below:
Table 3-5. TestPortNaming Defaults
WRSTN LV_WRSTN
WRCK LV_WRCK
WSI LV_WSI
WSO LV_WSO
Table 3-5. TestPortNaming Defaults (cont.)

UpdateWR LV_UpdateWR
shiftWR LV_ShiftWR
captureWR LV_CaptureWR
selectWIR LV_SelectWIR
enableWR LV_EnableWR
AuxIn LV_AuxIn
AuxOut LV_AuxOut
AuxEn LV_AuxEn
TestClockPort(OldName) Null
TestClockPortFreqUnificationSuffix _extF
ETClockEnable LV_ETClockEnable
BISR_SI LV_BISR_SI
BISR_SO LV_BISR_SO
BISR_CLOCK LV_BISR_CLK
BISR_SCAn_ENABLE LV_BISR_SCAn_ENABLE
BISR_CLEAR LV_BISR_CLEAR
BISR_SELECT LV_BISR_SELECT
BISR_MEM_DISABLE LV_BISR_MEM_DISABLE
Usage Conditions
The TestPortNaming wrapper is located in the main Configuration wrapper.
• Unless the default names interfere with design port names, the default values should be
used.
• The TestClockPort property is different from the rest of the properties inside the
TestPortNaming wrapper—it has the port name it is referring specified with the
parenthesis. You use this property to rename a TestClockPort created by ETAssemble.
Example
In the following example, the default WSI port name is changed:
TestPortNaming {
WSI: TEST_WSI;
}
TestReceiverInitClkPinAssert
The TestReceiverInitClkPinAssert property enables you to program the initClk waveform to
accommodate different types of 1149.6 receiver hysteresis memory implementations. This
waveform is a single one-cycle TCK pulse.
When running ETAssemble in -flow EBscan, this property is forwarded into the .lvbscan Input
File as InitClkPolarity. The specified TestReceiverInitClkPinAssert value is checked against
the InitClkPolarity values read from child .lvbscan files. Currently, ETAssemble only supports
one TestReceiverInitClkPinAssert value for the entire device. This restriction will be
removed in a later release by allowing the InitClkPolarity property to be specified in the Pad
Library Input File on a per pad basis.
Syntax
TestReceiverInitClkPinAssert: (RisingEdge)|FallingEdge | Logic0 | Logic1;
• RisingEdge — specifies to ETAssemble that the test receiver memory element is a

positive-edge triggered flop.
• FallingEdge — specifies to ETAssemble that the test receiver memory element is a
negative-edge triggered flop.
• Logic0 — specifies to ETAssemble that the test receiver memory element is reset by a
logic zero.
• Logic1 — specifies to ETAssemble that the test receiver memory element is reset by a
logic one.
Default Value
The default value is RisingEdge.
Usage Conditions
This property is used in the BoundaryScan: ACMode wrapper.
The TAP initClk signal waveform is the following:
• RisingEdge -> negative pulse

• FallingEdge -> positive pulse
• Logic0 -> negative pulse
• Logic1 -> positive pulse
This single-cycle init pulse occurs during:
• Select-DR state in EXTEST mode

• Exit1-DR state in AC-EXTEST mode
In all cases, the pulses are meant to reset the contents of the test receiver’s hysteretic memory in
the following way:
• 1/2 TCK cycle before boundary-scan capture in EXTEST mode

• 1/2 TCK cycle before boundary-scan update in AC-EXTEST mode
Example
The following example specifies to ETAssemble that the test receiver memory element is a
negative-edge triggered flop:
TestReceiverInitClkPinAssert: FallingEdge;
Train
The Train property specifies the minimum number of Tcl pulses during the Idle TAP state
when the TAP instruction EXTEST_TRAIN is executed. The MaximumTime property value is
copied into the AIO_EXTEST_Train_Execution attribute within the generated .bdsl file.
Syntax
Train: <x>;
where x is an integer greater than zero.
Default
None
Usage Conditions
The Train property is used in EXTESTTrainExecution: ACMode: BoundaryScan wrapper.
The omission of the EXTESTTrainExecution wrapper indicates that there is no timing

requirement on Train execution.
Example
The following example shows the minimum number of Tcl pulses set to 8:
Train: 8;
UnusedPins
The optional UnusedPins property defines the top-level pins that are not connected in the
specified bonding option. The boundary-scan cells belonging to these pins are converted to
internal cells in the BSDL file if they are not bypassed. This includes control cells that are
shared among pins. If all pins controlled by the cell are internal or bypassed, the control cell also
will be internal.
Syntax
Default
None
Usage Conditions
The UnusedPins property is used in the BoundaryScan:BondingOption wrapper.
The UnusedPins property supports comma-separated lists and the * wildcard.
Example
Refer to the BondingOption wrapper for an example showing the UnusedPins property.
UseLocalAuxPins
The UseLocalAuxPins property enables you to use local auxiliary pins.
If set to On and not enough pins are available on the LocalAuxInPinList or LocalAuxOutPinList
to meet the needs of the block or ELTCore, an error message is generated.
This property defaults to On if enough pins are available on the LocalAuxInPinList or

LocalAuxOutPinList to meet the needs of the block or ELTCore; otherwise, the property
defaults to Off.
Syntax
UseLocalAuxPins: On | Off;
Usage Conditions
Example
Configuration {
UseLocalAuxPins: Yes;
LocalAuxOutPinList: A[3:0],B2,B1;
}
UserBitAlias
The UserBitAlias wrapper defines alias names for groups of user IR bits.
Syntax
LeftIndex: x;
RightIndex: x;
}
where the above criteria represent the following:
• x — is an integer between 0 and the number of IRbits -1 .

• y — is an integer between 0 and the number of IRbits -1 .
Default Value
None
Usage Conditions
The UserBitAlias wrapper is used in the WTAP wrapper.
You can define an alias for one user bit or for a range of user bits. The alias name always refers
to a bus with the index [x:y].
Note
The alias name must consist of alphanumeric characters and underscores only.
Example
In the following example, an alias is defined for a range of 2 user bits and another is defined for
a single bit.
WTAP {
UserBitAlias (my_wtap_IR_bit_10_to_3) {
LeftIndex: 10;
RightIndex: 3;
}
UserBitAlias (my_wtap_IR_bit_11) {
LeftIndex: 11;
RightIndex: 11;
}
}
UserBitAliases
The UserBitAliases wrapper defines alias names for groups of user IR or DR bits.
Syntax
UserBitAliases {
<alias>: UserDRBit(<x>);
<alias>: UserIRBit(<x>);
}
where x is an integer or a range specification in Verilog format.
Default Value
None
Usage Conditions
The UserBitAliases wrapper is used in the TAP wrapper.
• You can define an alias for one user bit or for a range of user bits. The alias name always
refer to a bus with the index [n-1:0].
• You can use the bit aliases defined here in the TestStep wrappers in the following
Verify wrappers:
o MembistVerify
o LogicbistVerify
o ScanVerify
• For user bit aliases associated with userIR bits, the value you specify applies only to the
register value, but not the value on the userBits port.
Example
In the following example, an alias is defined for a range of user bits.
UserBitAliases {
myBit: UserDrBit(3); //defines myBit[0:0]
myBit2: UserIRBit(3:2); //defines myBit2[1:0]
myBit3: UserDRBit(4:6); //defines myBit3[2:0]
}
UserDefinedTestPointMapping
The UserDefinedTestPointMapping wrapper specifies instance paths to where you want
ETAssemble to instantiate particular InjectControl and/or AddObservation cells.
Syntax
...
}
• PortOrInternalPinOrNetX — is a top-level port, internal pin, or net for which an

InjectControl or AddObservation cell is being inserted. A bus port must be specified
with a single bit or as a bus range.
• hierarchicalPathNameX — is a valid Verilog or VHDL instance name where an
InjectControl or AddObservation cell inserted on the specified port, internal pin, or net
is instantiated.
Default Value
If a pin is not specified, the testpoint cell location will be “.” which means the root module
unless the ETPlanner UserDefinedTestPointParentInstance property is specified.
Usage Conditions
The UserDefinedTestPointMapping wrapper is used in the LogicTest wrapper of the
.etassemble file.
• Specified ports, internal pins, or nets that do not have InjectControl or AddObservation
cells will be ignored. The location of a port, internal pin, or net is limited to the parent
module instance.
• You can specify pins or nets as a bus to reduce the number of edits needed in the
.etassemble file.
• A given instance path (hierarchicalPathNameX) for a port, internal pin, or net cannot
point to an instance inside a lower-level ELT core or block module.
Example
The following example identifies that the InjectControl or AddObservation cells inserted for
pins A[1] and b_2_buf/Y are to be instantiated within the instances tlb_inst and tlb_inst/
subBlock, respectively:
LogicTest {
A[1]: tlb_inst;
b_2_buf/Y : tlb_inst/subModule;
}
}
UserInstruction
The UserInstruction wrapper enables you to define an instruction code that ETAssemble
inserts in INSTRUCTION_OPCODE field in the BSDL file. You also can identify which user-
defined test-data register is to be selected for a specific instruction.
Syntax
RegisterAccess: <registerName>;
Code: <bitValue>;
Private: Yes | (No);
}
where InstructionName is the name associated with a specific instruction code.
Default Value
You must include at least one instruction code per UserInstruction wrapper.
Usage Conditions
The UserInstruction wrapper is used in the TAP wrapper.
Example
In this example, the syntax adds the instruction MyInstr1 and its associated values to the list of
instructions within the BSDL file.
Code: 17'b10000000000000000;
RegisterAccess: myReg2;
}
UserSignal
The optional UserSignal wrapper enables you to create an output port on the TAP controller
and to connect that port to a specific signal or port in your design. The signal is decoded by the
opcode specified using user-IR bits or user-DR bits.
Syntax
The following syntax specifies the UserSignal wrapper and its properties:
Code: <bitValue>;
Polarity: (activeHigh) | activeLow;
DecodeSource: (IR) | DR;
}
where TAPportName is the name of the output port created on the TAP controller.
Usage Conditions
The UserSignal wrapper is used in the TAP wrapper.
The following usage conditions apply to the UserSignal wrapper:
• You can create only a scalar port on the TAP using the UserSignal wrapper.
• You can specify the Code and Connection properties multiple times for user bits,
signals, and input ports or nets.
• If a UserSignal on the TAP fans out to logic designExtract must trace through, such as a
clock multiplexer. A hierarchical assert must be used to set the UserSignal to the correct
state. Note that the name of the hierarchical net in the Assert wrapper of the .designe file
must correspond to TAPportName in the UserSignal wrapper.
Example
ETAssemble uses the user-DR bits for decoding purposes and checks the three DR bits
specified. Finally, the TAP port is connected to the port u1/u2/u3/data[2] within the design.
UserSignal (myPort) {
Code: 3'b100;
DecodeSource: DR;
}
WTAP
The WTAP wrapper enables you to specify to ETAssemble the information about how to
customize, connect, and assemble the WTAP in the target design block.
Syntax
This wrapper includes the following syntax:
WTAP {
BlockedAuxiliaryPins: x;
Bypass: Yes | No;
DeviceIdCode: <number>;
ManufacturersIdCode: <number>;
RevisionCode: <number>;
MaxWRCKFreq: x;
NumberBistPorts: x;
NumberUserIRBits: x;
Connections{
}
AuxiliaryTestPort {
EnablePort:<HierarchicalPath>;
}
}
LeftIndex: x;
RightIndex: x;
}
}
Usage Conditions
None
ZeroCounterBits
The ZeroCounterBits property is rarely used and is automatically computed to be the log2 of
your longest BISR chain. For example, if your longest BISR chain is calculated to be 15k, then
the ZeroCounterBits will be automatically adjusted to be log2(15k) which is 14. Each power
domain group has a separate chain, and the value of the largest group is used to generate the
BISR controller hardware. The value assigned to this property has an impact on the number of
fuses required to store memory repair information.
Syntax
where int is the number of bits used for the Zero Counter.
Default Value
The default value is automatically adjusted to be log2 of your longest BISR chain.
Usage Conditions
• You rarely need to specify this property because the default value is automatically
adjusted to match your design. This value does not need to be exact; the BISR controller
will be functional even if the value is slightly higher or lower than the optimal value.
However, more fuses might be required to store the memory repair information. For
example, if ZeroCounterBits is set to 10 but the actual BISR chain length is such that
the value should have been set to 11, in some cases two zero counts instead of one--that
is, 2 * (10 + 1) = 22 fuses--are needed to represent the distance between two repair
words. The impact on the number of fuses depends on the average distance between
repair words.
• You might need to use this property if you are building your chip top level and your
child blocks are not yet equipped with BISR segments. In this case, the computed
longest BISR chain length might not reflect the proper future length because
ETAssemble assigns a default value to incomplete blocks. For more information, see the
“Performing Parent Memory BIST Insertion Before Child Regions” section in the “Flow
Variations” appendix of the Tessent MemoryBIST User’s and Reference Manual.
Example
This example specifies to ETAssemble to build a BISR controller with 10 bits.
MemBISR {
ZeroCounterBits: 10;
}
Chapter 4
Memory Library File
This chapter describes in detail the ETAssemble memory library file.

Chapter topics follow this sequence:
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Reference for Memory Library File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
MemoryTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
AddressCounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
ATD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
BistOrTMActive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
BitGrouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
BusRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CellName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
ColumnSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
ConcurrentRead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
CountRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
DataOutHoldWithInactiveReadEnable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
DataOutStage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Fuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
FuseMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
FuseSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
GroupWriteEnableMap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
LogicalAddressMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
LogicalPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
LogicalPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
LogicLow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
MemoryType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Memory Library File
Overview
MinHold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
NotAllocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
NumberOfBits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
NumberOfWords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
ObservationLogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
OperationSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
PhysicalAddressMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
PhysicalDataMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
PinMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
PipelineDepth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
RedundancyAnalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
RepairEnable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Retimed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
RowSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
RowSegmentRange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
SafeValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
SegmentAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
ShadowRead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
ShadowWrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
ShadowWriteOK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
ShiftedIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
ShiftedIORange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
SpareElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
TestInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
TestOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Overview
Every memory that you intend to test in your design must be described in a memory template.
Multiple instances of the same memory should use the same memory template. You can create a
separate memory library file for each memory template or group as many memory templates as
you want into the same memory library file.
Memory Library File
Overview
Note
Separate memory library files are required for the shared bus interface implementation. For
more information, see the “Memory Shared Bus Interface” appendix in the Tessent
The memory library file consists of the following major sections:
• MemoryTemplate wrapper in this chapter. This section is mandatory.

• OperationSet wrapper described in Reference for OperationSet Wrapper Contents in
the Tessent MemoryBIST User’s and Reference Manual. This section is optional.
• Algorithm wrapper described in “Reference for Algorithm Wrapper Contents” in the
Tessent MemoryBIST User’s and Reference Manual. This section is optional.
Note
Each of these sections can be contained in a separate file, but all files must be read in
together.
Memory Library File
Reference for Memory Library File Syntax

The following sections provide descriptions of the available wrappers and properties of the
memory library file.
MemoryTemplate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
AddressCounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
ATD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
BistOrTMActive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
BitGrouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
BusRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CellName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
ColumnSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
ConcurrentRead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
CountRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
DataOutHoldWithInactiveReadEnable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
DataOutStage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Fuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
FuseMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
FuseSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
GroupWriteEnableMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
LogicalAddressMap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
LogicalPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
LogicalPorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
LogicLow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
MemoryType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Memory Library File
MinHold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
NotAllocated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
NumberOfBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
NumberOfWords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
ObservationLogic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
OperationSet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
PhysicalAddressMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
PhysicalDataMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
PinMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
PipelineDepth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
RedundancyAnalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
RepairEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Retimed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
RowSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
RowSegmentRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
SafeValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
SegmentAddress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
ShadowRead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
ShadowWrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
ShadowWriteOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
ShiftedIO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
ShiftedIORange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
SpareElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
TestInput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
TestOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Memory Library File
MemoryTemplate
MemoryTemplate
The memory library file begins with the following wrapper:
MemoryTemplate (<memoryTemplateName>) {
where memoryTemplateName is the name of the template.
Note
Within the MemoryTemplate wrapper, you can specify several primary sections in any
order. You do not need to include in your memory library file all of the sections shown or all
the properties listed.
Figure 4-1 summarizes the complete syntax of the memory library file wrappers and properties.
Memory Library File
MemoryTemplate
Figure 4-1. Memory Library File
MemoryTemplate (<memoryTemplateName>) {
// Begin Memory Template Section
Algorithm: ReadOnly | SMarch |SMarchCHKB | (SMarchCHKBci) |
SMarchCHKBcil | SMarchCHKBvcd | LVMarchX | LVMarchY |
LVMarchCMinus | LVMarchLA | LVRowBar | LVColumnBar |
LVGalPat | LVGalColumn | LVGalRow | LVCheckerboard1X1 |
LVCheckerboard4X4 | LVWalkingPat | LVBitSurroundDisturb |
LVAddressInterconnect | LVDataInterconnect |
<algorithmName>;
ATD: On | (Off);
BitGrouping: x;
CellName: <memoryModuleName>;
ConcurrentRead: On | (Off);
ConcurrentWrite: On | (Off);
DataOutHoldWithInactiveReadEnable: (On) | Off;
DataOutStage: (None) | StrobingFlop;
InternalScanLogic: On |(Off);
LogicalPorts: [xR] [yW] [zRW];
MemoryHoldWithInactiveSelect: (On) | Off;
MemoryType: ROM | (SRAM) | DRAM;
MilliWattsPerMegaHertz: <real>;
MinHold: <holdTime>;
NumberOfBits: x | <UserVariable>;
NumberOfWords: x | <UserVariable>;
ObservationLogic: (On) | Off;
OperationSet: Async | AsyncWR | ROM | (Sync) | SyncWR |
<operationSetName>;
PipelineDepth: <integer>;
ReadOutOfRangeOK: On | (Off);
RetentionTimeMax: time[s | (ms) | us | ns | ps];
ROMContentsFile: <ROMContentsFileName>;
ShadowRead: On | Off;
ShadowWrite: On | (Off);
ShadowWriteOK: On | (Off);
TransparentMode: (SyncMux) | None | AsyncMux;
// Begin AddressCounter Section
AddressCounter {
Function (Address) {
LogicalAddressMap {
ColumnAddress[x:y] : Address[a:b];
RowAddress[x:y] : Address[a:b];
BankAddress[x:y] : Address[a:b];
} //End of LogicalAddressMap wrapper
} //End of Function(Address) wrapper
Function (ColumnAddress | RowAddress | BankAddress) {
CountRange: [<lowRange>:<highRange>];
} //End of Function (...) wrapper
} //End of AddressCounter wrapper
//Begin physical address map section
PhysicalAddressMap {
ColumnAddress[x]: <expression>;
.
.
RowAddress[x]: <expression>;
.
Memory Library File
MemoryTemplate
.
BankAddress[x]: <expression>;
.
.
} //end of PhysicalAddressMap wrapper
// Begin physical data map section
PhysicalDataMap {
Data [x]: [not] d[index] [xor <expression>]...;
.
.
.
} //End of PhysicalDataMap wrapper
// Begin GroupWriteEnableMap section
GroupWriteEnableMap {
GroupWriteEnable[gwe_bit]: d[bit_or_range], ...;
.
.
.
} //End of GroupWriteEnableMap wrapper
// Define Port wrapper
Port (<portName>[LeftIndex:RightIndex]) {
BusRange: [LeftIndex:RightIndex];
Direction: InOut | (Input) | Output;
DisableDuringScan: On | Off;
Function: Address | BistEn | BistOn | Clock | Data |
GroupWriteEnable |LogicHigh | LogicLow |(None) | Open|
OutputEnable | ReadEnable | ScanTest | Select |
ShadowAddressEnable | ShiftEnable | WriteEnable | CAS |
RAS | User0 | User1 | User2 | User3 | User4 | User5 |
User6 | User7 | User8 | User9 | User10 | User11 | User12 |
User13 | User14 | User15 | User16 | User17 | User18 |
User19 | User20 | User21 | User22 | User23 | Refresh |
Activate | Precharge | ValidData | BisrParallelData |
BisrSerialData | BisrClock | BisrReset | BisrScanEnable;
LogicalPort: <logicalPortID>;
Polarity: (ActiveHigh) | ActiveLow;
Retimed: On | (Off);
SafeValue: (X) | 0 | 1;
EmbeddedTestLogic {
TestInput: <portName>[LeftIndex:RightIndex];
TestOutput: <portName>[LeftIndex:RightIndex];
}
} //end of Port wrapper
.
. //Repeat this syntax until you define all BIST ports.
.
//Begin BIRA section
RedundancyAnalysis {
ColumnSegmentRange {
SegmentAddress [<bitIndex>]: AddressPort(<name>);
.
. //Repeat for all SegmentAddress bits
.
}
ColumnSegment {(<SegmentName>)
ColumnSegmentCountRange [<lowRange>:<highRange>];
RowSegmentCountRange [<lowRange>:<highRange>];
NumberOfSpareElements <Int>;
Memory Library File
MemoryTemplate
ShiftedIORange: <dataPortName>,<dataPortName>,...;
FuseSet {
Fuse: [<bitIndex>]: AddressPort(<name>) |
not AddressPort (<name>) |
LogicHigh | LogicLow;
.
. //Repeat for all Fuse bits
.
FuseMap [<HighBitRange>:<LowBitRange>] {
NotAllocated: <bitString>;
ShiftedIO: (<DataPortName>): <bitString>;
.
. //Repeat for all IO within ShiftedIORange
.
}
}
PinMap {
SpareElement {
RepairEnable: <repairPortName> |
RepairRegister[bitIndex];
Fuse [bitIndex]: <repairPortName> |
FuseMap [bitIndex]: <repairPortName> |
LogicLow: <pinName> | RepairRegister[<x>];
}
.
. // Repeat for all SpareElements
.
}
}
.
. //Repeat for all ColumnSegments
.
RowSegmentRange {
SegmentAddress [bitIndex]: AddressPort(<name>);
.
.
}
RowSegment (<segmentName>) {
NumberOfSpareElements: <integer>;
RowSegmentCountRange [<lowRange>: <highRange>];
ColumnSegmentCountRange [<lowRange>: <highRange>];
FuseSet {
Fuse [bitIndex]: AddressPort(<name>) |
not AddressPort(<name>) |
.
.
}
PinMap {
SpareElement {
RepairEnable: <repairPortName> | RepairRegister[bitIndex];
Memory Library File
MemoryTemplate
}
.
.
}
}
. //Repeat for all RowSegments
.
} //End of RedundancyAnalysis wrapper
} //End of MemoryTemplate wrapper
//Begin Programmability Section for Tessent MemoryBIST.

// Consists of Algorithm wrapper
Algorithm (<AlgorithmName>) {
... //The contents of this wrapper are described in detail in the
// Tessent MemoryBIST User’s and Reference Manual.
}//End of Algorithm wrapper
OperationSet(<operationSetName>) {
... //The contents of this wrapper are described in detail in the
// Tessent MemoryBIST User’s and Reference Manual.
} //End of OperationSet wrapper
Memory Property Section

The Memory Property section of the memory library file defines the physical attributes of the
memory, such as the number of words and bits, the interface timing, and the type of bypass
mode implemented for scan testing. Typically, this section immediately follows the
MemoryTemplate wrapper.
Syntax
Figure 4-2 summarizes the memory properties.
Memory Library File
AddressCounter
Figure 4-2. Memory Property Section Syntax
Algorithm: ReadOnly | SMarch |SMarchCHKB | (SMarchCHKBci) |

SMarchCHKBcil | SMarchCHKBvcd | LVMarchX | LVMarchY |
LVMarchCMinus | LVMarchLA | LVRowBar | LVColumnBar |
LVGalPat | LVGalColumn | LVGalRow | LVCheckerboard1X1 |
LVCheckerboard4X4 | LVWalkingPat | LVBitSurroundDisturb |
LVAddressInterconnect | LVDataInterconnect | <algorithmName>;
ATD: On | (Off);
BitGrouping: x;
InternalScanLogic: On |(Off);
MemoryType: ROM | (SRAM) | DRAM;
MinHold: <holdTime>;
NumberOfBits: x | <UserVariable>;
NumberOfWords: x | <UserVariable>;
OperationSet: Async | AsyncWR | ROM | (Sync) | SyncWR |
<operationSetName>;
RetentionTimeMax: time[s] | (ms) | us | ns | ps;
AddressCounter
The AddressCounter wrapper can segment the address bits into a row segment and a column
segment. Typically, the lower address bits correspond to the column segment and the higher
address bits correspond to the row segment.
Note
The Programmable memory BIST controller supports testing of memories with asymmetric
banks containing a different number of rows per bank. For more information about
asymmetric banks, refer to the NumberOfWords and CountRange properties.
Note
Shadow read operations, memory templates with the PhysicalDataMap wrapper and/or the
PhysicalAddressMap wrappers, and all checkerboard algorithms require segmented
addresses. All checkerboard algorithms require a segmented address counter to build the correct
physical one-by-one checkerboard pattern.
Memory Library File
Algorithm
Syntax
AddressCounter {
LogicalAddressMap {
ColumnAddress[x:y]: Address[a:b];
RowAddress[x:y]: Address[a:b];
BankAddress[x:y]: Address[a:b];
} //end of LogicalAddressMap wrapper
} //end of Function(Address) wrapper
Function (ColumnAddress | RowAddress |BankAddress) {
CountRange [lowRange:highRange];
} //end of Function(...) wrapper
} //end of AddressCounter wrapper
Default Value
This wrapper is mandatory.
Algorithm
The Algorithm property identifies the type of the default algorithm that the memory BIST
controller uses to test the memory.
Syntax
Algorithm: ReadOnly | SMarch |SMarchCHKB |

(SMarchCHKBci) | SMarchCHKBcil | SMarchCHKBvcd |
LVMarchX | LVMarchY | LVMarchCMinus | LVMarchLA |
LVRowBar | LVColumnBar | LVGalPat | LVGalColumn |
LVGalRow | LVCheckerboard1X1 |LVCheckerboard4X4 | LVWalkingPat |
LVBitSurroundDisturb |LVAddressInterconnect | LVDataInterconnect |
<algorithmName>;
For the details on the Algorithm values, refer to “Memory BIST Algorithms” in the Tessent
Default Value
The default value for this property is SMarchCHKBci.
Usage Conditions
The Algorithm property is used in the MemoryTemplate wrapper.
Memory Library File
Algorithm
• The ReadOnly algorithm can only be used for MemoryType ROM.

• A ROM memory type can only use the ReadOnly algorithm.
• The SMarchCHKBvcd algorithm is only applicable to specific port configurations:
• One Read-Write port (1RW)
• Two Read-Write ports (2RW)
• One Read-only port and one Write-only port (1R1W)
• Two Read-only ports and two Write-only ports (2R2W)
• The following algorithms are only applicable to Programmable controllers—
LVMarchX, LVMarchY, LVMarchCMinus, LVMarchLA, LVRowBar, LVColumnBar,
LVGalPat, LVGalColumn, LVGalRow, LVCheckerboard1x1, LVCheckerboard4x4,
LVWalkingPat, LVBitSurroundDisturb, LVAddressInterconnect, LVDataInterconnect.
• The following algorithms are only applicable to memories for which the ETPlanner
property BitSliceWidth is set to 1: SMarchCHKBvcd, LVMarchX, LVMarchY,
LVMarchCMinus, LVMarchLA, LVRowBar, LVColumnBar, LVGalPat,
LVGalColumn, LVGalRow, LVCheckerboard1X1, LVCheckerboard4X4,
LVWalkingPat, LVBitSurroundDisturb, LVAddressInterconnect, LVDataInterconnect.
• The ETPlanner property RAMAlgorithm overrides the value of this property in the
memory library file.
• A custom algorithm name might be specified.
• The SMarchCHKBvcd algorithm performs specialized tests on the chip select and read
enable ports. To use this algorithm, the memory data output value must be preserved
when the chip select or read enable port is deasserted.
Example
This example illustrates specifying algorithms for testing the memories in your design.
LogicalPorts:1RW;
Algorithm: SMarchCHKB;
.
.
.
Note
You cannot specify a different algorithm for two instances of the same memory. To specify
different algorithms, create a new memory template and specify a different algorithm.
Memory Library File
ATD
ATD
The sections below provide detailed information on the following usage of the ATD property:
• MemoryTemplate Usage
• Tick Usage
MemoryTemplate Usage
The ATD property supports address transition detection (ATD). With ATD, the memory
requires that the address must change in order for the memory BIST controller to read data from
the memory.
Syntax
ATD: On | (Off);
• On — forces the address of the memory to change so that data can be read out of the
memory being tested. Specify On for memories that require an address transition to
initiate a read cycle.
• Off — specifies memories without ATD.
Default Value
The default value is Off.
Usage Conditions
The ATD property is used in the MemoryTemplate wrapper.
• The OperationSet property section in the memory library file must specify an ATD
waveform.
• If your address counter is not segmented, the value specified for NumberOfWords must
be even.
• If your address counter is segmented into a row address (AddressCounter: Function
(RowAddress)) and a column address (AddressCounter: Function (ColumnAddress)),
you must specify an even value for lowRange and an odd value for highRange in
Function (ColumnAddress): CountRange.
The restrictions relating to the address counter prohibit an out-of-range address that is
caused by inverting bit0 of the row address counter when the ATD waveform is on.
Memory Library File
BistOrTMActive
Example
The following example indicates that the memory supports address transition detection:
MemoryTemplate (MEM) {
ATD: On;
}
Tick Usage
The ATD property controls activation of address transitions for memories with
addresstransition-detect (ATD) interfaces.
Syntax
ATD: On | (Off);
Usage Conditions
The ATD property is used in the OperationSet: Tick wrapper.
BistOrTMActive
The BistOrTMActive property specifies if the memory control port should be driven during
both BIST and scan test.
Syntax
BistOrTMActive: On | (Off);
• On — instructs ETAssemble to make the select ports active during both scan test and
BIST.
• Off — instructs ETAssemble to handle the port as necessary for BIST.
Default Value
Usage Conditions
The BistOrTMActive property is used in the Port wrapper.
Memory Library File
BitGrouping
• This property is applicable to control ports defined with function Activate, Precharge,
Refresh, Select, OutputEnable, RAS, CAS, WriteEnable or GroupWriteEnable.
Example
This example specifies that the select port should be driven active during both BIST and scan
test.
Port (CE) {
Function: Select;
BistOrTMActive: On;
}
BitGrouping
Modern memories are designed to form physical arrays of cells with minimum layout spacing
design rules to reduce area. Memory designers also use different strategies to achieve higher
performance by manipulating the way the memory bits are distributed in the physical array.
Some memories might be designed to allow the data bit of a word be next to each other in the
array. Other memories might have them distributed in the array in a systematic way.
Usage
The BitGrouping property allows you to specify the distribution of the data bits in the memory
array. This information is required by some of Tessent MemoryBIST algorithms to construct a
contiguous checkerboard pattern within the bit arrays. Specifically, the following algorithms
use this property during the checkerboard phases:
• SMarchCHKB
• SMarchCHKBci
• SMarchCHKBcil
• SMarchCHKBvcd
During the checkerboard phases of the algorithm the BIST data written and read from the
memory is modified at the memory interface/collar to ensure the memory contains
checkerboard patterns.
The following examples will help to clarify what that means.
Example 1
Consider the physical layout of a 8-bit memory in which data is stored in columns. That is,
data[0] will be placed under column 0, data[1] will place in column 1, data[2] will be in column
2,.., data [7] will be in column 7. Sometimes this type of memory is referred to as a word-
oriented memory. The memory BIST controller applies a checkerboard pattern to the memory
Memory Library File
BitGrouping
by alternating values of 0 and 1 in the address locations, as shown. For this memory, the
BitGrouping is equal to the data width, which is 8.
The numbers 0-7 represent the physical data bits 0-7.
Example 2
Many memories are designed to gather bits from different addresses with the same data
reference into the same array. That is, the memory has separate arrays for each bit of the word.
Here is an example of a memory with 4 data bits. There are four arrays with each array has the
specific data bit reference. The BitGrouping property for this type of memory should be defined
with a value of 1.
Memory Library File
BitGrouping
Example 3
Consider a memory where only three of the consecutive data bits are physically gathered in the
array. The physical layout of a 6-bit memory that is broken into two arrays. This example shows
a bit grouping of 3.
To access bit0 of the first row, specify the column address y0 to select the correct bit0. The
checkerboard pattern for this grouping needs a 1 in the first bit0 and a 0 in the second bit0 of the
same row. Specifying BitGrouping 3 for this example enables the hardware to make this
correction.
Syntax
The syntax for this property is as follows:
BitGrouping: x;
where x is an integer. The specified value must be less than or equal to the value specified for
the NumberOfBits property.
Default Value
This property defaults to 1 when the memory address port has at least one column address bit,
otherwise it will resolve to the value specified for the NumberOfBits property.
Usage Conditions
The BitGrouping property is used in the MemoryTemplate wrapper.
The BitGrouping property only affects the following checkerboard algorithms—SMarchCHKB,

SMarchCHKBci, SMarchCHKBcil, and SMarchCHKBvcd.
Example
This example specifies that the memory replicates in groups of 2 bits.
BitGrouping: 2;
Memory Library File
BusRange
BusRange
The BusRange property specifies the range for a bused port.
Note
The specification of this property is not necessary for single-bit ports.
Syntax
BusRange: [LeftIndex:RightIndex];
where [LeftIndex:RightIndex] identifies the range for bused ports. For a discussion about the
valid data types for LeftIndex and RightIndex. Refer to Syntax Rules.
Default Value
If you do not specify BusRange and the Port wrapper’s portName does not specify [x:y],
ETAssemble assumes the specified port is a single-bit port.
Usage Conditions
The BusRange property is used in the Port wrapper.
• If you included the range for a bused port in the portName of the Port wrapper, you do
not need to specify BusRange.
• If you included a %d character identifier for portName in the Port wrapper, you must
specify BusRange.
• If you did not include the range for a bused port or the %d character identifier for
portName in the Port wrapper and the Function property specifies either Data or
GroupWriteEnable, then BusRange RightIndex must be 0.
Example
This example specifies an 8-bit bused port.
BusRange: [7:0];
CellName
The CellName property provides the entity or the module name for the memory.
Memory Library File
ColumnSegment
Syntax
where memoryModuleName is the entity or the module name for the memory.
Default Value
If CellName is missing from both the memory library and ETAssemble configuration files,
ETAssemble uses the value specified for MemoryTemplate as the entity or the module name.
Usage Conditions
The CellName property is used in the MemoryTemplate wrapper.
Example
This example specifies that the entity or the module name of the memory is SRAM256X32.
CellName: SRAM256X32;
ColumnSegment
The ColumnSegment wrapper enables you to identify a segment of the memory address space
which contains spare IO/Column elements. The column segment can be the whole address
space or a subset of the address space. Specify this wrapper in the RedundancyAnalysis wrapper
to implement IO/Column repair analysis.
Memory Library File
ColumnSegment
Syntax
ColumnSegment (<SegmentName>) {
NumberOfSpareElements : <int>;
ShiftedIORange: <dataPortName>,...;
FuseSet {
Fuse[<bitIndex>]: AddressPort(<name>) |
.
.
FuseMap[<HighBitRange>:<LowBitRange>] {
ShiftedIO(<DataPortName>):<bitString>;
.
.
}
}
PinMap {
SpareElement {
Fuse [<bitIndex>]: <repairPortName> |
FuseMap[<bitIndex>]: <repairPortName> |
.
.
}
}
}
.
.
where SegmentName is a unique identifier for the memory segment.
Default Value
None
Usage Conditions
The ColumnSegment wrapper is used in the RedundancyAnalysis wrapper.
Memory Library File
ColumnSegmentCountRange
Example
The following example specifies the segment ALL for the entire address space:
ColumnSegment (ALL) {
ShiftedIORange: D[7:0];
.
.
}
ColumnSegmentCountRange property:
• ColumnSegment Usage
• RowSegment Usage
ColumnSegment Usage
The ColumnSegmentCountRange property defines the portion of the column address space
where the segment’s spare elements can replace a defective IO/Column element.
Syntax
• lowRange— specifies the low address value in terms of the defined segment address bits
used to enable the repair analysis for this segment.
• highRange— specifies the high address value in terms of the defined segment address
bits used to enable the repair analysis for this segment.
Valid data types for lowRange and highRange are integers or BitsValues.
Default Value
If any SegmentAddress bits are specified in the ColumnSegmentRange wrapper, the
ColumnSegmentCountRange property defaults to a lowRange of zero to a highRange of 2n -1,
where n is the number of SegmentAddress bits specified.
Usage Conditions
The ColumnSegmentCountRange property is used in the ColumnSegment or RowSegment
wrapper.
Memory Library File
• The ColumnSegmentCountRange property can be specified only when at least one

SegmentAddress bit is defined.
• When more than one ColumnSegment wrapper is specified, the combined count ranges
of all ColumnSegmentCountRange properties must encompass all possible codes
defined by the SegmentAddress properties of the ColumnSegmentRange wrapper. Any
unused codes must be explicitly indicated within the range values of the
ColumnSegmentCountRange property.
Example
In the following example, column segment Bank0 will be enabled when address port AD[11] is
logic 0 and AD[10] is logic 0. Column segment Bank1 will be enabled for all remaining AD[11]
and AD[10] combinations.
SegmentAddress[1]: AddressPort(AD[11]);
}
ColumnSegment(Bank0) {
ColumnSegmentCountRange[2'b00:2'b00];
.
.
.
}
.
.
.
}
RowSegment Usage
The ColumnSegmentCountRange property defines the portion of the column address space
where the segment’s spare elements can replace a defective row element.
Syntax
• lowRange — specifies the low address value in terms of the defined segment address
bits used to enable the redundancy analysis for this segment.
• highRange — specifies the high address value in terms of the defined segment address
Memory Library File
Note
lowRange and highRange must be specified in Verilog format; i.e., 4'b1001 not as plain
integers like 9.
Default Value
If any SegmentAddress bits are specified in the ColumnSegmentRange wrapper, the
ColumnSegmentCountRange property defaults to a lowRange of zero and to a highRange of 2n
-1, where n is the number of SegmentAddress bits specified.
Usage Conditions
The ColumnSegmentCountRange property is used in the RowSegment or ColumnSegment
wrapper.
• The ColumnSegmentCountRange property can be specified only when at least one

• When more than one RowSegment wrapper is specified, the combined count ranges of
all ColumnSegmentCountRange properties must encompass all possible codes defined
by the SegmentAddress properties of the ColumnSegmentRange wrapper. Any unused
codes must be explicitly indicated within the range values of the
ColumnSegmentCountRange property.
Example
In the following example, row segment Bank0 will be enabled when address port AD[0] is logic
0. Bank1 will be enabled when AD[0] is logic 1.
}
RowSegment(Bank0) {
.
.
.
}
RowSegment(Bank1) {
.
.
.
}
Memory Library File
ColumnSegmentRange
ColumnSegmentRange
The ColumnSegmentRange wrapper enables you to define a portion of the memory address
space where spare element can replace a defective element. The ColumnSegmentRange is used
to define the significant column bits of the address bus that are used by the
ColumnSegmentCountRange property inside the ColumnSegment and RowSegment
wrappers.
Syntax
SegmentAddress[<bitIndex>]: AddressPort(<name>);
.
. Repeat for all SegmentAddress bits
.
}
Default Value
None
Usage Conditions
The ColumnSegmentRange wrapper is used in the RedundancyAnalysis wrapper.
Example
This example divides the memory address space into 2 column segments called BANK0 and
BANK1. The address range of each column segment is defined by address port AD[7].
ColumnSegmentRange{
}
ColumnSegment (BANK0) {
ColumnSegmentCountRange [1'b0:1'b0];
}
ColumnSegment (BANK1) {
ColumnSegmentCountRange [1'b1:1'b1];
}
ConcurrentRead
Multi-port memories exhibit defects related to inter-port interaction. Such defects require
special test algorithms that enable the sensitization and detection of these defects. The
ConcurrentRead property enables you to perform simultaneous read operations from two
different read ports.
ConcurrentRead provides more flexibility than ShadowRead in that it allows modification of

both the row and column address from the operation set, and is therefore preferred when
Memory Library File
ConcurrentWrite
creating custom operation sets for a programmable controller. ShadowRead only allows
modification to the row address.
Syntax
• On — inserts logic in the memory interface circuit to support concurrent read.

• Off — specifies that concurrent read operations will not be applied to this memory.
Default Value
The default is Off.
Usage Conditions
The ConcurrentRead property is used in the MemoryTemplate wrapper.
• This property is not supported for ROM or 1RW memory.
Note
If the above conditions are not met, ETAssemble issues a warning and forces the
ConcurrentRead property to Off.
Example
This example specifies that logic is inserted into the controller and memory interface to support
the concurrent operations:
ConcurrentRead: On;
}
ConcurrentWrite
Multi-port memories exhibit defects related to inter-port interaction. Such defects require
special test algorithms that enable the sensitization and detection of these defects. The
ConcurrentWrite property enables you to perform simultaneous write operations from two
different write ports with different data combinations. When ConcurrentWrite is set to On, the
generated memory interface will support concurrent operations.
Memory Library File
ConcurrentWrite
ConcurrentWrite provides more flexibility than ShadowWrite. ConcurrentWrite allows

modification of both the row and column address, as well as the data pattern, from the selected
operation set and is therefore preferred when creating custom operation sets for a programmable
controller. ShadowWrite is only used by library algorithms and is not controllable from the
operation set.
Syntax
• On — inserts logic in the memory interface circuit to support concurrent write.

• Off — specifies that concurrent write operations will not be applied to this memory.
Default Value
The default is Off.
Usage Conditions
The ConcurrentWrite property is used in the MemoryTemplate wrapper.
• The memories must have ONE of the following combinations of ports:

• Two ReadWrite ports
• One Read-only port and one Write-only port
• Any number of Read-only ports and two Write-only ports
• The BitSliceWidth specified in the controller step should be 1.
Note
If the above conditions are not met, ETAssemble issues a warning and forces the
ConcurrentWrite property to Off.
Example
This example specifies that logic is inserted into the memory interface to support the concurrent
operations.
ConcurrentWrite: On;
}
Memory Library File
CountRange
CountRange
The CountRange property specifies a single count range on all logical ports for the column,
row, or bank address.
Syntax
AddressCounter {
Function (ColumnAddress | RowAddress | BankAddress){
}
}
where valid data types for lowRange and highRange are integers or BitsValue.
Note
You can specify lowRange and highRange in any order. ETAssemble considers the integer
or BitsValue with the lower value as lowRange and the integer or BitsValue with the higher
value as highRange.
Default Value
The default value of the CountRange property is [0:2n-1] where n is the number of address bits
specified for ColumnAddress, RowAddress, or BankAddress in the LogicalAddressMap
wrapper.
Usage Conditions
The CountRange property is used in the Function wrapper.
• For ROMs with segmented address counters, Function (ColumnAddress): CountRange

must end at the maximum value, 2n-1, and Function (RowAddress): CountRange must
start at 0. If you do not meet these conditions, the counting order will not match the
ROM contents file and the signature will be wrong.
• The Programmable memory BIST controller supports testing of memories with
asymmetric banks containing a different number of rows per bank. If this is the case:
• You must explicitly specify the CountRange for all existing memory address segments
in the memory library file.
• You must ensure that the address count range specified by the properties in the
AddressCounter wrapper is contiguous. In other words, the valid memory address range
is 0 to NumberOfWords -1.
Memory Library File
Data
• You must specify the highRange for the RowAddress segment for the bank(s) with the
largest number of rows.
Example
Acceptable entries for CountRange for a 10-bit row address segment counting from 0 to 1023
are as follows:
CountRange [0:1023];
CountRange [10'b1111111111:0];
CountRange [10'h3FF:10'h000];
CountRange [1023:0];
Data
The sections below provide detailed information on the following usage of the Data property:
• Tick Usage
• PhysicalDataMap Usage
Tick Usage
The Data property enables the tri-state driver on the memory BIST collar. This property
specifies when data are read from or written to the memory for a bidirectional data bus.
Note
For memories with bidirectional data buses, you cannot use the built-in operation sets. The
Tick wrappers in the built-in operation sets do not include Data entries. In order for memory
BIST controller to test your memory, you need to switch control between the OutputEnable of
the memory and the OutputEnable of the memory BIST collar.
Syntax
Data: Pattern | (Z);
PhysicalDataMap Usage
The PhysicalDataMap is an independent wrapper for the Data property that provides
information to facilitate the mapping between the data input ports of the memory and the
internal data lines. Because physical memory cells are arranged in a particular order to facilitate
layout, you must provide this information so that ETAssemble can correctly generate the
checkerboard patterns.
Memory Library File
Data
Syntax
PhysicalDataMap {
Data[x]: [not] d[index] [xor <expression>]...;
.
.
.
}
• Data[x] represents the physical data port of the memory.

• d[y] identifies the physical data bit controlled by the memory BIST controller.
• <expression> is <counterBit> | ([not] <counterBit> and [not] <counterBit>)
The parentheses in the preceding expression are literal characters.
• <counterBit> is c[index] | r[index]
where c[index], r[index] represent the counter bits used to generate the column and row
addresses.
When specifying the mapping between the data input ports of the memory and the
internal data lines, you must follow these rules:
o Data[indexes] must be contiguous, as follows:
PhysicalDataMap {
Data[0]: d[0];
//ERROR: missing Data[1]
Data[2]: d[2];
Data[3]: d[3];
}
o d[index] must use every Data[index] exactly once. For example,

PhysicalDataMap {
Data[0]: d[0];
Data[1]: d[0];
//ERROR: d[0] used more than
//once. d[1] missing.
}
Default Value
If your memory library files do not include a physical data map wrapper, ETAssemble assumes
a one-to-one mapping, Data[n]: d[n].
Usage Conditions
The Data property is used in the PhysicalDataMap wrapper.
Memory Library File
DataOutHoldWithInactiveReadEnable
• The address counter bit specified in the physical data map equation must be defined in
the AddressCounter wrapper of your memory library file.
• The data bus must be an even multiple of the size of the physical data map wrapper.
ETAssemble repeats the entire physical data map wrapper to produce a map wide
enough for the actual data bus.
Example
The following example shows the Data property entries for a 4-bit wide memory:
PhysicalDataMap {
Data[0]: not d[0];
Data[1]: d[1];
}
DataOutHoldWithInactiveReadEnable
The DataOutHoldWithInactiveReadEnable property describes the memory behavior when the
read enable control signal is inactive.
Syntax
DataOutHoldWithInactiveReadEnable: (On) | Off;
• On — holds the memory output when the read enable control signal is inactive.
• Off — may not hold the memory output when the read enable control signal is inactive.
Default Value
The default is On.
Usage Conditions
The DataOutHoldWithInactiveReadEnable property is used in the MemoryTemplate wrapper.
• If the memory output does not hold when the read enable control signal is inactive and
you want to test the memory with the SMarchCHKBvcd algorithm, you must set
DataOutHoldWithInactiveReadEnable to Off.
Memory Library File
DataOutStage
Example
The following example shows that the memory under test may not hold memory output when
the read enable control signal is inactive:
DataOutHoldWithInactiveReadEnable: Off;
DataOutStage
The DataOutStage property controls whether or not ETAssemble uses a strobing flip-flop on
output data to meet the hold time in a memory that cannot safely write the data from a previous
read operation. Typically, this property is used when the memory is tested with the serial
interface approach (BitSliceWidth property > 1). The flip-flop is inserted on the path from the
memory data output to the data input. When the BitSliceWidth property is 1, specifying a
strobing flip-flop effectively provides one stage of pipelining between the data output and the
comparator logic.
Syntax
• None — does not add a latch or a flip-flop between DataOut and DataIn.
• StrobingFlop — inserts a flip-flop to strobe DataOut. This property is used when the
data output of the memory is not latched or registered. For scan testing, the strobing flip-
flop is reused to implement the bypass mode specified by the TransparentMode:
SyncMux setting. Refer to Figure 4-3 for illustration.
Memory Library File
DataOutStage
Figure 4-3. Single Port Memory With BitSlice=2 and StrobingFlop Registers
Compare with the ETPlanner PipelineSerialDataOut property in the manual ETPlanner Tool
Reference.
Memory Library File
DataOutStage
Default Value
The default value depends upon the data bus. If the data bus is not bidirectional, the
DataOutStage property defaults to None.
Usage Conditions
The DataOutStage property is used in the MemoryTemplate wrapper.
Note
Simulation fails when using StrobingFlop, Sync operation set, and when bit-slice is greater
than 1 (that is, a serial interface is present in the memory collar).
• When using the StrobingFlop value, a custom operation set is required when the
algorithm is not SMarchCHKBvcd and the BitSliceWidth is greater than 1. The custom
operation set prevents the simulation from failing.
The interface hardware implements the serial interface, and the strobing flip-flops are
inserted on the data feedback path. In the custom operation set, the ReadModifyWrite
Operation must account for the pipelining due to the strobing flip-flops within the serial
interface; the write access must occur after the memory output is sampled by the
strobing flip-flops. To accomplish this, extend the ReadModifyWrite operation by 1
cycle and set WriteEnable to On in the Tick wrapper that follows the Tick wrapper
specifying StrobeDataOut as in the following example:
OperationSet (sync_strobeFF) {
Operation (ReadModifyWrite) {
Tick {
ReadEnable: On; //Activate read from memory
}
Tick {
ReadEnable: Off;
StrobeDataOut; //Sample memory output into strobing flip-
flops
}
Tick {
WriteEnable: On; //Activate write to memory
}
}
}
• Memories within the same Step wrapper cannot specify DataOutStage: StrobingFlop
when PipelineSerialDataOut is set to either Yes or PerPort; only one stage of output
pipelining is allowed.
Memory Library File
Direction
Example
The following example inserts strobing flip-flops at the memory output:
MemoryTemplate(MEM) {
DataOutStage: StrobingFlop;
.
.
}
Direction
The Direction property specifies the direction of the memory port.
Syntax
• InOut — identifies a bidirectional data port.

• Input — identifies a port as an input to the memory.
• Output — identifies a port as an output from the memory.
Default Value
This property defaults to Input.
Usage Conditions
The Direction property is used in the Port wrapper.
• If Direction is InOut, you must associate the bidirectional data port with an output
enable port.
If Function is set to either Data or None, you must specify Direction.
Example
This example specifies that the DIN signal is an input.
Port (DIN) {
Function: Data;
Direction: Input;
BusRange: [7:0];
}
Memory Library File
DisableDuringScan
DisableDuringScan
The DisableDuringScan property specifies if specific memory ports are to be disabled during
scan and logic test. The functional input is gated with the scan and logic test mode signal
LV_TM within the memory collar or interface. Setting DisableDuringScan to On prevents the
memory from being activated by functional logic during scan and logic test. Therefore, the
power requirement is minimized.
Syntax
• On — instructs ETAssemble to make this memory port inactive during scan and logic
test.
• Off — instructs ETAssemble to not add the gating capability.
Default Value
The default value is On for the applicable Port functions.
Usage Conditions
This property is used in the Port wrapper.
• The DisableDuringScan property can be used only for ports with the Function property
set to either Activate, CAS, Precharge, RAS, Refresh, Select, InterfaceReset,
ReadEnable, GroupWriteEnable, WriteEnable, or User<0...23>.
Example
The following example specifies that the functional select port ENA is to be inactive during scan
and logic test:
Port (ENA) {
Function: Select;
DisableDuringScan: On;
EmbeddedTestLogic {
TestInput: TENA;
TestOutput: ENAOBS;
}
EmbeddedTestLogic
The EmbeddedTestLogic wrapper describes any embedded test interface feature that exist for
the functional port being defined.
Memory Library File
EmbeddedTestLogic
Syntax
EmbeddedTestLogic {
}
Default Value
None
Usage Conditions
The EmbeddedTestLogic wrapper is used in the Port wrapper.
• EmbeddedTestLogic wrappers cannot be defined for ports with the following

functions: BistOn, BistEn, ScanTest, ShiftEnable, LogicLow, LogicHigh, Open, None.
• EmbeddedTestLogic wrappers cannot be defined for ports when the Direction property
is set to the value InOut.
• If a memory contains embedded scan circuitry, refer for detailed information to
“Integrating Modules With Pre-Existing Scan Chains” in the LV Flow User’s Manual.
• portName in the TestInput and TestOutput properties—is the name of the port. Since
ETAssemble instantiates the memory into a memory BIST collar, portName must match
the actual port name of the memory module:
• [LeftIndex:RightIndex] — identifies the range for bused ports.
• If portName contains a %d character identifier, ETAssemble expands the port based on
the range in the Port wrapper property name or the BusRange property. This enables the
support of both bused and scalar memory ports.
Note
The %d scalar notation is case sensitive. If you use %D, the Port is treated as a bus
with %D as part of the name. This makes it impossible to load the ETAssemble
output into other Siemens EDA tools or any simulator.
Example 1
The following example specifies the test input port TA[7:0] and the test output port TQ[15:0]
with their associated functional ports.
Memory Library File
Function
Port (A[7:0]) {
Function: address;
EmbeddedTestLogic {
TestInput: TA[7:0];
}
}
Port (Q[15:0]) {
Function: Data;
Direction: Output;
EmbeddedTestLogic {
TestOutput: TQ[15:0];
}
}
Example 2
The following example specifies the test input port TA%d[7:0].
Port (A%d[7:0]) {
Function: address;
EmbeddedTestLogic {
TestInput: TA%d[7:0];
}
}
Function
Function can be used as following:
• Wrapper in AddressCounter Wrapper

• Property in Port Wrapper
Wrapper in AddressCounter Wrapper
The required Function wrapper defines how the memory BIST controller drives memory
address ports. Use the Function wrapper to segment the address port into column, row, and
bank addresses as well as to specify the count range of each segment.
Syntax
The first form of syntax for this wrapper is used to specify the segmentation of the address port.
LogicalAddressMap {
.
.
.
}
}
The second form of syntax for this wrapper is used to specify the count range of an address
segment.
Memory Library File
Function
Function (ColumnAddress | RowAddress | BankAddress) {

}
• LogicalAddressMap — maps the column, row, and bank counter output to the address
port.
• CountRange — specifies the count range for the column, row, or bank address
segments.
Default Value
Defaults exist for each of the properties within the Function wrapper. Refer to the sections
describing these properties for details.
Usage Conditions
The Function wrapper is used in the AddressCounter wrapper.
Example
The following example shows an address port segmented into 4 row address bits and 7 column
address bits. The row address range is defined as 0 to 15. The column address range is not
specified and will default to the full binary count of the column address size (0 to 127).
LogicalAddressMap {
ColumnAddress[6:0]: Address[6:0];
RowAddress[3:0]: Address[10:7];
}
}
Function (RowAddress) {
CountRange[0:15];
}
Property in Port Wrapper

The Function property specifies the function of the signal port.
Memory Library File
Function
Syntax
Function: Activate | Address | BisrClock | BisrParallelData | BisrReset |

BisrScanEnable | BisrSerialData | BistEn | BistOn |
CAS | Clock | Data | GroupWriteEnable | LogicHigh | LogicLow |
(None) | Open | OutputEnable | Precharge | RAS | ReadEnable |
Refresh | ScanTest | Select | ShadowAddressEnable | ShiftEnable |
User0 | User1 | User2 | User3 | User4 | User5 | User6 | User7 |
User22 | User23 | ValidData | WriteEnable;
Table 4-1 describes the valid values and identifies the applicable controller type for each
Function value.
Table 4-1. Port Function Values
Function Description
Activate Specifies the activate signal for DRAM. A port of
this function can be controlled by the Activate
property of the Tick wrapper in the operation set.
Address Specifies a memory address port.
BisrClock Specifies the port that controls the clock to the
internal BISR chain registers. This port function is
mandatory for memories with serial BISR interface.
BisrParallelData Specifies the memory ports used for memory repair.
This port function is mandatory for memories with
parallel BISR interface.
BisrReset Specifies the port that controls the internal BISR
register chain asynchronous reset. This port function
is mandatory for memories with serial BISR
interface.
BisrScanEnable Specifies the port that enables the shifting of the
internal BISR chain. This port function is optional
for memories with serial BISR interface.
Memory Library File
Function
Table 4-1. Port Function Values (cont.)

BisrSerialData Specifies the internal BISR chain serial input and
output ports. The BisrSerialData port function is
mandatory for memories with a serial BISR
interface. You must specify the port direction using
the Direction: <Input> | <Output>. In most cases, a
memory with a serial BISR interface must have two
BisrSerialData ports where one port has direction
input and the other port has direction output. The
exception is when a memory has serial repair access
but no shift out port. In this case, you specify only
the BisrSerialData input port.
BistEn Specifies that the port is used to control a clock
multiplexer in the memory. A port of this function is
connected to the BIST_EN signal of the controller.
BistOn Specifies that the port is used to control the signals
(data/address/control but not a clock) selection in the
memory. A port of this function is connected to the
BIST_ON signal of the controller.
CAS Specifies the column access strobe signal for
DRAM. A port of this function can be controlled by
the CAS property of the Tick wrapper in the
operation set.
Clock Specifies a memory clock port.
Data Specifies the data port.
When Data is specified for the Function property,
Direction indicates if Data is an input, output, or
bidirectional port
GroupWriteEnable Specifies a write enable port that controls one or
more bits in the data path. Group write enable ports
must be associated with the data input port being
controlled using the LogicalPort property in their
Port wrappers. For programmable controllers, the
association of group write enable bits to data bits can
be defined with the GroupWriteEnableMap wrapper.
The group write enable ports can be controlled using
the Tick properties: EvenGroupWriteEnable and
OddGroupWriteEnable in the operation set.
LogicHigh Specifies that the associated port is to be tied to a
logic high value.
Memory Library File
Function

LogicLow Specifies that the associated port is to be tied to a
logic low value.
None Specifies a port that does not need to be controlled
during memory BIST. The functional connection to
this port will be preserved. Use SafeValue to control
the memory port value during the memory assembly
simulation. A UserDefinedSequence is required to
set the value when memory BIST is inserted into the
design.
ETAssemble will not intercept the memory port.
Open Specifies an unused output port of the memory that
will be left unconnected. The associated port must be
defined with Direction Output.
OutputEnable Specifies the memory tri-state output enable that
drives the data to the memory BIST collar or
interface.
A port of this function can be controlled by the
OutputEnable property of the Tick wrapper in the
operation set.
Precharge Specifies a port that controls the precharge circuitry
in DRAM. A port of this function can be controlled
by the Precharge property of the Tick wrapper in the
operation set.
RAS Specifies the row access strobe signal for DRAM. A
port of this function can be controlled by the RAS
ReadEnable Specifies a memory read enable signal. A port of this
function can be controlled by the ReadEnable
Refresh Specifies a port that controls the refresh circuitry in
DRAM. A port of this function can be controlled by
the Refresh property of the Tick wrapper in the
operation set.
ScanTest Specifies the port that configures the embedded test
logic to enable scan testing. Typically, the port
disables the memory’s tri-state outputs or enables the
memory bypass mode. A port of this function is
connected to the LV_TM signal of the controller.
Memory Library File
Function

Select Specifies a memory (chip) select signal.
A port of this function can be controlled by the Select
ShadowAddressEnab Specifies that the port is used to enable the
le ShadowWriteAddress on the memory. This property
is valid only for memories that support the
ShadowWrite operation. A memory with a port of
this function can have ShadowWrite: On, and the
number of rows in the memory equal to a power of
two. Asserting this port on the memory enables you
to perform a write operation without corrupting the
memory array content.
User0 - User23 Allow user-defined waveform to be applied to the
associated memory port. These port functions can be
assigned to any input port and can be controlled by
the Tick property User<n> in the operation set.
ValidData Specifies an output signal from the user logic which
is asserted when valid data is available on the read
data bus.
WriteEnable Specifies a memory write enable signal. A port of
this function can be controlled by the WriteEnable
For details on the Function values specific to the Programmable controllers, refer to the
contents of the Tick wrapper in Reference for OperationSet Wrapper Contents in the Tessent
Default Value
The default value is None.
Usage Conditions
The Function property is used in the Port wrapper.
• Selection guidelines for Function values are as follows:

If a port needs to have a different logic value in functional and Memory BIST mode,
then a port function other than LogicHigh or LogicLow must be used. When LogicHigh
or LogicLow is specified, no mux is inserted so the port logic levels are the same in both
modes.
Memory Library File
Fuse
Most values of port Function will cause a multiplexer to be inserted to select between
the functional and test inputs. The following value selections assume a dedicated test
port and no multiplexer is inserted: BistEn, BistOn, ScanTest, ShadowAddressEnable,
BisrParallelData, BisrSerialData, BisrClock, BisrReset and BisrScanEnable.
When port Function value of None is specified, no mux is inserted and the user must
specify a SafeValue, which is used to control the memory port value during the memory
assembly simulation. A UserDefinedSequence is required to set the value when memory
BIST is inserted into the design.
Table 4-2 provides additional Function value selection details and guidelines for
various port operations in functional and memory BIST modes.
Table 4-2. Port Function Value Guidelines
Port Operation Value Selection
tied high or low in functional and memory LogicHigh or LogicLow
BIST mode
Port is driven in functional mode but needs One of User0 to User23 values, with the
to be static in memory BIST mode appropriate logic level specified with the
Polarity property in the UserSignal wrapper.
For example, ActiveHigh (default) if the port
should be driven to logic 0 during memory
BIST, and ActiveLow for a logic 1 level.
Port needs to toggle in memory BIST mode Any port Function controlled from the
OperationSet wrapper, including User0-23.
Port is driven in functional mode, but cannot None; set SafeValue to the appropriate level
be gated. applied by the user circuit. A
UserDefinedSequence is required to set the
value when memory BIST is inserted into
the design.
Example
The following example identifies the given port as a WriteEnable.
Function: WriteEnable;
Fuse
The sections below provide detailed information on the following usage of the Fuse property:
• ColumnSegment: FuseSet Usage

• RowSegment: FuseSet Usage
• PinMap: SpareElement Usage
Memory Library File
Fuse
ColumnSegment: FuseSet Usage

The Fuse property enables you to map the fuse register bit to an address port on the memory.
The fuse register bit logs the value of this address port for the defective IO/Column.
Syntax
Fuse [<bitIndex>]: AddressPort (<name>) | not AddressPort (<name>) |

• <bitIndex> — represents the fuse bit number. This number must start from zero and
incrementally count by one up to n-1 where n is the number of Fuse properties specified.
• AddressPort <name> — represents the address port value that will be logged when a
failure is detected.
• not AddressPort <name> — represents the inverted address port value that will be
logged when a failure is detected.
• LogicHigh — specifies that a logic high value will be logged when a failure is detected.
• LogicLow — specifies that a logic low value will be logged when a failure is detected.
Default Value
None
Usage Conditions
The Fuse property is used in the wrapper of the ColumnSegment wrapper.
• AddressPort <name> must identify a port defined in the memory library file with
Function:Address.
• AddressPort <name> must either be a scalar port or a single bit of a bussed port.
Note
There can be multiple fuse register bits. However, they must be starting from 0.
Example 1
The following syntax specifies a column segment that logs a constant LogicHigh value and 4
address bits to identify the defective IO/Column.
Memory Library File
Fuse
ShiftedIORange: Data[15:0];
FuseSet {
Fuse[4]: LogicHigh;
Fuse[3]: AddressPort(AD[9]);
}
}
Each spare element has a fuse register that logs the specified address bits as defined by the
FuseSet wrapper. The fuse register bits are as follows:
• Fuse[4] — logs a constant LogicHigh value.

• Fuse[3] — logs the address driven on the port AD[9] for the defective element.
Example 2
The following syntax specifies a column segment that logs a constant LogicHigh value and 4
address bits whose values are inverted to identify the defective IO/Column.
ShiftedIORange: Data[15:0];
FuseSet {
Fuse[4]: LogicHigh;
Fuse[3]: not AddressPort(AD[9]);
}
}
• Fuse[4] — logs a constant LogicHigh value.

• Fuse[3] — logs the inverse of the address driven on the port AD[9] for the defective
element.
element.
element.
Memory Library File
Fuse
element.
RowSegment: FuseSet Usage
The Fuse property enables you to map the fuse register bit to an address port on the memory.
The fuse register bit logs the value of this address port for the defective row.
Syntax

incrementally count by one up to n-1 where n is the number of Fuse bits specified.
• AddressPort <name> — represents the address port value that will be logged when a
failure is detected.
• not AddressPort <name> — represents the inverted address port value that will be
logged when a failure is detected.
• LogicHigh — specifies that a logic high value will be logged when a failure is detected.
• LogicLow — specifies that a logic low value will be logged when a failure is detected.
Default Value
None
Usage Conditions
The Fuse property is used in the RowSegment:FuseSet wrapper.
• A minimum of one Fuse must be defined per FuseSet wrapper.

• name must identify a port defined in the memory library file with Function:Address.
• AddressPort <name> must either be a scalar port or a single bit of a bused port.
Memory Library File
Fuse
Example 1
The following example specifies a row segment that logs a constant LogicLow followed by 4
address bits to identify the defective row:
RowSegment(Bank0) {
NumberOfSpareElements: 2;
FuseSet {
Fuse[4]: LogicLow; Fuse[3]: AddressPort(AD[9]);
}
}
• Fuse[4] — logs a constant LogicLow value.

Example 2
The following example specifies a row segment that logs a constant LogicLow followed by 4
address bits whose values are inverted to identify the defective row:
RowSegment(Bank0) {
FuseSet {
Fuse[4]: LogicLow; Fuse[3]: not AddressPort(AD[9]);
}
}
• Fuse[4] — logs a constant LogicLow value.

element.
Memory Library File
Fuse
element.
element.
element.
PinMap: SpareElement Usage
The Fuse property allows you to specify the port of the memory that controls the address of a
spare row or column element. You can use this property multiple times. This property maps
each bit in FuseSet:Fuse to the corresponding repair ports on the memory. Each
PinMap:Fuse[<bitIndex>] index must match a FuseSet:Fuse [<bitIndex>] index.
Syntax
Fuse[<bitIndex>]: <repairPortName> |
RepairRegister <bitIndex>;
• repairPortName — represents the address port value that will be logged when a failure is
detected.
• RepairRegister [<bitIndex>] — allows you to describe the order of the internal BISR
chain register for the serial BISR interface.
Default Value
None
Usage Conditions
The Fuse property is used inside the PinMap:SpareElement wrapper of the RowSegment or
ColumnSegment wrapper.
• Each FuseSet:Fuse property must have a corresponding PinMap:SpareElement: Fuse

property.
• name must be either a scalar port or a single bit of a vectored port.
• repairPortName specified must be a port defined in the memory library file with the
specified name which has one of BISR Functions.
Memory Library File
FuseMap
Example
The following example shows spare elements for implementing built-in self-repair feature.
PinMap {
SpareElement {
RepairEnable: B0_REN0;
Fuse[0]: B0_RR0[0];
Fuse[1]: B0_RR0[1];
Fuse[2]: B0_RR0[2];
Fuse[3]: B0_RR0[3];
}
SpareElement {
Fuse[0]: B0_RR1[0];
Fuse[1]: B0_RR1[1];
Fuse[2]: B0_RR1[2];
Fuse[3]: B0_RR1[3];
}
}
FuseMap
The following sections describe in detail FuseMap used as following:
• Wrapper
• Property
Wrapper
The FuseMap wrapper enables you to define the HighBitRange and the LowBitRange for the
fuse register. This wrapper is used to map IO ports to the fuse register.
Syntax
ShiftedIO(<DataPortName>): <bitString>;
.
.
}
Default
None
Usage Conditions
The FuseMap wrapper is used in the ColumnSegment: FuseSet wrapper.
Memory Library File
FuseMap
Example
This example specifies the binary codes that will be logged to identify each failing data IO port.
FuseMap[3:0] {
ShiftedIO(Data[0]): 4'b0000;
}
Property
The FuseMap property allows you to specify the memory port that controls the port of a spare
IO element or describe the order of the internal BISR chain register for the serial BISR
interface. This property can only be specified inside the ColumnSegment wrapper. This
property must be repeated for each FuseMap bit. This property maps the shifted IO fuse map
bits to the corresponding repair ports on the memory. Each
PinMap:SpareElement:FuseMap[<x>] index must be within the FuseSet:FuseMap[x:y] index
range.
Syntax
FuseMap [bitIndex]: <repairPortName> | RepairRegister[bitIndex];
• bitIndex — represents the fuse bit number. This number must start from zero and
• repairPortName — represents the address port value that will be logged when a failure is
detected.
• RepairRegister [<bitIndex>] — allows you to describe the order of the internal BISR
chain register for the serial BISR interface.
The total BISR chain length (N) for a given memory is equal to the number of the
RepairRegister[bitIndex] properties specified in the ColumnSegment wrappers
combined inside a memory library file. The RepairRegister[0] specifies the BISR chain
register that is closest to the BISR scanOut port, and the RepairRegister[N-1] specifies
the BISR chain register that is closest to the BISR scanIn port.
A single BISR chain register is generated for each memory library file. The
RepairRegister indexes must be contiguous from 0 to N-1 within a memory library file.
All indexes between 0 and N-1 must be used, and each index can only be used once.
Memory Library File
FuseSet
You must take care to describe the RepairRegister indexes to match the internal
memory BISR chain order specified in the memory data sheet. Any mismatch between
the external and internal BISR chains ordering will result in the incorrect repair data
scanned inside the memory.
Default Value
None
Usage Conditions
The FuseMap property is used in the PinMap: SpareElement wrapper only inside the
• Each FuseSet: Fuse property must have a corresponding PinMap: SpareElement: Fuse
property.
• name must be either a scalar port or a single bit of a vectored port.
Example
PinMap {
SpareElement {
Fuse[0]: B0_RR0[0];
Fuse[1]: B0_RR0[1];
Fuse[2]: B0_RR0[2];
Fuse[3]: B0_RR0[3];
}
SpareElement {
Fuse[0]: B0_RR1[0];
Fuse[1]: B0_RR1[1];
Fuse[2]: B0_RR1[2];
Fuse[3]: B0_RR1[3];
}
}
FuseSet
The sections below provide detailed information on the following usage of the FuseSet
wrapper:
Memory Library File
FuseSet
ColumnSegment Usage
The FuseSet wrapper contains two possible definitions of the fuse register bits:
• The first definition is used to map fuse register bits to address ports on the memory. In
this case, the fuse register bit logs the value of this address port for the defective IO
element. The mapping information is passed through the Fuse property.
• The second definition is used for IO shifting and enables you to define fuse register
values for identifying defective IO/columns. The defined fuse value is loaded into the
fuse register for a defective IO. The mapping information for the shifted IO is passed to
the tool through the FuseMap wrapper.
Syntax
FuseSet {
.
.
ShiftedIO (<DataPortName>): <bitString>;
.
.
}
}
Default Value
None
Usage Conditions
The FuseSet wrapper is used in the ColumnSegment wrapper and is specified only once per
Example
This example specifies the binary codes that will be logged to identify each failing data IO port.
Memory Library File
FuseSet
FuseSet {
FuseMap[3:0] {
}
}
RowSegment Usage
The FuseSet wrapper contains properties that define which address bits are required for the
fuses to replace a defective element with a spare element. These fuse bits are defined per row
segment.
Syntax
FuseSet {
Fuse[bitIndex]: AddressPort (<name>) | not AddressPort (<name>) |
.
. Repeat for all Fuse bits
.
}
Default Value
None
Usage Conditions
The FuseSet wrapper is used in the RowSegment wrapper and is specified only once per
RowSegment wrapper.
Example
The following example specifies two segments that consist of two spare elements each.
Memory Library File
GroupWriteEnableMap
RowSegment (Bank0){
RowSegmentCountRange [1'b0:1'b0];
FuseSet {
}
}
RowSegment (Bank1){
FuseSet {
}
}
• Fuse[3] — logs the address driven on the port AD[9] for the defective element
GroupWriteEnableMap
The GroupWriteEnableMap wrapper is an optional wrapper that describes the mapping of a
memory’s group write enable (GWE) bit to the one or more data bits that it controls.
If this wrapper is not specified, a uniform distribution of the GWE bits to memory data bits is
assumed and all memory bits must be controlled by a GWE bit. This wrapper is only allowed if
the memory has at least one Port wrapper with the Function GroupWriteEnable present in the
library.
If the ports with Function GroupWriteEnable also feature EmbeddedTestLogic inputs, the
number of GroupWriteEnable properties must match the size of the test GWE port. Otherwise,
the number of GroupWriteEnable properties must match the size of the functional GWE port.
Syntax
GroupWriteEnable[gwe_bit] : d[bit_or_range], ... ; // repeatable
}
Memory Library File
GroupWriteEnableMap
Where valid values are as follows:
• GroupWriteEnable[gwe_bit] — Specifies which group write enable bit, identified by

the index gwe_bit, is to be mapped.
• d[bit_or_range] — Specifies which memory data input bit or range of bits are to be
controlled by the GWE bit specified by gwe_bit.
Default Value
None
Usage Conditions
The GroupWriteEnableMap wrapper is used in the MemoryTemplate wrapper.
• GroupWriteEnableMap is supported in programmable controllers only.

• The gwe_bit indices for GroupWriteEnable must count from 0 to the size of the test
input or functional GWE port, minus 1.
• The data bit_or_range indices must be within the range of the functional memory data
input ports, regardless of whether the data port has EmbeddedTestLogic or not. The bit
range of vector Data Input ports must always start with “0”. The data bit indices cannot
be duplicated within the GroupWriteEnableMap wrapper, however not all indices need
to be used. If all indices are not used, a warning will be issued.
Examples
This example shows a mapping of a 4 bit GWE port that covers 9 of 10 bits of memory data
input ports:
GroupWriteEnable[3] : d[9];
GroupWriteEnable[2] : d[8:6];
GroupWriteEnable[1] : d[4];
GroupWriteEnable[0] : d[3:0];
Given this mapping, data input bits 0-3 and 6-8 will be controlled by GWE bits 0 and 2 with the
EvenGroupWriteEnable property and data input bits 4 and 9 will be controlled by GWE bits 1
and 3 with the OddGroupWriteEnable property. Note that data input bit 5 will not be controlled
by any GWE bit.
Memory Library File
InternalScanLogic
InternalScanLogic
The InternalScanLogic property specifies the memory module contains scan circuitry that is to
be reused during scan test modes.
The supported internal scan logic is the bypass logic between the data input and the data outputs
of the memory. If the bypass logic includes flip-flops on the data input side, then the flip-flops
must be stitched into a scan chain. For more information, refer to “Integrating Modules With
Pre-Existing Scan Chains” in the LV Flow User’s Manual.
When InternalScanLogic is set to On, ETAssemble will not generate a scan model for the
associated memory module. The memory scan model must be provided to properly describe the
internal scan logic to both ETChecker and ruleAnalyze. Refer to “Integrating Modules With
Pre-Existing Scan Chains” in the LV Flow User’s Manual for methods to share the same model
for both simulation and Siemens EDA’s LV ETAnalysis tools.
Syntax
InternalScanLogic: On | (Off);
Default Value
The default is Off.
Usage Conditions
The InternalScanLogic property is used in the MemoryTemplate wrapper.
• You must set TransparentMode to None when InternalScanLogic is On.

• Specify ObservationLogic to Off if the internal scan logic includes flip-flops that
observes the address and control inputs, and those flip-flops are part of the internal scan
chain of the memory.
Example
In the example below, the memory is declared as having internal scan logic, which provides the
data input to data output bypass logic. The memory collar will not implement any external
bypass path but will insert flip-flops to observe the address and control signals driven to the
memory.
InternalScanLogic: On;
TransparentMode: None;
ObservationLogic: On;
Memory Library File
LogicalAddressMap
LogicalAddressMap
The LogicalAddressMap wrapper maps the column, row, and bank address function bits to the
logical address bits.
Syntax
LogicalAddressMap {
ColumnAddress[LeftIndex:RightIndex]:
Address[LeftIndex:RightIndex];
.
.
RowAddress[LeftIndex:RightIndex]:
.
.
BankAddress[LeftIndex:RightIndex]:
.
.
}
• ColumnAddress[] — maps part or all of the column address function counter bits to the
• RowAddress[] — maps part or all of the row address function counter bits to the logical
address bits.
• BankAddress[] — maps part or all of the bank address function counter bits to the
• Address[] — specifies the logical address bit range to which the column, row, or bank
address bits map.
Usage Conditions
The LogicalAddressMap wrapper is used in the Function wrapper.
• BankAddress[x] is supported by Programmable controllers only.
Note
Asymmetric memory banks may exist with different numbers of rows per bank. For more
information about asymmetric banks, refer to the NumberOfWords and CountRange
properties.
Memory Library File
LogicalAddressMap
• The values for ColumnAddress[x], RowAddress[x], and BankAddress[x] together must

use the entire range specified for the address port (Port: Function Address).
• Each bit in Address[x] must map to either a column, row, or bank address counter bit or
be multiplexed to row and column address bits. Multiplexing of bank address bits is not
supported.
• If a multiplexed row address segment and column address segment feature different
sizes, you can define padding bit values for the shorter address segment with the
AddressPadding property.
• If at least one address bit position is multiplexed, either all row address bits or all
column address bits must be multiplexed as well.
• Address multiplexing is supported only for single-port (1RW) memories.
Examples
Example 1
The following example shows a mapping for a 15-bit address bus with a contiguous 8-bit row
address segment:
LogicalAddressMap {
RowAddress[7:0] : Address[7:0];
ColumnAddress[6:0] : Address[14:8];
}
}
Example 2
The following example shows a mapping for a 15-bit address bus with a non-contiguous 8-bit
row address segment, which is composed of address bit 14, and from address bits 6 to 0:
LogicalAddressMap {
}
}
Memory Library File
LogicalPort
Example 3
The following example shows a mapping for a 15-bit address bus with a 4-bit column address
segment, an 8-bit row address segment, and a 3-bit bank address segment:
LogicalAddressMap {
BankAddress[2:0] : Address[14:12];
}
}
Example 4
The following example shows a mapping of a 3-bit bank address segment and multiplexing of a
5-bit (non-contiguous) column address bus with a 11-bit (non-contiguous) row address bus:
LogicalAddressMap {
BankAddress[2:0] : Address[6:4];
}
}
LogicalPort
The LogicalPort property groups address, data, and control signals for memory BIST. Memory
BIST requires a read port and a write port to execute the test. The read port and the write port
can be either separate ports or shared ports.
Syntax
where logicalPortID can be any identifier. Typically logicalPortID is A, B, C, and so on.
Default Value
When LogicalPort is omitted from a Port wrapper, ETAssemble treats the port as a global port
and includes the port in all logical ports.
Usage Conditions
The LogicalPort property is used in the Port wrapper.
You can specify only one clock, one set of addresses, and one set of data terminals per logical
port.
Memory Library File
LogicalPorts
Example
Port (D1[7:0]) {
Function: Data;
LogicalPort: A;
}
Port (D2[7:0]) {
Function: Data;
LogicalPort: B;
}
Port (Clock) {
Function: Clock; //This port belongs to both logical port A and B.
}
LogicalPorts
The LogicalPorts property identifies the configuration of read, write, and read/write logical
ports for a memory. Logical ports require a unique address bus for reading, writing, or both.
Syntax
• xR — identifies the number of Read logical ports.

• yW — identifies the number of Write logical ports.
• zRW — identifies the number of ReadWrite logical ports.
You must specify Read logical ports, Write logical ports, and ReadWrite logical ports in the
order shown.
Default Value
The default value for this property depends on the MemoryType property, as follows:
• If MemoryType: SRAM, this property defaults to 1RW.

• If MemoryType: ROM, this property defaults to 1R.
Usage Conditions
The LogicalPorts property is used in the MemoryTemplate wrapper.
• If MemoryType: ROM, you cannot specify W or RW.

• If MemoryType: SRAM, you must specify at least one R and one W or one RW.
Memory Library File
LogicLow
Example
A LogicalPorts entry for a dual port memory with a single address bus for read and write access
of each port would be as follows:
LogicalPorts: 2RW;
LogicLow
The LogicLow property is used to instantiate a BISR register that is not associated to any BIRA
register. This instantiates a BISR register that captures a constant logic low value during a
BIRA to BISR transfer.
Syntax
• pinName — identifies the parallel BISR interface memory repair port to which the
current BISR register is connected to.
• RepairRegister[x] — identifies the index of the BISR register in the chain for a memory
with serial BISR interface.
Default Value
There is no default value for this property.
Usage Conditions
The LogicLow property is used in the PinMap: SpareElement wrapper.
• pinName is used for memories with Parallel BISR interface.

• RepairRegister[x] is used for memories with Serial BISR interface.
Example
This example specifies that the third bit of the BISR chain is capturing a constant logic low
value during a BIRA to BISR transfer. This register is connected to the SRowAddress[2] port of
the memory with parallel BISR interface.
Memory Library File
MemoryHoldWithInactiveSelect
PinMap{
SpareElement{
LogicLow: SRowAddress[2];
Fuse[2]: SRowAddress[1];
Fuse[1]: SRowAddress[0];
RepairEnable: SRowEn; }
}
MemoryHoldWithInactiveSelect
The MemoryHoldWithInactiveSelect property describes the memory behavior when the select
control signal is inactive.
Syntax
MemoryHoldWithInactiveSelect: (On) | Off;
• On — holds the memory contents when the select control signal is inactive for a write
operation and holds the memory output when the select control signal is inactive for a
read operation.
• Off — may not hold the memory contents when the select control signal is inactive for a
write operation nor hold the memory output when the select control signal is inactive for
a read operation.
Default Value
The default is On.
Usage Conditions
The MemoryHoldWithInactiveSelect property is used in the MemoryTemplate wrapper.
• If the memory contents or output does not hold when the select control signal is inactive
and you want to test the memory with the SMarchCHKBvcd algorithm, you must set
MemoryHoldWithInactiveSelect to Off.
Example
The following example shows that the memory under test may not hold when the select control
signal is inactive:
MemoryHoldWithInactiveSelect: Off;
Memory Library File
MemoryType
MemoryType
The MemoryType property describes the type of memory.
Syntax
MemoryType: ROM | (SRAM)| DRAM;
• ROM — specifies a read-only memory.

• SRAM — specifies a static random access memory.
• DRAM — specifies a dynamic random access memory.
Default Value
The default value is SRAM.
Usage Conditions
The MemoryType property is used in the MemoryTemplate wrapper.
Example
This example specifies that the memory under test is a SRAM.
MemoryType: SRAM;
MilliWattsPerMegaHertz
The MilliWattsPerMegaHertz property defines the amount of power consumed by the
memory in relation to the operational frequency. The value specified by this property represents
the average between the read and write power consumption. The memory BIST performs
approximately equal number of read and write operations.
Typically, this property is provided by the memory supplier in the data sheet to enable users to
manage the power distribution and consumption of the chip.
Syntax
where <real> is greater than 0.
Memory Library File
MinHold
Default Value
The default value is estimated as follows:
• b * (0.004 + (c * 0.00008))
where
• b — number of bits per word.

• c — number of columns, or column mux option.
Usage Conditions
This property is used in the MemoryTemplate wrapper.
Example
This example specifies that the memory consumes 0.5mW of power during 1.0 MHz of
operating frequency:
MilliWattsPerMegaHertz: 0.5;
MinHold
The MinHold property provides delay on all address, data, and control input signals from the
memory BIST controller with respect to the memory clock during RTL simulation. Specify
MinHold when the minimum hold requirements of the memory models are greater than zero.
Syntax
MinHold: holdTime;
where holdTime can be either an integer or a real number with up to two digits of accuracy
following the decimal point.
Default Value
The default value is 0 nanoseconds.
A value of zero does not affect the simulation.
Usage Conditions
The MinHold property is used in the MemoryTemplate wrapper.
If you use the MinHold property for a memory, keep in mind that delay is being added in the
RTL code that does not translate through synthesis. The delays added in the RTL code to meet a
hold-time requirement are ignored by Synopsys, and the inherent gate and wire delay in the
Memory Library File
NotAllocated
circuit may or may not be sufficient to meet the hold-time requirement on the memory. The
specified value must be greater than or equal to zero and less than the specified clock period.
The time unit for MinHold is nanoseconds.
Example
This example specifies the memory hold time is 5ns:
MinHold: 5;
In the memory collar module, #50.0 will added to all assign statements that define signals
propagating to the memory inputs:
assign #50.0 BIST_ON = BIST_EN_R;
NotAllocated
The NotAllocated property specifies the fuse register decode value to indicate the spare element
in the column segment is not used. If this property is not present, a one bit register called the
Allocation Bit will be added as the MSB of the fuse register.
Syntax
Default Value
None
Usage Conditions
The NotAllocated property is used in the ColumnSegment: FuseSet: FuseMap wrapper.
• This property must be specified for all or none of ColumnSegment.

• If this property is defined, the specified value must be all zeroes.
• If this property is defined, the same value must be specified for all ColumnSegments.
• If this property is defined, the specified value cannot be repeated as a ShiftedIO value
within the same FuseMap wrapper.
Example
This example shows that the spare element is unused if the fuse register contains the binary
value 0000.
NotAllocated: 4'b0000;
Memory Library File
NumberOfBits
NumberOfBits
The NumberOfBits property specifies the number of bits per word in the memory.
Syntax
NumberOfBits: x;
where x is an integer, 1 or greater, that specifies the number of bits per word.
Default Value
If the NumberOfBits property is not specified, the default value is the output data width of the
first logical port in the MemoryTemplate wrapper.
Usage Conditions
The NumberOfBits property is used in the MemoryTemplate wrapper.
Example
For a 32X8 memory (depth of 32 words and width of 8 bits), the entry for NumberOfBits
would be as follows:
NumberOfBits: 8;
NumberOfSpareElements
The NumberOfSpareElements property enables you to define the number of spare blocks,
banks, rows, or columns within the RowSegment or ColumnSegment.
Syntax
where integer is a valid integer defining the number of spare elements within the memory
segment.
Default Value
Usage Conditions
The NumberOfSpareElements property is used in the RowSegment and ColumnSegment
wrappers.
Memory Library File
NumberOfWords
Example
The following example specifies there are 2 spare elements in the row segment Bank0.
RowSegment (Bank0){ NumberOfSpareElements: 2;

.
.
.
}
NumberOfWords
The NumberOfWords property specifies the number of words in the memory.
Syntax
NumberOfWords: x;
where x is an integer greater than 1 that specifies the number of words in the memory.
Default Value
The NumberOfWords property defaults to the product of the number of columns, rows, and
banks defined in the AddressCounter wrapper. If a CountRange is specified for a particular
address segment, that CountRange is used in the formula. If no CountRange is specified, the
address segment size is assumed to be 2n, where n is the number of bits in that address segment.
Note
Siemens EDA recommends specifying the NumberOfWords property for non-segmented
addresses and for memories in which the actual number of words is not a power of 2. Not
specifying NumberOfWords might cause the simulation to fail. For example, if you do not
specify NumberOfWords for a memory with 12 words and four address bits, the address
counter counts to 16 although there are only 12 words.
Usage Conditions
The NumberOfWords property is used in the MemoryTemplate wrapper.
The Programmable memory BIST controller supports testing of memories with asymmetric
banks containing a different number of rows per bank. In this case, you must specify a
CountRange for each existing memory address segment in the memory library file. Also, you
must specify the NumberOfWords property indicating the valid memory address range is 0 to
NumberOfWords -1.
Memory Library File
ObservationLogic
Examples
Example 1
For a 32X8 memory (depth of 32 words and width of 8 bits), the entry for NumberOfWords is
as follows:
NumberOfWords: 32;
Example 2
In the following example, the CountRange properties show that the memory has 17 rows and 4
banks with a NumberOfWords value of 66. The memory has asymmetric banks (Bank0 has 17
rows, Bank1 has 17 rows, Bank2 has 16 rows, and Bank3 has 16 rows). As required for
asymmetric banks, the address count range specified with the properties within the
AddressCounter wrapper is contiguous.
NumberOfWords: 66;
AddressCounter {
LogicalAddressMap {
BankAddress[1:0]: Address[1:0];
}
}
Function (RowAddress) {
CountRange [0:16];
}
Function (BankAddress) {
CountRange [0:3];
}
}
ObservationLogic
The ObservationLogic property specifies whether or not ETAssemble adds scan observation
points for address and control signals in the memory collar.
Syntax
• On — adds sample points by means of XOR gates and flip-flops to the address and
control signals of the memory within the collar. ETAssemble either uses existing flip-
flops within the collar for these sample points or adds additional flip-flops with the XOR
gates if necessary.
• Off — omits sample points from the collar.
Memory Library File
OperationSet
Default Value
The default is On.
Usage Conditions
This property is used in the MemoryTemplate wrapper of the memory library file.
• The value of the ObservationLogic property in the .etplan File will override the value of
this property in the memory library file.
• Use the ETPlanner property ObservationXORSize to specify the number of signals per
observation point.
OperationSet
OperationSet can be used as follows:
• As a property in the MemoryTemplate wrapper.

• As a wrapper in the memory library file. The OperationSet wrapper defines the set of
operations associated with a memory template. For complete details about the
OperationSet wrapper, including syntax, description, and examples, see “Reference for
OperationSet Wrapper Contents” in the Tessent MemoryBIST User’s and Reference
Manual.
Property in MemoryTemplate Wrapper
The OperationSet property specifies the name of the operation set that the memory BIST
controller uses to generate waveforms that drive the memory.
Note
Siemens EDA provides a variety of built-in operation sets: two for asynchronous memories
without clocks, two for asynchronous memories with at least one clock, one for read-only
memories, and three for synchronous memories. These operation sets are not optimized. You
can optionally create optimized operation sets for the memories in your design.
Programmable controllers support more types of control functions. For details, refer to the
section OperationSet in the Tessent MemoryBIST User’s and Reference Manual.
Syntax
OperationSet: Async | AsyncWR | ROM | (Sync) | SyncWR | SyncWRvcd |

<operationSetName>;
Memory Library File
OperationSet
• Async— is a reserved string that specifies the built-in asynchronous operation set. This
property applies to a memory for which the contents of a new location within its array
are put at the outputs after an address change (a clock is not used in the read operation).
• AsyncWR — is a reserved string that specifies a built-in asynchronous operation set for
a multi-port memory.
• ROM — is a reserved string that specifies the built-in operation set for ROMs.
• Sync — is a reserved string that specifies the built-in synchronous operation set. This
property applies to a memory for which the contents of a new location within its array
are displayed at the outputs after an address change and a clock.
• SyncWR — is a reserved string that specifies a built-in synchronous operation set for a
multi-port memory.
• SyncWRvcd — is a reserved string that specifies a built-in synchronous operation set for
a multi-port memory. This property applies to a memory tested by the
SMarchCHKBvcd algorithm using the Programmable controller.
• operationSetName — is a user-defined identifier that matches the name of an operation
set defined by the OperationSet wrapper. If you specify a user-defined name for the
OperationSet property, ETAssemble searches the specified memory library files for an
OperationSet wrapper with the same identifier.
Note
If ETAssemble finds two OperationSet wrappers with the same name and with braces {},
empty or not, ETAssemble generates an error.
Siemens EDA recommends using the built-in operation sets as templates to create your own
operation sets. The built-in operation sets are generic and are not optimized for one type of
memory. Using the built-in operation sets results in longer test times than if you use optimized
operation sets.
Default Value
The default value is Sync.
Usage Conditions
The OperationSet property is used in the MemoryTemplate wrapper.
• The operation set that you specify must define the operations that are required by the
algorithm testing this memory.
Memory Library File
PhysicalAddressMap
• The OperationSet property in ETPlanner overrides the value of the OperationSet

property in the memory library file.
Example
This example specifies that the memory BIST controller is to use the operations defined in the
built-in Sync operation set when testing the memory.
OperationSet: Sync;
PhysicalAddressMap
The PhysicalAddressMap wrapper enables ETAssemble to construct a physical checkerboard
pattern in the memory. The left column of the PhysicalAddressMap wrapper identifies the
memory pins. The right column of the wrapper shows how the address counter bits drive the
memory pins.
Syntax
ColumnAddress[x]: <expression>;
.
.
RowAddress[x]: <expression>;
.
.
BankAddress[x]: <expression>;
.
.
} //end of PhysicalAddressMap wrapper
• ColumnAddress[x], RowAddress[x], BankAddress[x] — identify the signals that are

mapped to the memory address port as described by the LogicalAddressMap wrapper in
the AddressCounter wrapper. The index x must match the LogicalAddressMap wrapper
index values.
• <expression> — represents a Boolean expression composed of Boolean operators,
address counter bits, and optional parentheses.
• Table 4-3 shows the valid operators and their precedence from highest to lowest.
Operators on the same level are evaluated from left to right.
Table 4-3. Operator Precedence

Operator Precedence
not Highest
Memory Library File
PhysicalAddressMap
Table 4-3. Operator Precedence (cont.)

Operator Precedence
and, nand
xor, xnor
or, nor Lowest
• The operands represent the counter bits used to generate the column, row, or bank
addresses. Valid address counter symbols are as follows, where the integer x is a valid
bit index of the address segment as defined in the AddressCounter wrapper:
o c[x] — column address
o r[x] — row address
o b[x] — bank address
The address counter bits r[x], c[x], or b[x] can be specified in any of the
ColumnAddress, RowAddress, or BankAddress equations.
• Optional parentheses define the operator precedence. Inserting parentheses is strongly
recommended to avoid ambiguity in interpreting precedence and to improve readability.
The following are examples of supported mapping equations:
RowAddress[0]: c[0];
RowAddress[0]: not c[0] xor c[1] xor c[2];
RowAddress[0]: (c[0] and not c[1]) or c[2];
RowAddress[0]: not (r[11] and ((r[11] nor r[12]) nand not r[10]));
Default Value
If your memory library file(s) do not include a PhysicalAddressMap wrapper, ETAssemble
assumes a one-to-one mapping. For example, RowAddress[x]: r[x], ColumnAddress[x]: c[x],
and BankAddress[x]: b[x].
In addition, if the number of equations is fewer than the number of address ports or if the
mapping contains gaps, ETAssemble assumes a one-to-one mapping for the missing addresses.
For example:
ColumnAddress[0]: c[0] xor c[1];
ColumnAddress[1]: c[1];
ETAssemble automatically fills in the missing address as follows:
Memory Library File
PhysicalAddressMap
Usage Conditions
The PhysicalAddressMap wrapper is used in the MemoryTemplate wrapper.
• When specifying the PhysicalAddressMap wrapper, ColumnAddress[x],

RowAddress[x], and BankAddress[x] must be uniquely specified. For example, the
following is not allowed:
}
• ETAssemble will issue an error indicating ColumnAddress[1] is repeated.

• The same counter bit c[x], r[x], or b[x] may be specified in one or more equations.
Omitting a counter bit from the PhysicalAddressMap wrapper is permitted. For
example:
RowAddress[0]: r[0] xor r[1];
RowAddress[1]: r[1];
}
• ETAssemble will issue a warning indicating counter bit r[2] is not used in any equation.
Example 1
The following example shows a typical PhysicalAddressMap wrapper.
}
Memory Library File
PhysicalDataMap
Example 2
The following example shows the scrambling definition for a bussed address port. The port
width is 4 bits; bit 0 represents the column address, and bits 1 to 3 represent the row address.
MemoryTemplate (RAM) {
Port (A[3:0]) {
Function: Address;
Direction: Input;
}
...
AddressCounter {
LogicalAddressMap {
ColumnAddress[0:0]: Address[0:0];
}
}
}
ColumnAddress[0]: r[0] xor (c[0] or r[1]);
RowAddress[2]: not (r[2] and not c[0]);
}
}
PhysicalDataMap
The PhysicalDataMap wrapper describes the mapping between the data input ports of the
memory and the internal data lines. Because physical memory cells are arranged in a particular
order to facilitate layout, you must provide this information so that ETAssemble can correctly
generate the checkerboard patterns.
Syntax
PhysicalDataMap {
Data[x]: [not] d[index] [xor
<expression>]...; .
.
.
}
• Data[x] represents the physical data port of the memory.

• d[y] identifies the physical data bit controlled by the memory BIST controller.
• <expression> is <counterBit> | ([not] <counterBit> and [not] <counterBit>)
Memory Library File
PhysicalDataMap
The parentheses in the preceding expression are literal characters.

• <counterBit> is c[index] | r[index]
where c[index], r[index] represent the counter bits used to generate the column and row
addresses.
When specifying the mapping between the data input ports of the memory and the
internal data lines, you must follow these rules:
• Data[indexes] must be contiguous, as follows:
PhysicalDataMap {
Data[0]: d[0];
//ERROR: missing Data[1]
Data[2]: d[2];
Data[3]: d[3];
}
• d[index] must use every Data[index] exactly once. For example,

PhysicalDataMap {
Data[0]: d[0];
Data[1]: d[0];
//ERROR: d[0] used more than
//once. d[1] missing.
}
Default Value
If your memory library files do not include a physical data map wrapper, ETAssemble assumes
a one-to-one mapping, Data[n]: d[n].
Usage Conditions
The PhysicalDataMap wrapper is used in the MemoryTemplate wrapper.
• The address counter bit specified in the physical data map equation must be defined in
the AddressCounter wrapper of your memory library file.
• The data bus must be an even multiple of the size of the physical data map wrapper.
ETAssemble repeats the entire physical data map wrapper to produce a map wide
enough for the actual data bus.
Example 1
Figure 4-4 is a typical PhysicalDataMap wrapper for an 8-bit wide memory.
Memory Library File
PinMap
Figure 4-4. PhysicalDataMap Wrapper for an 8-Bit-Wide Memory
PhysicalDataMap {
Data[0]: not d[1] xor c[0];
Data[1]: d[0] xor c[0];
Data[2]: d[2];
Data[3]: not d[3] xor (c[1] and not r[2]) xor r[4];
Data[4]: d[4] xor (not c[3] and r[5]) xor (c[3] and not r[5]);
Data[5]: d[5] xor c[0];
Data[6]: d[6];
Data[7]: not d[7] xor c[1] xor c[8];
}
Example 2
Figure 4-5 shows two equivalent versions of the PhysicalDataMap wrapper for a 4-bit wide
memory. ETAssemble interprets the first PhysicalDataMap wrapper as shown in the second
PhysicalDataMap wrapper.
Figure 4-5. PhysicalDataMap Wrappers for a 4-Bit-Wide Memory
PhysicalDataMap {
Data[0]: not d[0];
Data[1]: d[1];
}
PhysicalDataMap {
Data[0]: not d[0];
Data[1]: d[1];
Data[2]: not d[2];
Data[3]: d[3];
}
PinMap
The contents of the PinMap wrapper allows you to instruct ETAssemble to treat pins that have
this property as repair specific pins. These pins can be used to create the self-repair registers and
connect them to the associated BIRA ports to enable efficient implementation of self-repair
logic.
Using the SpareElement wrapper, you can specify mappings from the BISR fuse registers to the
corresponding memory repair ports. These pin mappings are used to connect the BISR fuse
register ports to the memory repair ports.
Memory Library File
PipelineDepth
Syntax
PinMap {
SpareElement {
FuseMap[<index>]: <name>;}//only used in the
//ColumnSegment wrapper
}
.
. / Repeat for all SpareElements
.
}
Usage Conditions
This wrapper is used in the MemoryTemplate wrapper inside the RowSegment or
Example
PinMap {
SpareElement {
Fuse[0]: B0_RR0[0];
Fuse[1]: B0_RR0[1];
Fuse[2]: B0_RR0[2];
Fuse[3]: B0_RR0[3];
}
SpareElement {
Fuse[0]: B0_RR1[0];
Fuse[1]: B0_RR1[1];
Fuse[2]: B0_RR1[2];
Fuse[3]: B0_RR1[3];
}
}
PipelineDepth
The optional PipelineDepth property declares the number of cycles to delay the compare on the
read data. The adjustment is memory specific and typically is used to handle memories with
built-in pipelining. The compare on the read data is enabled by the StrobeDataOut property in
the OperationSet:Operation:Tick wrapper. In the operation set used with this memory, the
position of StrobeDataOut is pipelined by the specified number of stages. Using the
Memory Library File
PipelineDepth
PipelineDepth property enables you to apply a common operation set to multiple memories
having different pipelining and to customize the delay per memory type.
Syntax
where integer is a value specifying the number of cycles to delay the compare on the read data
or the position of StrobeDataOut.
Default Value
Usage Conditions
This property is used in the MemoryTemplate wrapper of the memory library file.
• This property is used only for Programmable memory BIST controllers.

• All memories that are grouped in the same step must have the same PipelineDepth
value.
Example
The following example defines the read operation in the operation set for a typical synchronous
memory. The read access is activated in the first cycle, and the output data is compared on the
second cycle.
Operation (Read) {
Tick {
ReadEnable: On;
}
Tick {
ReadEnable: Off;
StrobeDataOut;
}
}
Figure 4-6 illustrates the same memory having two stages of built-in pipelining on the output
data. To account for the latency of the output data introduced by the internal pipelining stages,
you can specify the PipelineDepth property and apply the same read operation. The
StrobeDataOut signal will be pipelined by two cycles without any modifications to the
operation set.
Memory Library File
Polarity
Figure 4-6. Memory With 2 Stages of Built-In Pipelining on the Output Data
PipelineDepth: 2;
.
.
.
}
Polarity
The Polarity property specifies the active polarity of the port.
Every operation begins with all signals at their inactive values.
Syntax
• ActiveHigh — specifies that a logic “1” on the port activates the function.
• ActiveLow — specifies that a logic “0” on the port activates the function.
Memory Library File
Port
Default Value
The default polarity is ActiveHigh.
Usage Conditions
The Polarity property is used in the Port wrapper.
ETAssemble ignores this property if Function Data, Address, LogicHigh, LogicLow, None, or
Open for the port.
Example
A Polarity entry for a WriteEnable signal that activates when a logic “0” occurs on the port
would be
Function: WriteEnable;
Polarity: ActiveLow;
Port
The Port wrapper defines the direction, function, and bus parameters for a signal port. The
memory library file includes a Port wrapper for each port on the memory.
Figure 4-7 on page 304 summarizes the Port wrapper properties.
Syntax
Each Port wrapper begins with this syntax:
• portName — is the name of the port. Because ETAssemble instantiates the memory into
a memory BIST interface, portName must match the actual port name of the memory
module.
• [LeftIndex:RightIndex] — identifies the range for bused ports.
If you include the range for a bused port in the Port wrapper, you do not need to specify
the BusRange property.
If portName does not contain a %d character identifier and the Function property
specifies either Data or GroupWriteEnable, then RightIndex must be 0.
If portName contains a %d character identifier, ETAssemble expands the port based on
the range in the Port wrapper property name or the BusRange property. This enables the
support of both bused and scalar memory ports. For the Port wrapper shown in the
Example shown in Figure 4-1, ETAssemble expands the memory ports in the RTL code
output file for the memory BIST interface.
Memory Library File
Port
Note
The %d scalar notation is case sensitive. If you use %D, the Port is treated as a bus with %D
as part of the name. This makes it impossible to load the ETAssemble output into other
Siemens EDA tools or any simulator.
Figure 4-7. Port Wrapper Syntax
BusRange : [LeftIndex:RightIndex];
Function: Address | BistEn | BistOn | Clock | Data |
GroupWriteEnable |LogicHigh | LogicLow |(None) | Open|
OutputEnable | ReadEnable | ScanTest | Select |
ShadowAddressEnable | ShiftEnable | WriteEnable | CAS | RAS |
User0 | User1 | User2 | User3 | User4 | User5 | User6 | User7 |
User22 | User23 | Refresh | Activate | Precharge |
ValidData | BisrParallelData | BisrSerialData |
BisrClock | BisrReset | BisrScanEnable;
EmbeddedTestLogic {
}
} //end of Port wrapper
.
. //Repeat this syntax until you define all BIST ports.
.
Example 1
For this Port wrapper,
Port (AADR%d) {
Direction: Input;
LogicalPort: A;
Function: Address;
BusRange:[3:0];
}
ETAssemble expands the bused AADR port as follows:
module MEM (AADR3, AADR2, AADR1, AADR0...

input AADR3, AADR2, AADR1, AADR0;
Example 2
Memory Library File
ReadOutOfRangeOK
Port (AADR [3:0]) {

Direction: Input;
LogicalPort: A;
Function: Address;
}
ETAssemble uses the bused AADR port as follows:
module MEM (AADR...

input [3:0] AADR;
Example 3
Port (AADR) {
Direction: Input;
LogicalPort: A;
Function: Address;
BusRange: [3:0];
}
ETAssemble uses the bused AADR port, identical to Example 3 above:
module MEM (AADR...

input [3:0] AADR;
ReadOutOfRangeOK
The ReadOutOfRangeOK property suppresses the CountRange rule checking when
ShadowRead is set to On. This enables you to use the shadow read cycle even when the low
CountRange for your RowAddress is odd or the high CountRange for your RowAddress is
even. The data from the out-of-range read does not contribute to the BIST results.
Syntax
Default Value
Usage Conditions
The ReadOutOfRangeOK property is used in the MemoryTemplate wrapper.
Memory Library File
RedundancyAnalysis
• Set this property to On only when your memory can tolerate an out-of-range read
without damaging the memory logic or corrupting the memory data.
• This property is meaningful only when ShadowRead is set to On.
Example
In this example, setting ShadowRead to On causes the memory controller to read from
addresses 0 and 17. The standard ShadowRead rule-checking would not normally allow this
condition, but setting ReadOutOfRangeOK disables the rule check and implements the test.
ReadOutOfRangeOK: On;
ShadowRead: On;
AddressCounter {
Function (RowAddress) {CountRange[1:16];}
}
RedundancyAnalysis
The RedundancyAnalysis wrapper indicates that the built-in repair analysis (BIRA) feature is
required for the memory described by the memory template. The properties and wrappers
within this wrapper contain information about the repairable memory segments, the number of
spare elements within a segment, and the addresses to be logged for the spare fuses.
Memory Library File
RedundancyAnalysis
Syntax
SegmentAddress[<bitIndex>]: AddressPort(<name>);
.
.
}
ColumnSegment (<segmentName>) {
PinMap {
SpareElement {
FuseMap [bitIndex]: <repairPortName> |
RepairRegister[bitIndex]; //Only used in
// the ColumnSegment wrapper
LogicLow: <pinName>| RepairRegister[<x>];
.
.
}
}
NumberOfSpareElements : <int>;
ShiftedIORange: <dataPortName>,...;
FuseSet {
Fuse[<bitIndex>]: AddressPort(<name>) |
.
.
ShiftedIO: (<DataPortName>): <bitString>;
.
.
}
}
}
.
.
RowSegmentRange {
SegmentAddress[bitIndex]: AddressPort(<name>);
.
.
}
RowSegment (<segmentName>){
Memory Library File
RedundancyAnalysis
PinMap {
SpareElement {
LogicLow: <pinName>| RepairRegister[<x>];
}
.
.
}
FuseSet {
Fuse [bitIndex]: AddressPort(<name>) |
.
.
}
}
.
.
}
Note
For multi-port memories, you only need to define the repair information for one port.
Tessent MemoryBIST tests the ports in sequence re-using the same comparators between
ports. The comparator results are cumulative and capture all defects for all ports at the end of
the test.
Example
The following example specifies four RowSegment wrappers.
• Each segment consists of two spare elements and is located in the address space defined
by the address ports AD[12:10].
• The RowSegment(Bank0) is defined within the address space, whereby AD[12:10] is
within 3'b000 and 3'b001.
Memory Library File
RepairEnable

RowSegmentRange {
}
RowSegment (Bank0){
FuseSet {
}
}
RowSegment (Bank1){
FuseSet {
}
}
RowSegment (Bank2){
FuseSet {
}
}
RowSegment (Bank3){
FuseSet {
}
}
}
RepairEnable
The RepairEnable property is used to identify the memory pin name that is used to control the
memory repair function or to describe the order of the internal BISR chain register for the serial
BISR interface.
Memory Library File
RepairEnable
Syntax
• repairPortName — specifies memory pin name used to control the memory repair
function.
• RepairRegister [bitIndex] — allows you to describe the order of the internal BISR chain
register for the serial BISR interface.
The total BISR chain length (N) for a given memory is equal to the number of the
RepairRegister[<bitIndex>] properties specified in the RowSegment and
ColumnSegment wrappers combined inside a memory library file. The
RepairRegister[0] specifies the BISR chain register that is closest to the BISR scanOut
port, and the RepairRegister[N-1] specifies the BISR chain register that is closest to the
BISR scanIn port.
A single BISR chain register is generated for each memory library file. The
RepairRegister[x] indexes must be contiguous from 0 to N-1 within a memory library
file. All indexes between 0 and N-1 must be used, and each index can only be used once.
You must take care to describe the RepairRegister[x] indexes to match the internal
memory BISR chain order specified in the memory data sheet. Any mismatch between
the external and internal BISR chains ordering will result in the incorrect repair data
scanned inside the memory.
Default Value
None
Usage Conditions
This property is used in the PinMap: SpareElement wrapper of repairable memories.
Example
PinMap {
SpareElement {
Fuse[0]: B0_RR0[0];
Fuse[1]: B0_RR0[1];
Fuse[2]: B0_RR0[2];
Fuse[3]: B0_RR0[3];
}
}
Memory Library File
RetentionTimeMax
RetentionTimeMax
The RetentionTimeMax property specifies the upper limit of retention time between two full
refreshes of a DRAM array. Therefore, the real refresh interval between two consecutive refresh
operations applied to the memory is computed as RetentionTimeMax divided by the maximum
number of memory rows obtained based on the row CountRange property
(2RowCountRangeBits). The value of RowCountRangeBits is the number of bits necessary to
store the row CountRange of the memory so that 2RowCountRangeBits is the row CountRange
rounded up to the nearest power of 2.
The RetentionTimeMax value is also used to size the delay counter so that all the desired
retention time values can be accommodated.
Syntax
The syntax for this property is as follows:
RetentionTimeMax: time[s | ms | us | (ns) | ps];
where time is a real number that specifies the time elapsed between an access to the same row in
the memory array. Valid values for specifying the units for time 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
None
Usage Conditions
The RetentionTimeMax property is used in the MemoryTemplate wrapper.
• RetentionTimeMax must be a value greater than zero if MemoryType is defined as

DRAM.
• The number of RowAddress bits specified in MemoryTemplate: AddressCounter:
LogicalAddressMap must be greater than zero.
Memory Library File
Retimed
Example
This example specifies that the maximum retention time for this DRAM is 100 milliseconds:
MemoryType: DRAM;
RetentionTimeMax: 100ms;
Retimed
For a memory implementing the serial repair interface, the Retimed property specifies if the
internal BISR chain has a negedge retiming flop on its scanout port. This property is used only
when declaring the memory pin corresponding to the repair serial data output.
Syntax
• On—specifies that a negedge retiming flop is present at the output of the internal BISR
chain.
• Off—specifies that no retiming flop is present on the internal BISR chain.
Default Value
The default is Off.
Usage Conditions
The Retimed property is used in the Port wrapper when Function: BisrSerialData and
Direction: Output are specified.
Example
The following example specifies that the internal BISR chain has a negedge retiming flop on the
SDOUT port:
Port(SDOUT) {
Function: BisrSerialData;
Direction: Output;
Retimed: On;
}
Memory Library File
ROMContentsFile
ROMContentsFile
The ROMContentsFile property specifies the name of the ROM contents file. The ROM
contents file is a hexadecimal or a binary listing of the ROM contents. Each line in the ROM
contents file represents a single address location within the ROM starting with address 0.
The entire ROM contents file should be specified in hexadecimal or binary. The two formats
cannot be mixed within the same ROM contents file. The number of hexadecimal or binary
digits per line must be consistent with the width of the ROM locations. For example, each entry
for a 12-bit wide ROM must be specified exactly as three hexadecimal digits (000 to 3FF) or 12
binary digits (000000000000 to 1111111111111).
Figure 4-8 is a ROM contents file in hexadecimal format for a 16-bit wide ROM. Since the last
entry in the ROM contents file is FFFF, all subsequent address locations assume the FFFF data
value.
Figure 4-8. ROM Contents File in Hexadecimal Format
0060
E896
0000
0000
0000
0000
0000
0000
C010
01C6
0000
0000
C010
0212
0000
0000
C010
025E
FFFF
Figure 4-9 is a ROM contents file in binary format for a 6-bit wide ROM. Since the last entry in
the ROM contents file is 101111, all subsequent address locations assume the 101111 data
value.
Memory Library File
RowSegment
Figure 4-9. ROM Contents File in Binary Format
001000
011011
000110
000110
001111
101000
101011
101010
101111
Syntax
where ROMContentsFileName can be any identifier that identifies the ROM contents file.
ROMContentsFileName can be either an absolute path or a file path relative to the working
directory, the directory in which you invoked ETAssemble. When specifying a file path for
ROMContentsFileName, you can begin the identifier with a tilde (~).
Default Value
None
Usage Conditions
The ROMContentsFile property is used in the MemoryTemplate wrapper.
The MemoryType property must be specified to ROM, otherwise the ROMContentsFile

property is ignored.
The ETPlanner property ROMContentFile overrides the value of this property in the memory
library file.
Example
This example specifies that the name of the ROM contents file is ROM16X32.data.
ROMContentsFile: ROM16X32.data;
RowSegment
The RowSegment wrapper enables you to identify a segment of the memory address space that
contains spare row elements. The row segment can be the whole address space or a subset of the
address space. Specify this wrapper in the RedundancyAnalysis wrapper to implement row
repair analysis.
Memory Library File
RowSegment
Syntax
RowSegment (<segmentName>){
FuseSet {
Fuse [<bitIndex>]: AddressPort(<name>) |
.
. //Repeat for all Fuses
.
}
//Begin BISR-specific syntax
PinMap {
SpareElement {
Fuse [<bitIndex>]: <repairPortName> |
}
.
.
}
// End BISR-specific syntax
}
.
.
where segmentName is a unique identifier for the memory segment.
Default Value
None
Usage Conditions
The RowSegment wrapper is used in the RedundancyAnalysis wrapper.
The number of RowSegment wrappers defined must encompass the entire memory address
space if the RowSegmentRange wrapper is specified.
Example
Refer to the example in the RedundancyAnalysis wrapper description.
Memory Library File
RowSegmentRange
RowSegmentRange
The RowSegmentRange wrapper enables you to specify the memory address bits used to define
the address space for the specified row segment. The RowSegmentRange is used to define the
significant row bits of the address bus that are used define RowSegmentCountRange limits in
the ColumnSegment and RowSegment wrappers.
Syntax
RowSegmentRange {
SegmentAddress[y]: AddressPort(<name>);
.
. Repeat for all SegmentAddress bits
.
}
Default Value
If only one RowSegment wrapper is defined within the RedundancyAnalysis wrapper, the
RowSegmentRange wrapper defaults to encompass the whole memory address space.
Usage Conditions
The RowSegmentRange wrapper is used in the RedundancyAnalysis wrapper.
• You do not need to specify this wrapper if only one RowSegment wrapper is defined
within the RedundancyAnalysis wrapper. If only one RowSegment wrapper is defined
within the RedundancyAnalysis wrapper, the row segment will encompass the whole
memory address space.
• If more than one RowSegment wrapper is defined within the RedundancyAnalysis
wrapper, the RowSegmentRange wrapper is required and all the segment ranges
specified for all wrappers must encompass the whole memory address space.
Example
Refer to the example in the RedundancyAnalysis wrapper description.
RowSegmentCountRange
RowSegmentCountRange property:
Memory Library File
ColumnSegment Usage
The RowSegmentCountRange property defines the portion of the row address space where the
segment’s spare elements can replace a defective IO/Column element.
Syntax
used to enable the repair analysis for this segment.
bits used to enable the repair analysis for this segment.
Default Value
If any SegmentAddress bits are specified in the RowSegmentRange wrapper, the
RowSegmentCountRange property defaults to a lowRange of zero to a highRange of 2n -1,
Usage Conditions
The RowSegmentCountRange property is used in the ColumnSegment and RowSegment
wrappers.
• The RowSegmentCountRange property can be specified only when at least one

• When more than one ColumnSegment wrapper is specified, the combined count ranges
of all RowSegmentCountRange properties must encompass all possible codes defined
by the SegmentAddress properties of the RowSegmentRange wrapper. Any unused
codes must be explicitly indicated within the range values of the
RowSegmentCountRange property.
Example
In the following example, column segment Bank0 will be enabled when address port AD[10] is
logic 0. Bank1 will be enabled when AD[10] is logic 1.
Memory Library File
RowSegmentRange {
}
RowSegmentCountRange[1'b0:1'b0];
.
.
.
}
.
.
.
}
RowSegment Usage
The RowSegmentCountRange property defines the portion of the row address space where the
segment’s spare elements can replace a defective row element.
Syntax
used to enable the redundancy analysis for this segment.
Default Value
If any SegmentAddress bits are specified in the RowSegmentRange wrapper, the
RowSegmentCountRange property defaults to a lowRange of zero and to a highRange of 2n -1,
Usage Conditions
The RowSegmentCountRange property is used in the RowSegment and ColumnSegment
wrappers.
• The RowSegmentCountRange property can be specified only when at least one

SegmentAddress bit is defined in the RowSegment wrapper.
Memory Library File
SafeValue
• When more than one RowSegment wrapper is specified, the combined count ranges of
all RowSegmentCountRange properties must encompass all possible codes defined by
the SegmentAddress properties of the RowSegmentRange wrapper. Any unused codes
must be explicitly indicated within the range values of the RowSegmentCountRange
property.
Example
In the following example, row segment Bank0 will be enabled when address port AD[11] is
logic 0 and AD[10] is logic 0. Row segment Bank1 will be enabled for all remaining AD[11]
and AD[10] combinations.
RowSegmentRange {
}
RowSegment(Bank0) {
.
.
.
}
RowSegment(Bank1) {
.
.
.
}
SafeValue
The SafeValue property specifies an assumed value that is applied to the memory input ports
with Function None during the memory assembly simulation only. The memory assembly
module instantiates the memory controller and interfaces and is used to verify the operation of
the BIST circuitry.
ETAssemble does not add additional logic to a memory port for which SafeValue is specified.
The assumed value is applied from the memory assembly test bench. Once the memory
controller and interfaces are inserted into your design, the memory inputs defined with Function
None will be driven by their functional values.
Syntax
SafeValue: (X) | O | 1;
• X — sets the port to logic “X” in the memory assembly testbench. X denotes the value as
ambiguous.
Memory Library File
SegmentAddress
• 0 — sets the port to logic “0” in the memory assembly testbench.

• 1 — sets the port to logic “1” in the memory assembly testbench.
For bussed ports, the specified value will be applied to all bits of the port unless a multi-bit
binary value matching the port width is specified. Specifying a multi-bit binary value will apply
the respective SafeValue value for each individual bit of the bussed port.
Default Value
This property defaults to X.
Usage Conditions
The SafeValue property is used in the Port wrapper.
Specify SafeValue only for ports that specify Direction: Input and Function: None in the
definition.
The SafeValue property only has an effect when simulating the memory assembly module.
Example
This example applies logic 0 to the input port RMA during the memory assembly simulation:
Port(RMA) {
Function: None;
Direction: Input;
SafeValue: 0;
}
This example applies a multi-bit value matching the input port width:
Port(MBus[2:0]) {
Function: None;
Direction: Input;
SafeValue: 3'b010;
}
SegmentAddress
SegmentAddress property:
• ColumnSegmentRange Usage
• RowSegmentRange Usage
Memory Library File
SegmentAddress
ColumnSegmentRange Usage
The SegmentAddress property enables you to specify which address ports are used to define
the range of the memory segment.
Syntax
• y — identifies an the segment address bit number.

• name — represents the address port value that will be used to select a memory segment.
Default Value
None
Usage Conditions
The SegmentAddress property is used in the ColumnSegmentRange wrapper.
• If only one ColumnSegment wrapper is defined, the ColumnSegmentRange wrapper

value defaults to encompass the whole memory address range.
• name must either be a scalar port or a single bit of a bused port.
• name must identify a port defined in the memory library file with Function: Address.
Example
In this example, address port AD[10] is used to define the range of the IO/Column segments:
SegmentAddress[0]: (AD[10]);
}
}
RowSegmentRange Usage
The SegmentAddress property enables you to specify address ports are used to define the range
of the memory segment.
Syntax
Memory Library File
ShadowRead
• y — identifies an the segment address bit number.

• name — represents the address port value that will be used to select a memory segment.
Default Value
None
Usage Conditions
The SegmentAddress property is used in the RowSegmentRange wrapper.
• SegmentAddress[y] — for all specified SegmentAddress properties, y must start from 0

and encompass all valid integers to n-1 where n is the number of the SegmentAddress
properties specified.
• name must either be a scalar port or a single bit of a bused port.
• name must identify a port defined in the memory library file with Function: Address.
• If only one RowSegment wrapper is defined within the RedundancyAnalysis wrapper,
the RowSegmentRange wrapper defaults to encompass the whole memory address
space.
Example
The following example specifies a segment range where the SegmentAddress bit 0 is defined as
memory address port AD[10], and SegmentAddress bit 1 is defined as memory address port
AD[11]. This address bit is used by the RowSegmentCountRange property in the RowSegment
wrapper to define the segment address range for segment Bank2.
RowSegmentRange {
}
RowSegment(Bank2) {
ShadowRead
The ShadowRead property enables and disables the shadow read cycle. To detect shorts
between multiple logical ports, the memory BIST controller performs a shadow read on inactive
read ports during both the write and the read cycles of the active ports.
ShadowRead does not allow to read a memory cell located in a different column when executing
algorithms on a programmable controller using a custom operation set. ConcurrentRead should
be used for greater flexibility.
Memory Library File
ShadowRead
Syntax
• On — enables the shadow read by inverting bit0 of the row address counter.
• Off — disables the shadow read.
Default Value
The default value for this property depends upon whether or not the Usage Conditions are met.
If the conditions are satisfied, this property defaults to On. If the conditions are not met, this
property defaults to Off.
Usage Conditions
The ShadowRead property is used in the MemoryTemplate wrapper.
• If ShadowRead is On, the OperationSet section in the memory library file must specify
the ShadowReadAddress and ShadowReadEnable waveforms.
• If ShadowRead is On, you must specify a row address. For information on specifying a
row address, refer to the AddressCounter wrapper.
• If ShadowRead is On, you can use the default address counter only if the value specified
for the NumberOfWords property is even.
• If ShadowRead is On, lowRange for Function(RowAddress): CountRange must be an
even value and highRange for Function(RowAddress): CountRange must be an odd
value. ou can suppress this rule by setting the ReadOutOfRangeOK property to On.
• If you specify LogicalPorts: 1RW or 1R, you cannot specify ShadowRead On.
• When ShadowWrite is On the ShadowRead property will be turned to On as well.
Note
The restrictions relating to the address counter prohibit an out-of-range address, that is
caused by inverting bit0 of the row address counter, when the ShadowReadAddress
waveform is On.
Memory Library File
ShadowWrite
Example
The following example enables shadow read during the memory test:
MemoryTemplate(MEM) {
ShadowRead: On;
.
.
}
ShadowWrite
The ShadowWrite property enables and disables the shadow write operation. The shadow write
operation is used to detect inter-port bitline coupling faults for multiple ReadWrite logical ports.
The memory BIST controller performs a shadow write on inactive ReadWrite ports in specific
phases of the SMarchCHKBci, SMarchCHKBcil, and SMarchCHKBvcd algorithms during the
READ cycle of the active ReadWrite port. For memories with one Read and two Write ports,
the SMarchCHKBci, SMarchCHKBcil, and SMarchCHKBvcd algorithms also support shadow
write on inactive write ports during the READ and WRITE cycles of the active port.
When ShadowWrite is On and ShadowWriteOk is On in the memory library file, concurrent

operations are enabled in programmable controllers. The OperationSet SyncWRvcd is
automatically selected if Algorithm: SMarchCHKBvcd is specified, and the user can then
modify the way concurrent operations are performed in the SMarchCHKBvcd library algorithm,
or in any custom algorithm. ShadowWrite operations are not controllable from the operation set
and are only used by library algorithms.
Syntax
• On—enables the shadow write by forcing the row address to its full binary range.
• Off—disables the shadow write.
Default Value
Usage Conditions
The ShadowWrite property is used in the MemoryTemplate wrapper.
Memory Library File
ShadowWrite
If ShadowWrite is On, the following conditions must be satisfied:
• The memories must be synchronous SRAM. Preferably, Siemens EDA Sync or

SyncWR operation sets should be used. Other operation sets must take into account that
the waveform used to perform shadow writes from inactive ports is the exact inverse of
the waveform described for write enable signals. Also, the row address changes at the
same time as the write enable signal. These waveforms might not be appropriate in all
cases, especially for asynchronous memories.
• If no memory port with Function ShadowAddressEnable is defined, the number of rows
cannot be a power of two. The row address range must not use the full binary count. It
might be required to generate a new memory block with at least one more row to comply
with this restriction. Note that this restriction does not apply to memories that use the
SMarchCHKBvcd algorithm.
• The memories must have a bit grouping of 1.
• The memories must have ONE of the following combinations of ports:
• Two ReadWrite ports
• One Read-only port and one Write-only port
• Any number of Read-only ports and two Write-only ports
• The algorithm used must be SMarchCHKBci, SMarchCHKBcil, or SMarchCHKBvcd.
• If ShadowWrite is On, you must specify a row address. For information on specifying a
row address, refer to the AddressCounter wrapper.
• The ShadowWriteOK property must be On.
Note
If the above conditions are not met ETAssemble issues a warning and forces the
ShadowWrite property to Off.
Example
The following example applies shadow write during the memory test with the SMarchCHKBcil
algorithm:
MemoryTemplate(MEM){
Algorithm: SMarchCHKBcil;
BitGrouping: 1;
ShadowWrite: On;
ShadowWriteOK: On;
.
.
}
Memory Library File
ShadowWriteOK
ShadowWriteOK
The ShadowWriteOK property is used to indicate that the memory can tolerate an out-of-range
address during shadow write without damaging the memory logic or corrupting the data. If
enabled it suppresses the count range rule checking. This property must be set to On to perform
shadow writes on the memory.
ShadowWrite operations are not controllable from the operation set and are only used by library
algorithms. ConcurrentWrite operations are fully controllable from the operation set.
Syntax
• On — indicates your memory can tolerate out of range addresses during shadow write.
The count range rule checking is disabled.
• Off — indicates that the memory cannot tolerate out of range addresses and therefore
shadow writes should not be used on this memory.
Default Value
Usage Conditions
The ShadowWriteOK property is used in the MemoryTemplate wrapper.
If ShadowWriteOK is On, the following conditions must be satisfied:
• The memory must be able to tolerate out of range addresses without damage or
corruption.
• The ShadowWrite property must be On.
Example
The following example applies shadow write during the SMarchCHKBcil algorithm:
MemoryTemplate(MEM){
Algorithm: SMarchCHKBcil;
BitGrouping: 1;
ShadowWrite: On;
ShadowWriteOK: On;
}
Memory Library File
ShiftedIO
ShiftedIO
The ShiftedIO property enables you to specify the values to be logged in the fuse register, which
will identify each defective IO.
Syntax
ShiftedIO(<DataPortName>):<bitString>;
where DataPortName is a defective port name.
Default Value
None
Usage Conditions
The ShiftedIO property is used in the ColumnSegment: FuseSet: FuseMap wrapper.
• You should specify a ShiftedIO property for all memory data outputs. Otherwise, an
error message is generated.
• You can specify the same bitString value for ShiftedIO properties of different memory
outputs. However, a limitation applies. See the “Limitations and Restrictions” section in
the “Implementing and Verifying Memory Repair” chapter of the Tessent MemoryBIST
Example
In this example, the fuse register will log the binary value 0000 when a failure is detected on
data port Data[0].
ShiftedIORange
The ShiftedIORange property enables you to define a group of IO bits where spare elements can
replace a faulty IO. When a defective element is within this group, a spare element can be
allocated from this segment.
Syntax
ShiftedIORange: <DataPortName>, <DataPortName>,...;
Memory Library File
SpareElement
where DataPortName is a valid data port name. Each port name can be bused port or scalar
ports separated by comma.
Default Value
The default range includes all IO bits of the data port.
Usage Conditions
The ShiftedIORange property is used in the ColumnSegment wrapper.
Example
This example specifies that the spare element in column segment LEFT is dedicated to repairing
data ports Q4, Q5, Q6 and Q7. The spare element in column segment RIGHT is dedicated to
repairing data ports Q0, Q1, Q2 and Q3.
ColumnSegment(LEFT) {
ShiftedIORange: Q4,Q5,Q6,Q7;
}
ColumnSegment(RIGHT) {
ShiftedIORange: Q0,Q1,Q2,Q3;
}
SpareElement
The SpareElement wrapper is used to treat pins in this wrapper as repair specific pins for
repairable memories to enable efficient implementation of self-repair logic.
Using the SpareElement wrapper, you can specify mappings from the BISR fuse registers to the
corresponding memory repair ports. These pin mappings are used to connect the BISR fuse
register ports to the memory repair ports.
Syntax
SpareElement {
RepairEnable: <name>;
Fuse [y]: <name>;
FuseMap[<index>]: <name>;}//only used in the
//ColumnSegment wrapper
}
.
.
Default Value
None
Memory Library File
TestInput
Usage Conditions
The SpareElement wrapper is used in the PinMap wrapper inside the ColumnSegment or
RowSegment wrapper.
• If the Self-Repair feature is used, each RowSegment or ColumnSegment wrapper must

have a PinMap: SpareElement wrapper(s).
o When specified inside the RowSegment wrapper, the PinMap wrapper might
contain multiple SpareElement wrappers.
o When specified inside the ColumnSegment wrapper, only a single SpareElement
wrapper might be specified inside the PinMap wrapper.
o The number of PinMap: SpareElement wrappers inside the RowSegment wrapper
must be equal to the NumberOfSpareElements property.
• The FuseMap property is used only in the SpareSegment wrapper inside the
Example
PinMap {
SpareElement {
Fuse[0]: B0_RR0[0];
Fuse[1]: B0_RR0[1];
Fuse[2]: B0_RR0[2];
Fuse[3]: B0_RR0[3];
}
SpareElement {
Fuse[0]: B0_RR1[0];
Fuse[1]: B0_RR1[1];
Fuse[2]: B0_RR1[2];
Fuse[3]: B0_RR1[3];
}
}
TestInput
The TestInput property identifies the input test port associated with a functional port. When
defined for a functional input port, this property specifies that embedded multiplexing logic
exists within the memory interface to select between the functional port and the test port. This
selection is controlled by an input port with Function BistOn.
Memory Library File
TestInput
For a functional output port, this property specifies that embedded multiplexing logic exists
within the memory interface to bypass the memory output with test data. This selection is
controlled by an input port with Function ScanTest.
For an input port of function Clock, this property specifies that embedded multiplexing logic
exists within the memory interface to select between the functional clock and a BIST clock.
This selection is controlled by an input port with Function BistEn.
Syntax
• portName — specifies the name of the input test port associated with the functional port
being defined Since ETAssemble instantiates the memory into a memory BIST collar,
portName must match the actual port name of the memory module:
o [LeftIndex:RightIndex] — identifies the range for bused ports.
o If portName contains a %d character identifier, ETAssemble expands the port based
on the range in the Port wrapper property name or the BusRange property. This
enables the support of both bused and scalar memory ports.
o If portName does not contain a %d character identifier and the Function property
Note
The %d scalar notation is case sensitive. If you use %D, the Port is treated as a
bus with %D as part of the name. This makes it impossible to load the
ETAssemble output into other Siemens EDA tools or any simulator.
Default Value
None
Usage Conditions
The TestInput property is used in the EmbeddedTestLogic wrapper.
• The bus range must be the same as the range specified for the functional port being
defined. The exceptions are the test data input port and test group write enable input
port.
• You can specify a test data input port or a test group write enable input port that is
narrower than its functional signal. The test input signals are assumed to be repeated
Memory Library File
TestInput
inside the memory module to form the internal data bus or the write mask controls to the
memory array. The following limitations apply when testing such a memory design:
• The valid test data width must range from 2 bits up to the functional port width.
• The valid test group write enable width must range from 1 bit up to the functional port
width.
• The ETPlanner property ControllerType must be set to HardProgrammable or
SoftProgrammable.
• Only data input and group write enable ports specified with the EmbeddedTestLogic:
TestInput property are supported; all other test input ports must conform to the identical
width requirement.
• No data scrambling can be present within the memory array itself.
• A memory having narrower test data input cannot be tested using the serial interface
approach. Therefore, the ETPlanner property BitSliceWidth must be 1 for such a
memory type.
• To support scalar or bit-blasted types for the data and group write enable ports, their
definition in the memory library is restricted to the following syntax; the functional and
test ports must be specified in one Port wrapper using the %d notation:
Port (DIN%d[31:0]) { // functional port
Function: Data;
Direction: Input;
EmbeddedTestLogic {
TestInput: DFTDIN%d[31:0]; // test port
}
}
• If this property is defined for an input functional port, then a port with Function BistOn
must also be defined. If defined for an input clock port, then a port with Function BistEn
must also be defined. If defined for an output functional port, then a port with the
Function ScanTest must also be defined.
• The existence of this property must be consistent among all functional ports having the
same function and assigned to the same logical port.
• If this property is defined for a functional output port, then the TransparentMode
property must have a value of SyncMux.
Example 1
The following example specifies that the test input port TA[7:0] is associated with functional
port A[7:0].
Memory Library File
TestInput
Port (A[7:0]) {
Function: Address;
EmbeddedTestLogic {
TestInput: TA[7:0];
}
}
Port (TESTSEL) {
Function: BistOn;
}
Example 2
The following example specifies the group of scalar test ports TA7, TA6, .., TA0.
Port (A%d[7:0]) {
Function: Address;
EmbeddedTestLogic {
TestInput: TA%d[7:0];
}
}
Example 3
The following example specifies an 11-bit functional port and a 4-bit test port and shows the
assumed mapping.
Port (D[10:0]) { // functional port

Function: Data;
Direction: Input;
EmbeddedTestLogic {
TestInput: TD[3:0]; // test port
}
}
Test Data Input Memory Word

TD[0] bit 0
TD[1] bit 1
TD[2] bit 2
TD[3] bit 3
TD[0] bit 4
TD[1] bit 5
TD[2] bit 6
TD[3] bit 7
TD[0] bit 8
TD[1] bit 9
TD[2] bit 10
Memory Library File
TestInput
Example 4
The following example specifies a 16-bit functional data port DIN and a 4-bit test port DFTDIN
and shows the assumed mapping. The memory implements bit write mask, and the test group
write enable signal, DFTWBE, is 4 bits.
Port (DIN[15:0]) { // functional port

Function: Data;
Direction: Input;
EmbeddedTestLogic {
TestInput: DFTDIN[3:0]; // test port
}
}
Port (WBE[15:0]) { // functional port
Function: GroupWriteEnable;
Direction: Input;
EmbeddedTestLogic {
TestInput: DFTWBE[3:0]; // test port
}
}
Memory Word Bit DFTDIN Bit WBE Bit DFTWBE Bit

0 0 0 0
1 1 1 1
2 2 2 2
3 3 3 3
4 0 4 0
5 1 5 1
6 2 6 2
7 3 7 3
8 0 8 0
9 1 9 1
10 2 10 2
11 3 11 3
12 0 12 0
13 1 13 1
14 2 14 2
15 3 15 3
Memory Library File
TestInput
Example 5
The following example specifies a 16-bit functional data port DIN and a 4-bit test port DFTDIN
and shows the assumed mapping. The memory implements write mask, and the test group write
enable signal, DFTWBE, is 2 bits.
Port (DIN[15:0]) { // functional port

Function: Data;
Direction: Input;
EmbeddedTestLogic {
TestInput: DFTDIN[3:0]; // test port
}
}
Port (WBE[3:0]) { // functional port
Function: GroupWriteEnable;
Direction: Input;
EmbeddedTestLogic {
TestInput: DFTWBE[1:0]; // test port
}
}
Memory Word Bit DFTDIN Bit WBE Bit DFTWBE Bit

0 0 0 0
1 1
2 2
3 3
4 0 1 1
5 1
6 2
7 3
8 0 2 0
9 1
10 2
11 3
12 0 3 1
13 1
14 2
15 3
Memory Library File
TestOutput
TestOutput
The TestOutput property identifies the output test port associated with a functional port. When
defined for a functional output port, the TestOutput property identifies the dedicated output
port used to create the BIST serial interface and to observe test responses. When defined for a
functional input port, the property identifies the output port used to observe the multiplexed
functional and test input data.
Syntax
• portName — specifies the name of the output test port associated with the functional
port being defined Since ETAssemble instantiates the memory into a memory BIST
collar, portName must match the actual port name of the memory module:
o [LeftIndex:RightIndex] — identifies the range for bused ports.
o If portName contains a %d character identifier, ETAssemble expands the port based
on the range in the Port wrapper property name or the BusRange property. This
enables the support of both bused and scalar memory ports.
o If portName does not contain a %d character identifier and the Function property
Note
The %d scalar notation is case sensitive. If you use %D, the Port is treated as a
bus with %D as part of the name. This makes it impossible to load the
ETAssemble output into other Siemens EDA tools or any simulator.
Default Value
None
Usage Conditions
The TestOutput property is used in the EmbeddedTestLogic wrapper.
• If this property is used with an Input port, then the TestInput property must also appear.
• The bus range must be the same as the range specified for the functional port being
defined.
• The existence of this property must be consistent among all functional ports having the
same function and assigned to the same logical port.
Memory Library File
TransparentMode
Example 1
This example specifies that the test output port TQ[15:0] is associated with functional data
output port Q[15:0].
Port (Q[15:0]) {
Function: Data;
Direction: Output;
EmbeddedTestLogic {
TestOutput: TQ[15:0];
}
}
Port (TESTSEL) {
Function: BistOn;
}
Example 2
The following example specifies the test output port TA%d[7:0].
Port (A%d[7:0]) {
Function: address;
EmbeddedTestLogic {
TestOutput: TA%d[7:0];
}
}
TransparentMode
The TransparentMode property specifies when and how memories are bypassed during scan
testing. Bypassing memories enables testing the user interface logic to and from these
embedded memories as well as the memory BIST controller and collar circuitry.
Syntax
• SyncMux — inserts an additional multiplexer and flip-flop on the collar DataOut ports
that enable combinational ATPG tools to test the interface between the user logic and
the memory. When you specify this value, the collar also provides control values for
scan chain testing. In addition, you can observe the DataIn port by using the same flip-
flop that provides the control values for DataOut.
For ATPG tools that have the capability to generate test patterns through the specified
memories, the additional multiplexer that ETAssemble adds when SyncMux is specified
might not be necessary.
Memory Library File
TransparentMode
• None — specifies that no bypass logic will be added in the memory interface. Specify
None if you have a bidirectional data bus or the memory implements an internal bypass
logic.
• AsyncMux — inserts an additional multiplexer on the collar DataOut ports so that data is
directly transferred from the DataIn ports to the DataOut ports. This setting enables
combinational ATPG tools to test the interface between the user logic and the memory.
Note
To perform memory BIST, which requires controllability of the memory output, you must
disable any internal bypass circuitry in your memory.
Default Value
The default value is SyncMux.
Usage Conditions
The TransparentMode property is used in the MemoryTemplate wrapper.
• You can specify TransparentMode AsyncMux only when DataOutStage is set to None.
• The value in the TransparentMode property in the .etplan file overrides the value of this
property in the memory library file. If TransparentMode is not specified in the .etplan
file, the value in the memory library file takes effect.
Example
If you are using memory BIST, the typical entry for TransparentMode is as follows:
TransparentMode: SyncMux;
Memory Library File
TransparentMode
Chapter 5
.lvbscan Input File
This chapter describes in detail wrappers and properties available in the .lvbscan input file in
alphabetic order.
Complete Syntax for the .lvbscan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
AC_HP_Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
AC_HP_onChip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
AC_LP_Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
ACCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
ACSelectCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
ACMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
ACModeSel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
ACSignal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
AuxIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
AuxOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
BSDLInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
BScanCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
BScanSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
BScanShiftIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
BScanShiftInRetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
BScanShiftOut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
CellInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
ClockBscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
ControlCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
DifferentialType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
DisableResult . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
DisableValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
ForceDisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
FromPad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
InitClk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
InitClkPolarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
PinInv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
SafeValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
SelectJTagInput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
SelectJTagOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
ShiftBScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
ShiftBScan2Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
.lvbscan Input File
Complete Syntax for the .lvbscan File
UpdateBscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

The .lvbscan file serves as input to ETAssemble. This library file consists of boundary-scan cell
descriptions formatted for ETAssemble.
.lvbscan Input File
Figure 5-1. Syntax for .lvbscan File
BScanCells {
BScanCell (<cellName>) {
CellInfo (<CellTypeID>): <bsdlCellDefinition>;
Pin (<portName>) {
PinInv: <portName>;
FromPad: <portName>;
Function: (padIO) | padIOInv;
AuxIn: <AuxInPin>[,AuxInEnPin>];
AuxOut: <AuxOutPin>, <AuxOutEnPin>, [<AuxOutPin>,
<AuxOutEnPin>,..];
AC_HP_Time: <time>;
AC_LP_Time: <time>;
AC_HP_onChip: On | (Off);
DifferentialType: (voltage) | current;
}// End of Pin
ACMode: <PinName>;
ACModeSel: <PinName>;
ACSignal: <PinName>;
InitClk: <PinName>;
InitClkPolarity (RisingEdge) | FallingEdge | Logic1 | Logic0;
ForceDisable: <PinName>;
SelectJTagInput: <PinName>;
SelectJTagOutput: <PinName>;
ClockBscan: <PinName>;
ShiftBScan: <PinName>;
ShiftBScan2Edge: <PinName>;
UpdateBscan: <PinName>;
BScanSegment (<bscanSegmentName>) {
BScanShiftIn: <PinName>;
BScanShiftOut: <PinName>;
BScanShiftInRetime: (Yes) | No;
BSDLInfo (<BSDLInfoID>) {
Function: output2 | output2a | output3 | input |
bidir | control | internal | observe_only |
clock;
CellInfo: <CellTypeID>;
Port: <PinName>;
ControlCell: <BSDLInfoLabel>;
ACCell: On | (Off);
ACSelectCell: <BSDLInfoLabel>;
SafeValue: (x) | 1 | 0;
DisableResult: (Z) | pull0 | pull1 | weak0 | weak1;
DisableValue: (X) | 0 | 1;
}// End of BSDLInfo
}// End of BScanSegment
} // End of BScanCell
} // End of BScanCells
.lvbscan Input File
AC_HP_Time
AC_HP_Time
The AC_HP_Time property is used to document the minimum High pass time constant of an
AC input cell. This value is forwarded to the BSDL file and also affects the TAPVerify pattern
when AC_HP_onChip is specified to Yes.
Syntax
AC_HP_Time: <time>;
where time is the time constant expressed in time units.
Default Value
None
Usage Conditions
The AC_HP_Time property is used in the BScanCell: Pin wrapper.
This property is only relevant for AC input pins.
Example
This example documents a high pass time constant of 5 microseconds.
BScanCell (BlockWithPads){
Pin (A[7:0]){
Function: PadIO;
AC_HP_Time: 5us;
}
}
AC_HP_onChip
The AC_HP_onChip property specifies whether the AC High pass filter associated to an AC
input pin is on the device or on the board.
Syntax
AC_HP_onChip: Yes | (No);
where Yes means the AC high pass filter in on the chip.
Default Value
Default value is No.
.lvbscan Input File
AC_LP_Time
Usage Conditions
The AC_HP_onChip property is used in the BScanCell: Pin wrapper.
Example
This example documents the fact that the Low pass filter is on the chip.
Pin (A[7:0]){
Function: PadIO;
AC_HP_onChip: Yes;
}
}
AC_LP_Time
The AC_LP_Time property is used to document the minimum Low pass time constant of an
AC input cell.
Syntax
AC_LP_Time: <time>;
where time is the time constant expressed in time units.
Default Value
None
Usage Conditions
The AC_LP_Time property is used in the BScanCell: Pin wrapper.
Example
This example documents a low pass time constant of 2 milliseconds.
Pin (A[7:0]){
Function: PadIO;
AC_LP_Time: 2ms;
}
}
.lvbscan Input File
ACCell
ACCell
The ACCell property is used in BSDLInfo wrappers to document if the given output or
bidirectional cell is an AC cell or not.
Syntax
ACSCell: Yes | (No);
Default Value
The default is No.
Usage Conditions
The ACCell property is used in the BScanSegment: BSDLInfo wrapper.
The BSDLInfo wrapper specifying the ACCell property with a Yes value must have Function
equal to output3, output2, output2a, input or bidir.
Example
The following example illustrates this property:
BsdlInfo(1) {
Function: Output2;
CellInfo: BC_4;
ACCell: On;
}
ACSelectCell
The ACSelectCell property is used in BSDLInfo wrappers associated with AC output
boundary-scan cell to point to the optional internal boundary-scan cell that is used to enable the
output toggling of the AC output pins.
Syntax
where BSDLInfoLabel is the label of the BSDLInfo wrapper defining the internal boundary-
scan cell.
Default Value
None
.lvbscan Input File
ACMode
Usage Conditions
This property is used in the BScanSegment: BSDLInfo wrapper.
The following usage conditions apply to this property:
• The BSDLInfo wrapper is referenced by the ACSelectCell property must have Function
equal to Internal.
• The BSDLInfo wrapper specifying the ACSelectCell property must have Function
equal to output3, output2, output2a, or bidir.
Example
The following example illustrates this property:
BSDLInfo (1) {
Function: Output2;
CellInfo: AC_2;
ACSelectCell: 5;
}
BSDLInfo (5) {
Function: Internal;
CellInfo: AC_SELU;
SafeValue: 0;
}
...
ACMode
The ACMode property is used to define the pin name that carries the ACMode function. This
signal is an input on the AC pad cell and will be driven by the TAP. ACMode is driven high
during the AC output test (1149.6 instructions EXTEST_PULSE or EXTEST_TRAIN).
Syntax
ACMode: <PinName>;
where PinName is the name of the pin on the BScanCell.
Usage Conditions
Example
The following example defines the pin myACMode as the pin that carries the ACMode function.
ACMode: myACMode;
}
.lvbscan Input File
ACModeSel
ACModeSel
The ACModeSel property defines the pin name that enables the pad’s ACSignal input to invert
the output data of a dot6-compliant output or bidirectional pad. During ACMode operation, this
inversion occurs during the RunTestIdle state when both ACSignal and ACModeSel pad pins
are asserted high. The ACModeSel pin normally connects to the output of a dot6 ACSelect cell,
which exists in your design only if you specify an ACGroup wrapper in your ETAssemble
configuration file.
See “Differential Output Pad Example” in the Support for IEEE 1149.6 Boundary Scan
document. For more information about ACSelect cells and their interactions with dot6 pads, see
the IEEE 1149.6 standard.
Syntax
ACModeSel: <PinName>;
Usage Conditions
Example
The following example defines the pin myACModeSel on cell module MyCell:
ACModeSel: myACModeSel;
}
ACSignal
The ACSignal property is used to define the pin name that carries the ACSignal function. This
signal is an input on the ACCell and will be driven by the TAP. When high, the output pad
drives the inverted data contained in the boundary-scan register.
Syntax
ACSignal: <PinName>;
Usage Conditions
.lvbscan Input File
AuxIn
Example
The following example defines myACMode as the pin on the BScanCell that carries the
ACSignal function.
ACSignal: myACMode;
}
AuxIn
The AuxIn property lists pins that can be used to supply Auxiliary Input data such as ScanIn
data for Multi-Scan ATPG mode.
Syntax
AuxIn: <AuxInData>[, <AuxInEn>];
AuxInData might be a pin on the BScanCell or an internal pin within it. ETAssemble with
runtime option -flow EBScan will use the Pin: AuxIn property to point to the following:
• A primary output of the BScanCell for each pin specified in the ExternalAuxInPins
wrapper of the .etassemble file
• An internal pin for each pin specified in the InternalAuxInPins wrapper of the
.etassemble file
The presence of the AuxInEn pin is very rare and only happens when your pad cell includes the
SelectJTagInput multiplexer, and the fromPad output of the pad is not available. In such a case,
AuxInEn is used to force SelectJTAGInput to 1 when AuxInEn is high.
Default Value
None
Usage Conditions
This property is used in the BScanCell: Pin wrapper.
Example
This example documents a pin called A[7] equipped with an auxiliary input called AuxIn[0].
Pin (A[7]){
Function: PadIO;
AuxIn: AuxIn[0];
}
}
.lvbscan Input File
AuxOut
AuxOut
The AuxOut property lists pins that can be used to multiplex Auxiliary output data such as
ScanOut data for Multi-Scan ATPG mode.
Syntax
AuxOut: <AuxOutData>, <AuxOutEn> \

[<AuxOutData>, <AuxOutEn>];
AuxOutData might be a pin on the BScanCell or an internal pin within it. The ETAssemble
with runtime option -flow EBScan will use the Pin: AuxOut property to point to the following:
• A primary input of the BScanCell for each pin specified in the ExternalAuxOutPins
wrapper of the .etassemble file.
• An internal input pin for each pin specified in the InternalAuxOutPins wrapper of the
.etassemble file.
Default Value
None
Usage Conditions
Example
This example documents a pin called A[7] equipped with two AuxOut multiplexers, one sourced
by pin AuxOut[0], and another one sourced by the internal pin BGP/A_7_AuxOut1.
Pin (A[7]){
Function: PadIO;
AuxIn: AuxOut[0], AuxEn[0],\
BGP/A_7_AuxOut1, BGP/A_7_AuxEn1;
}
}
BSDLInfo
The BSDLInfo wrapper is used to provide the information needed to document a boundary-
scan register and its association to a pin or pins.
.lvbscan Input File
BScanCell
Syntax
Function: output2 | output2a | output3 | input | bidir |
control | internal | observe_only | clock;
Port: <PinName>;
ControlCell: <BSDLInfoLabel>;
ACCell: On | (Off);
SafeValue: (x) | 1 | 0;
}
where BSDLInfoID can be any arbitrary label but ETAssemble with -flow EBScan will use
integers from n-1 down to 0 to label the BSDLInfo wrapper. That way it matches the
BOUNDARY_REGISTER convention in the BSDL file where BOUNDARY_REGISTER[n-1]
is closest to TDI, and BOUNDARY_REGISTER[0] is closest to TDO.
Default Value
None
Usage Conditions
The BSDLInfo wrapper is used in the BScanSegment wrapper.
• Use one BSDLInfo per boundary-scan register.

• The order of the BSDLInfo registers represents the order of the boundary-scan segment
where the first BSDLInfo wrapper corresponds to the boundary-scan register closest to
TDI, and the bottom BSDLInfo wrapper corresponds to the boundary-scan register
closest to TDO.
BScanCell
The BScanCell wrapper is used to describe a module containing a boundary-scan segment with
one or more boundary-scan registers. A BScanCell module contains both the pads and the
associated boundary-scan registers stitched into a single boundary-scan chain.
.lvbscan Input File
BScanCell
Syntax
This wrapper contains the following syntax:
Pin (<portName>) {
<Function properties that list \
all function names>
}
<PortFunction>: <pinName>;
<Properties>
BSDLInfo (n) {
<Properties>
}
}
}
where cellName is the real module name of the boundary-scan cell.
Note that cellName might be a sub-physical region in which you have inserted a boundary-scan
segment using ETAssemble with -flow EBscan.
Default Value
None
Usage Conditions
The BScanCell wrapper is used in the main BScanCells wrapper and can be used multiple
times—one wrapper for each boundary-scan cell.
Example
The following syntax illustrates the main sections in the BScanCell wrapper in the .lvbscan file:
Pin (A[7:0]){
Function: PadIO;
}
Pin (Y[7:0]){
Function: PadIO;
}
// Function/Pin Map
// <FunctionName>: <pinName>
SelectJTagOutput: selectJtagOutput;
SelectJTagInput: selectJtagInput;
ForceDisable: forceDisable;
ClockBscan: clockBscan;
ShiftBscan2edge: shiftBscan2Edge;
UpdateBscan: updateBscan;
.lvbscan Input File
BScanSegment
BScanSegment (1){
BScanShiftIn: bscanShiftIn;
BScanShiftOut: bscanShiftOut;
BSDLInfo (EN_A){
Function: control;
CellInfo: BC_2;
DisableValue: 1;
}
BSDLInfo (A7){
Function: bidir;
CellInfo: LV_BC_7;
ControlCell: EN_A;
Port: A[7];
}
}
}
BScanSegment
The BScanSegment wrapper enables you to document the boundary-scan cells in your
boundary-scan cell.
Syntax
This wrapper has the following structure:
<portFunction>: <PinName>;
BSDLInfo (n) {
<Properties>
}
}
where bscanSegmentName is any arbitrary identifier.
Default Value
None
Usage Conditions
The BScanSegment wrapper is used in the main BScanCell wrapper.
.lvbscan Input File
BScanShiftIn
Example
The following syntax illustrates the main sections in the BScanSegment wrapper in the
.lvbscan file:
BScanSegment (1){
BSDLInfo (EN_A){
Function: control;
CellInfo: BC_2;
DisableValue: 1;
}
BSDLInfo (A7){
Function: bidir;
CellInfo: LV_BC_7;
ControlCell: EN_A;
Port: A[7];
}
}
BScanShiftIn
The BScanShiftIn property is used to define the pin name that carries the Bscan Scan-in
function.
Syntax
BScanShiftIn: <PinName>;
where PinName is the name of the pin on BScanCell with the function boundary scan Scan-in.
Usage Conditions
This property is used in the BScanCell: BScanSegment wrapper.
The BScanShiftin pin might be sampled on the rising or falling edge of TCK. The
BScanShiftInRetime property set to Yes documents that the BScanShiftin pin is sampled on the
falling edge of ClockBscan.
Example
The following example defines the pin myBScanSI as the pin used as the boundary scan Scan-in
function:
BSCanSegment (1) {
BScanShiftIn: myBScanSI;
}
.lvbscan Input File
BScanShiftInRetime
BScanShiftInRetime
The BScanShiftInRetime property specifies whether the BScanShiftIn pin is sampled on the
falling or the rising edge of ClockBscan.
Syntax
BScanShiftInRetime: (Yes) | No;
• Yes — BScanShiftIn is sampled on the falling edge of ClockBscan.

• No — BScanShiftIn is sampled on the rising edge of ClockBscan.
Default Value
Default is Yes.
Usage Conditions
Example
The following example defines the pin BScanSI as the pin used as the boundary scan Scan-in
function, and that this pin is sampled on the falling edge of ClockBscan:
BSCanSegment (1) {
BScanShiftIn: BScanSI;
BScanShiftinRetime: Yes;
}
BScanShiftOut
The BScanShiftOut property is used to define the pin name that carries the boundary-scan
Scan-out function.
Syntax
BScanShiftOut: <PinName>;
where PinName is the name of the pin on BScanCell with the function boundary-scan Scan-out.
Default Value
None
.lvbscan Input File
CellInfo
Usage Conditions
The BScanShiftOut pin is updated on the rising edge of ClockBscan.
Example
The following example defines the pin BScanSO as the pin used as the boundary-scan Scan-out
function:
BSCanSegment (1) {
BScanShiftOut: BScanSO;
}
}
CellInfo
The CellInfo property is used in these two wrappers:
• CellInfo in the BSDLInfo Wrapper

• CellInfo in the BScanCell Wrapper
Together, these two usages provide a flexible way to accurately describe your custom
boundary-scan cell’s capture behavior in the Tessent BoundaryScan-generated BSDL file so
that either ETVerify or a third-party boundary-scan tool can fully understand that behavior
when generating IO test patterns.
CellInfo in the BSDLInfo Wrapper

The BSDLInfo: CellInfo property value <CellTypeID> is a simple string that typically refers to
an 1149.1 standard cell type such as BC_1, BC_7, or AC_2. However, for a custom boundary-
scan cell, this property optionally refers to a new non-standard cell type that you can name and
define with the property CellInfo in the BScanCell Wrapper.
Syntax
}
where <CellTypeID> is a built-in boundary-scan cell type or a custom cell type that is defined
using the BScanCell: CellInfo property.
Default Value
None
.lvbscan Input File
CellInfo
Usage Conditions
The CellInfo property is used in the BScanSegment: BSDLInfo wrapper.
• The CellInfo property in the BSDLInfo wrapper can reference any of the following
built-in cell types: BC_0, BC_1, BC_2, BC_3, BC_4, BC_5, BC_6, BC_7, BC_8,
BC_9, BC_10, AC_SELX, AC_SELU, AC_1, AC_2, AC_3, AC_7, AC_8, AC_9,
AC_10, LV_BC_7.
• When referencing a non-built-in boundary-scan cell type, the BSDLInfo: CellInfo
property must reference a type defined with a BScanCell: CellInfo property. For an
example, see the “CellInfo in the BScanCell Wrapper” section.
Example
The following example associates the boundary-scan registers with the BSDL type BC_2:
BScanSegment (1) {
BSDLInfo (ID5) {
CellInfo: BC_2;
}
}
CellInfo in the BScanCell Wrapper

The BScanCell: CellInfo property value <CellTypeID> is a complex string that describes the
complete capture behavior of your custom boundary-scan cell.
Syntax
CellInfo (<CellTypeID>): <bsdlCellDefinition>;
}
• CellTypeID — is a label that can be referenced by the BSDLInfo: CellInfo property.

• bsdlCellDefinition — is a string constant that follows the BSDL CELL_INFO syntax.
See the “Example” section for more information.
Default Value
None
Usage Conditions
.lvbscan Input File
CellInfo
The string syntax must exactly match the CELL_INFO constant found inside the IEEE 1149.1
standard BSDL package files.
Example
This example shows how to use the BScanCell: CellInfo property.
The following is an example of the CELL_INFO definition that is copied directly from the
standard package file STD_1149_1_2001. This definition describes the capture behavior of the
BC_10 output boundary-scan cell, which is called “self-monitoring output cell.”
constant BC_10: CELL_INFO:=

((OUTPUT2, EXTEST, PO), (OUTPUT3, EXTEST, PO),
(OUTPUT2, SAMPLE, PO), (OUTPUT3, SAMPLE, PO));
From this definition, you know that:
• The cell captures its “Parallel Output” (PO), for both EXTEST and SAMPLE
instructions, when entering the CAPTURE-DR state, when the cell's function is output2
(connected to a 2-state buffer pin) or output3 (connected to a 3-state output pin).
• The cell does not support the optional “INTEST” TAP instruction because that
instruction is not mentioned.
• BC_10 is illegal for bidir, input, control, or observe_only cells.
The BSDL standard defines the possible CELL_INFO capture data sources as follows:
• PI (Parallel Output) — The core for an input cell. The chip pin for an output cell.
• PO (Parallel Output) — The core for an input cell. The chip pin for an output cell.
• X — Unknown value; this is typical in “internal” bscan cells.
• 0/1 — Fixed 0 or 1 logical value.
• UPD — The output from the cell's update stage (updateLatch in Tessent
BoundaryScan's generic boundary-scan cells).
For more information about the CELL_INFO functionality and syntax, see the IEEE 1149.1
standard.
.lvbscan Input File
CellInfo
Now let's say your custom embedded boundary-scan cell always captures its own update stage
for both EXTEST and SAMPLE modes, and the boundary-scan cell is connected to a three-state
pad buffer (output3) in its block netlist. You can specify the boundary-scan cell as follows:
BScanCell (my_cell) {
CellInfo (my_BC_type): " ((OUTPUT3, SAMPLE, UPD), (OUTPUT3, EXTEST,
UPD))";
BScanSegment (1){
BSDLInfo (ID5){
Function: output3;
CellInfo: my_BC_type;
Port: pTx1Pad;
ControlCell: cell71;
}
}
}
ETAssemble gathers all of the above custom CellInfo descriptions from all *.lvbscan files and
forwards them to the bottom of the LVS_BSCAN_CELLS output file in your specified -outDir
directory. For the above example, the tool adds the lines in red:
package LVS_BSCAN_CELLS is
use STD_1149_1_2001.all;
constant LV_BC_7: CELL_INFO;
constant my_BC_type: CELL_INFO;
end LVS_BSCAN_CELLS;
package body LVS_BSCAN_CELLS is
use STD_1149_1_2001.all;
constant LV_BC_7: CELL_INFO :=
((BIDIR_IN, EXTEST, PI), (BIDIR_OUT, EXTEST, PO),
(BIDIR_IN, SAMPLE, PI), (BIDIR_OUT, SAMPLE, PI),
(BIDIR_IN, INTEST, X), (BIDIR_OUT, INTEST, PI));
constant my_BC_type: CELL_INFO :=
((OUTPUT3, SAMPLE, UPD), (OUTPUT3, EXTEST, UPD));
end LVS_BSCAN_CELLS;
The following statement (in red) causes the LVS_BSCAN_CELLS package to be included in the
Tessent BoundaryScan-generated BSDL file:
entity <design> is
...
use STD_1149_1_2001.all;
use LVS_BSCAN_CELLS.all;
Important notes:
• ETVerify does not assume any hidden behavior or cell attribute for custom cells that
refer to standard BC_<type> strings such as BC_0, BC_1, BC_2, and so on. From
ETVerify's point of view, that string is used only as a cross-reference to the
corresponding CELL_INFO constant description in the IEEE 1149.1 standard packages.
.lvbscan Input File
ClockBscan
• If your custom boundary-scan cell's capture behavior happens to match one of the
standard IEEE 1149.1 cells' BC_<type>, you can specify that same type with the
BSDLInfo: CellInfo property without explicitly defining the same BC_<type> in your
.lvbscan file with the BScanCell: CellInfo property.
• The .lvbscan format does not directly support all custom boundary-scan cell
architectures. See the “Custom Boundary-Scan Cell Support Limitations and Solutions”
section in the LV Flow User’s Manual.
ClockBscan
The ClockBscan property is used to define the pin name that carries the ClockBScan function.
Syntax
ClockBscan: <PinName>;
where PinName is the name of the pin on BScanCell with the function ClockBscan.
Usage Conditions
Example
The following example defines the pin MyClkBScan as the pin used as the ClockBScan
function:
ClockBscan: MyClkBScan;
}
ControlCell
The ControlCell property enables you to associate an output3, or bidir boundary-scan cell with
a control (or enable) boundary-scan cell.
Syntax
ControlCell: <BSDLInfoID>;
where BSDLInfoID is the name of the BSDLInfo wrapper defining the control (or enable)
boundary-scan cell.
.lvbscan Input File
DifferentialType
Default Value
None
Usage Conditions
The ControlCell property is used in the BScanSegment: BSDLInfo wrapper.
You use this property within a BSDLInfo wrapper with Function: Output2, Output3, or Bidir:
• When the cell has function Output3 or Bidir, then the ControlCell property must point to
a the BSDLInfoID of a cell with function Control.
• When the cell has function Output2, then the ControlCell property must point to its own
BSDLInfoID. An Output2 cell uses the ControlCell property only when it drives an
open drain or an open source pad driver.
Example
This example describes the cell EN1 as the control cell of the bidirectional cell Y1.
BScanSegment (1){
BSDLInfo (Y1){
Function: bidir;
CellInfo: LV_BC_7;
ControlCell: EN_A;
Port: Y[1];
}
BSDLInfo (EN1){
Function: Control;
CellInfo: BC_2;
}
}
DifferentialType
The DifferentialType property enables you to document the differential type of your pad as
either voltage or current.
Syntax
DifferentialType: (voltage) | current;
• voltage — indicates that the cell operates using a differential voltage signal.
• current — indicates that the cell operates using a differential current signal.
.lvbscan Input File
DisableResult
Default Value
The default value is voltage.
Usage Conditions
The DifferentialType property is used in the BScanSegment: Pin wrapper.
This property is only relevant for Pin wrappers with a PinInv property.
Example
This example specifies that the pins A and AN form a differential current pin pair.
BScanSegment (1){
Pin (A) {
PinInv: AN;
DifferentialType: current;
}
}
DisableResult
The DisableResult property enables you to specify the state of the pin when the output buffer of
the pad is disabled.
Syntax
• Z — corresponds to floating.
• pull0 — identifies a boundary-scan cell pulled to ground using a resistor internal to the
device.
• pull1 — identifies a boundary-scan cell pulled to VDD using a resistor internal to the
device.
• weak0 — identifies a boundary-scan cell pulled to ground using a resistor external to the
device
• weak1 — identifies a boundary-scan cell pulled to VDD using a resistor external to the
device.
Default Value
The default value is Z.
.lvbscan Input File
DisableValue
Usage Conditions
The DisableResult property is used in the BScanSegment: BSDLInfo wrapper.
You use this property when the BSDL function is either output3 or bidir.
Example
The following example indicates that the boundary-scan cell goes to ground using a resistor
internal to the device when disabled.
BScanSegment (1){
BSDLInfo (8){
Function: bidir;
CellInfo: LV_BC_7;
ControlCell: EN1
DisableResult: pull0;
Port: A[7];
}
}
DisableValue
The DisableValue property specifies the value that disables the output of the tri-state pad
driver.
Syntax
• X — indicates an unknown value.

• 0 — indicates that a logic 0 disables the pad.
• 1 — indicates that a logic 1 disables the pad.
Default Value
The default value is X.
Usage Conditions
The DisableValue property is used in the BScanSegment: BSDLInfo wrapper.
You use this property when the BSDL function is output2, output3, or bidir.
Example
The follow example specifies that logic 0 disables the output of the pad.
.lvbscan Input File
ForceDisable
BScanSegment (1){
BSDLInfo (1){
Function: bidir;
CellInfo: LV_BC_7;
ControlCell: 4;
DisableValue: 0;
Port: A[7];
}
}
ForceDisable
The ForceDisable property is used to define the pin name that carries the ForceDisable
function.
Syntax
ForceDisable: <PinName>;
where PinName is the name of the pin on BScanCell with the function ForceDisable.
Usage Conditions
The ForceDisable property is used in the BScanCell wrapper.
Example
The following example defines the pin myForceDis as the pin used as the ForceDisable
function:
ForceDisable: myForceDis;
}
FromPad
The FromPad property is used to specify a pin name on the boundary-scan cell that is directly
controlled by the output pin of the input pad buffer.
Syntax
FromPad: <pinName>;
where pinName is the name of the pin of pin on the boundary-scan cell which is sourced by the
input pad buffer.
.lvbscan Input File
Function
Usage Conditions
Example
The following example defines A7_fromPad as the pin sourced by the input pad buffer
associated with pin A[7].
Pin (A[7]) {
FromPad: A7_fromPad;
}
}
Function
The Function property is used inside the following wrappers of the .lvbscan file and have
different syntax in each case:
• Function within the BSDLInfo wrapper

• Function within the Pin wrapper
Function within the BSDLInfo wrapper
The Function property is used within the BSDLInfo wrapper specifies which predefined
function the boundary-scan cell register has.
Syntax
Function: <FunctionName>;
where valid values for FunctionName are the following:
• output2 — A two-state output cell.

• output2a — An asymmetric two-state output cell. One state is the disabled state; the
possibilities are either 0 and Z or 1 and Z.
• output3 — A tri-state output cell.
• input — A control-and-observe cell for an input pin.
• bidir — A reversible cell for a bidirectional pin.
• control — An enable cell that controls an enable port of a tri-state pad cell or a direction
control port of a bidirectional.
• internal — A cell not associated with a device signal pin that captures constants 1, 0, or
X.
.lvbscan Input File
Function
• observe_only — An observe-only cell.

• clock — A cell used to pass a clock signal.
Default Value
None
Usage Conditions
The Function property is used in the BSDLInfo wrapper.
This property is mandatory.
Example
This example defines the function of a boundary-scan cell as a control cell.
BSDLInfo (EN_A){
Function: control;
CellInfo: BC_2;
DisableValue: 1;
}
Function within the Pin wrapper

The Function property used within the Pin wrapper specifies which pre-defined function the pin
has.
Syntax
Function: (padIO) | padIOInv;
• padIO — Pin on a pad cell that connect the device IO pins.

• padIOInv — The active low polarity pin used in a differential pin pair which connect the
device IO pins.
Default Value
The default value is padIO.
Usage Conditions
The Function property is used in the BScanCell: Pin wrapper.
The pin with the function PadIOInv needs to be referenced by a PinInv property found within a
Pin wrapper with the function PadIO.
.lvbscan Input File
InitClk
Example
This example defines A[7:0] and AN[7:0] as pairs of differential pins.
Pin (A[7:0]){
Function: PadIO;
PinInv: AN[7:0];
}
Pin (AN[7:0]){
Function: PadIOInv;
}
}
InitClk
The InitClk property is used to define the pin name that carries the InitClk function used by
1149.6 input pads. As defined in the 1149.6 standard, a pulse on InitClk initializes the hysteresis
memory of the input receiver to the value contained in its associated observe_only boundary-
scan cell.
Syntax
InitClk: <PinName>;
Usage Conditions
Example
The following example defines the pin myInitClk as the pin which carries the InitClk function
of the boundary-scan cell MyCell:
InitClk: myInitClk;
}
InitClkPolarity
The InitClkPolarity property is used to define the active state of the InitClk signal.
Syntax
InitClkPolarity: (RisignEdge) | FallingEdge |

Logic0 | Logic1;
.lvbscan Input File
Pin
• RisingEdge — specifies that InitClk is used to initialize test receiver memory elements
composed of positive-edge triggered flip-flops.
• FallingEdge — specifies that InitClk is used to initialize test receiver memory elements
composed of negative-edge triggered flip-flop.
• Logic0 — specifies that InitClk is used to initialize test receiver memory elements
composed of latches enabled with a logic zero value.
• Logic1 — specifies that InitClk is used to initialize test receiver memory elements
composed of latches enabled with a logic one value.
Default Value
The default value is RisingEdge.
Usage Conditions
• When ETAssemble is run in -flow EBscan, it writes out the InitClkPolarity with the
value that was specified using the TestReceiverInitClkPinAssert property in the
.etassemble file.
• When ETAssemble runs on a level of hierarchy that contains child BScanCell defined in
.lvbscan files, it verifies that the read in InitClkPolarity values is consistent with the
specified TestReceiverInitClkPinAssert value. Currently, ETAssemble only supports
one InitClkPolarity value for the entire device. This restriction will be removed in a
later release by allowing the InitClkPolarity to be specified in the Pad Library Input
File on a per pad basic.
Example
The following example defines that the InitClk pin called myInitClk is driving test receivers
with memory elements composed of latches enabled with a logic zero value:
InitClk: myInitClk;
InitClkPolarity: Logic0;
}
Pin
The Pin wrapper is used to document pin on BScanCell which connects to the device IO pins.
.lvbscan Input File
PinInv
Syntax
Pin (<pinName>) {
<Properties>
}
where pinName is the name of the pin on BScanCell.
Usage Conditions
The Pin wrapper is used in the BScanCell wrapper.
You must list all pins which connect to device IO pins in the Pin wrapper.
Example
The following example illustrates the Pin wrapper:
Pin (ABC[5]) {
Function: PadIO;
}
PinInv
The PortInv property enables to associate a negative pin to a positive pin when they form a
differential pin pair.
Syntax
Pin (<pinName>) {
PInInv: <pinName>;
}
Default Value
None
Usage Conditions
The PinInv property is used in the BScanCell: Pin wrapper.
The pin referenced by the PinInv property must be defined within a Pin wrapper with Function
PadIOInv.
Example
This example defines A[7:0] and AN[7:0] as pairs of differential pins.
.lvbscan Input File
Port
Pin (A[7:0]){
Function: PadIO;
PinInv: AN[7:0];
}
Pin (AN[7:0]){
Function: PadIOInv;
}
}
Port
The Port property is used within the BSDLInfo wrapper to associate a boundary-scan register to
a pin.
Syntax
BSDLInfo(<BSDLInfoID>) {
Port: <pinName>;
}
Default Value
None
Usage Conditions
This property is used in the BScanSegment: BSDLInfo wrapper.
The pin referenced by the Port property must be defined within a Pin wrapper with Function
PadIO.
Example
This example associates BSDLInfo (4) wrapper with the pin A[7].
Pin(A[7:0]) {
Function: PadIO;
}
BSDLInfo (4){
Port: A[7];
}
SafeValue
The SafeValue property document the safe data value associated to a boundary-scan register.
This value is forwarded into the BSDL file and is used when the chip is integrated into a target
system.
.lvbscan Input File
SelectJTagInput
Syntax
• X — indicates an unknown or don’t care value.

• 0 — indicates that a logic 0 is the safe value for this register
• 1 — indicates that a logic 1 is the safe value for this register.
Default Value
The default value is X.
Usage Conditions
The SafeValue property is used in the BScanSegment: BSDLInfo wrapper.
Example
The following example specifies that a logic 0 is the safe value for the register A7.
BScanSegment (1){
BSDLInfo (A7){
Function: bidir;
CellInfo: LV_BC_7;
SafeValue: 0;
}
}
SelectJTagInput
The SelectJTagInput property is used to define the pin name that carries the SelectJTagInput
function.
Syntax
SelectJTagInput: <PinName>;
where PinName is the name of the pin on BScanCell with the function SelectJTagInput.
Usage Conditions
The SelectJTagInput property is used in the BScanCell wrapper.
.lvbscan Input File
SelectJTagOutput
Example
The following example defines the pin SJI as the pin used as the SelectJTagInput function:
SelectJTagInput: SJI;
}
SelectJTagOutput
The SelectJTagOutput property is used to define the pin name that carries the
SelectJTagOutput function.
Syntax
SelectJTagOutput: <PinName>;
where PinName is the name of the pin on BScanCell with the function SelectJTagOutput.
Usage Conditions
The SelectJTagOutput property is used in the BScanCell wrapper.
Example
The following example defines the pin SJO as the pin used as the SelectJTagOutput function:
SelectJTagOutput: SJO;
}
ShiftBScan
The ShiftBscan property is used to define the pin name that carries the ShiftBscan function.
Syntax
ShiftBscan: <PinName>;
where PinName is the name of the pin on BScanCell with the function ShiftBscan.
Usage Conditions
The ShiftBscan property is used in the BScanCell wrapper.
.lvbscan Input File
ShiftBScan2Edge
The ShiftBScan function differs from the ShiftBScan2Edge function in its timing:
• ShiftBscan transitions on the falling edge of TCK and is meant to be used as ShiftEn of
an active high boundary-scan register.
• ShiftBscan2Edge transitions on the rising edge of TCK and is meant to be used as
ShiftEn of an active low boundary-scan register. Siemens EDA uses both a negedge and
a posedge flip-flop in each boundary-scan register to make sure that clock skew in the
boundary-scan clock distribution will never affect the shift ability of the boundary-scan
chain. The scan multiplexer is in front of the negative edge flip-flop which is why
ShiftBscan2Edge is used when describing a Siemens EDA boundary-scan cell.
Example
The following example defines the pin MyBScanSE as the pin used as the ShiftBScan function:
ShiftBscan: MyBScanSE;
}
ShiftBScan2Edge
The ShiftBscan2Edge property is used to define the pin name that carries the ShiftBscan2Edge
function.
Syntax
ShiftBscan2Edge: <PinName>;
where PinName is the name of the pin on BScanCell with the function ShiftBscan2Edge.
Usage Conditions
The ShiftBscan2Edge property is used in the BScanCell wrapper.
The ShiftBScan2Edge function differs from the ShiftBScan function in its timing:
• ShiftBscan transitions on the falling edge of TCK and is meant to be used as ShiftEn of
an active high boundary-scan register.
• ShiftBscan2Edge transitions on the rising edge of TCK and is meant to be used as
ShiftEn of an active low boundary-scan register. Siemens EDA uses both a negedge and
a posedge flip-flop in each boundary-scan register to make sure that clock skew in the
boundary-scan clock distribution will never affect the shift ability of the boundary-scan
chain. The scan multiplexer is in front of the negative edge flip-flop which is why
ShiftBscan2Edge is used when describing a Siemens EDA boundary-scan cell.
.lvbscan Input File
UpdateBscan
Example
The following example defines the pin MyBScanSE as the pin used as the ShiftBscan2Edge
function:
ShiftBscan2Edge: MyBScanSE;
}
UpdateBscan
The UpdateBscan property is used to define the pin name that carries the UpdateBScan
function.
Syntax
UpdateBscan: <PinName>;
where PinName is the name of the pin on BScanCell with the function UpdateBscan.
Usage Conditions
The UpdateBscan property is used in the BScanCell wrapper.
Example
The following example defines the pin MyUpdBScan as the pin used as the UpdateBScan
function:
UpdateBscan: MyUpdBScan;
}
Chapter 6
Pad Library
This chapter describes the pad library files for ETAssemble. Most input files described here are
optional; however, the design netlist, cell library and pad library files are required input to
ETAssemble. You run ETAssemble with the LV Flow.
Pad Library Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

ACTiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
BlibCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
DefaultBcells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
PadAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
PadLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Pad Library
Pad Library Input File
Pad Library Input File

The pad library file, pad.library, serves as input to the ETAssemble tool. The .padlibrary file
describes the I/O pads or their components and describes how these components connect to each
other. This information is used by ETAssemble to identify where to insert specified boundary-
scan cells in the design.
A pad library file targeted to your technology must exist. Create this file if your ASIC vendor
does not have a pad library for your technology, or if you are an ASIC vendor creating a pad
library.
Figure 6-1 illustrates the syntax of the pad library file.
Figure 6-1. Syntax Summary of the Pad Library File
PadLibrary (<padLibName>) {
Cell(<cellName>) {
PadAttribute: AC;
BlibCell: <cellName>;
Usage {//You can omit this wrapper if the pad cell has only one
// usage mode. However, you must include the Pin
// wrappers in the Cell wrapper.
PadAttribute: AC;
Pin (<pinName>) {
[Function: <functionType>] | [Condition: <conditionType>];
Attribute: <attrType>;
}
Pin (<pinName>) {
}
}
ACTiming {
LP_time: <time in seconds>;
HP_time: <time in seconds>;
HP_onChip: Yes | (No);
}
}
DefaultBcells {
<bcellName: <class/Subclass>;
}
}
The following sections provide detailed information on the available wrappers and properties of
the pad.library file.
ACTiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
BlibCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Pad Library
ACTiming
DefaultBcells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
PadAttribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
PadLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
ACTiming
The optional ACTiming wrapper specifies the AC-input timing requirements of an AC input or
bidirectional pad.
Syntax
ACTiming {
LP_time: <time in seconds>;
HP_time: <time in seconds>;
HP_onChip: Yes | (No);
}
where the above syntax represents the following:
• time in seconds—specifies real number expressed with an exponent—for example: 1.0e-

7, 4.73e-08.
• LP_time — specifies the Low Pass time constant in seconds.
• HP_time — specifies the High Pass time constant in seconds.
• HP_onChip — indicates that the coupling capacitor is embedded within the pad.
Default Value
None
Usage Conditions
The ACTiming wrapper can be specified at the Usage wrapper level in addition to the Cell
wrapper level:
• If specified at the Usage wrapper level, it apples only to that Usage wrapper.
• If specified at the Cell wrapper level, it applies to all Usage wrappers in the Cell
wrapper.
Pad Library
ACTiming
ETAssemble uses the information in the ACTiming wrapper to create the AIO_Pin_Behavior
attribute in the .bsdl file. Based on the IEEE 1149.6 standard section 7.5.4.2, you must specify
the LP_time or the HP_time, or both LP_time and HP_time.
The following rules must be followed while specifying the LP_time or HP_time:
• Specify LP_time only when your pad has input test receivers with an embedded low-
pass filter. Such a low-pass filter is always on-chip and requires an acMode control pin
in its pad library description.
• Embedded high-pass and low-pass filters cannot coexist on the same pad; therefore, you
cannot specify LP_time along with HP_onChip: Yes. However, you can specify LP_time
and HP_time when the HP filter is not on-chip.
• When there is no on-chip LP or HP filter, you must specify the HP_time in order to
provide guidelines for the board designer or the test engineering while creating the
loadboard. ETAssemble will only forward this information only to the .bsdl file.
Example
Examples of the AC pads are provided below.
Pad Library
ACTiming
This example illustrates a description of an AC 1149.6-compatible differential voltage (DV)

input in the pad.library file:
Cell(myAC_Rx) {
PadAttribute: AC;
Pin(P) {
Function: padIO;
Attribute: DV;
}
Pin(PI) {
Function: padIOInv;
}
Pin(Y) {
Function: fromPad;
}
// Pin functions for IEEE 1149.6 input receivers

Pin(ID) {
Function: InitData;
}
Pin(IDI) {
Function: InitDataInv;
}
Pin(ICK) {
Function: InitClk;
}
Pin(TD) {
Function: TestData;
}
Pin(TDI) {
Function: TestDataInv;
}
ACTiming {
HP_time: 1.5e-8;
}
}
AC Output Pad Example

This example illustrates a description of an AC 1149.6-compatible differential voltage (DV)
output pad in the pad.library file.
Pad Library
ACTiming
Cell(myAC_Tx) {
PadAttribute: AC;
Pin(P) {
Function: padIO;
Attribute: DV;
}
Pin(PI) {
Function: padIOInv;
}
Pin(A) {
Function: toPad;
}
Pin(GZ) {
Function: enableLow;
}
}
AC Output Pad with Embedded Output Test Mux Example

This example illustrates a description of an AC 1149.6-compatible differential current output
pad with an embedded output test mux. This output pad must specify the list of SJOMux pin
functions.
Cell(myAC_Tx) {
PadAttribute: AC;
Pin(P) {
Function: padIO;
Attribute: DC;
}
Pin(PI) {
Function: padIOInv;
}
Pin(A) {
Function: toPad;
}
Pin(GZ) {
}
Pin(TI) {
Function: toSJOMux;
}
Pin(TO) {
Function: fromSJOMux;
}
Pin(SJO) {
Function: SelectJTagOutput;
}
}
The enable pin for these output pads can be active-low or active-high.
AC Inout Pad Example

The AC inout pad simply combines pin functions from both above input-only and output-only
AC pads.
Pad Library
Attribute
Cell(myAC_IO)
PadAttribute: AC;
Pin(P) {
Function: padIO;
Attribute: DV;
}
Pin(PI) {
Function: padIOInv;
}
Pin(A) {
Function: toPad;
}
Pin(GZ) {
}
Pin(Y) {
Function: fromPad;
}
// Pin functions for IEEE 1149.6 input receivers
Pin(ID) {
Function: InitData;
}
Pin(IDI) {
Function: InitDataInv;
}
Pin(ICK) {
Function: InitClk;
}
Pin(TD) {
Function: TestData;
}
Pin(TDI) {
Function: TestDataInv;
}
Pin(ACM) {
Function: ACMode;
}
ACTiming {
LP_time: 0.75e-8;
HP_time: 1.5e-8;
}
}
Attribute
The Attribute property conveys extra information to ETAssemble about a particular cell pin or
the pad connected to the cell pin. Some of these attributes influence the selection of the type of
boundary-scan cell that must be generated for the pad, such as sampleOnly. Note that only the
inverted and parametric attribute types characterize a specific cell pin.
Pad Library
Attribute
Syntax
where attrType describes the pre-defined attributes of a pin. The following table lists the valid
values and their significance.
Table 6-1. Valid Values for the Attribute Property
Attribute Type Description
sampleOnly Specifies that a sample-only boundary-scan cell is to be generated for this
pad.
nonJTAG Specifies that pad is a non-JTAG pad and no boundary-scan cell is to be
generated for this pad.
inverted Specifies that data on this pin is inverted. This attribute is applicable only
for cell pins with either fromPad or toPad functions.
DV, DC Specifies that the pad is a differential voltage or differential current type
cell.
openDrain, Specifies that the output pad is an open drain or open source type.
openSource
pull0, pull1 Specifies that a tri-state bidirectional or output pad is pulled to ground or
to VDD using a resistor internal to the device.
The effect of specifying a pull0 or pull1 attribute on a pad is two-fold:
In the BSDL file generated by ETAssemble, the DisableResult value
corresponding to the pin associated with this pad is pull0 or pull1.
During the TAP simulation, the Output test algorithm compares the output
of the pin with a strong logic 0 or logic 1.
Default Value
None
Usage Conditions
The Attribute property is used in the Pin wrapper.
Pad Library
Attribute
Example
The example below illustrates four definitions of I/O cells using the Attribute property syntax:
Cell (InvInPad) {
Pin(A) {
Function: padIO;
}
Pin(Y) {
Function: fromPad;
Attribute: inverted;
}
}
Cell (sampleOnlyInPad) {
Pin(A) {
Function: padIO;
Attribute: sampleOnly;
}
Pin(Y) {
Function: fromPad;
}
}
Cell (njtagOutPad) {
Pin(Y) {
Function: padIO;
Attribute: nonJTAG;
}
Pin(A) {
Function: toPad;
}
Pin(G) {
Function: enableHigh;
}
}
Cell (DVInoutPad) {
Pin(P) {
Function: padIO;
Attribute: DV;
}
Pin(PI) {
Function: PadIOInv;
}
Pin(Y) {
Function: fromPad;
}
Pin(A) {
Function: toPad;
}
Pin(GZ) {
}
}
Pad Library
BlibCell
BlibCell
The BlibCell property specifies a pre-existing embedded pad or boundary-scan cell.
Syntax
Cell (<cellName>) {
BlibCell: <cellName>;
}
where cellName is any valid name of the pre-existing embedded pad/ boundary-scan cell.
Default Value
None
Usage Conditions
The BlibCell property is used in the Cell wrapper.
The cellName specified with this property must be described in a .lvbscan file. For more
information about this file, refer to .lvbscan Input File.
Example
In the following example, the blibCell is defined as ComboOut.
Cell(ComboOut) {
BlibCell: ComboOut;
Pin(pad) {
Function: toIO;
}
}
Cell
The Cell wrapper contains one or more Usage wrappers, which, in turn, contain one or more Pin
wrappers.
Pad Library
Cell
Syntax
The syntax for the Cell wrapper uses the following format:
PadLibrary (<padLibName>) {
Cell (<cellName>) {
PadAttribute: AC;
BlibCell: <.blibName>;
Usage {
PadAttribute: AC;
Pin (<pinName>) {
}
}
}
}
• padLibName — is any valid operating system character string.

• cellName — is any valid Verilog or VHDL identifier. The cellName represents a module
(typically, an I/O pad) in your design. The cellName is used to reference that cell in the
input netlist that you provide to ETAssemble.
• .blibName — an arbitrary label referencing the “cell (<name>)” entry in the .blib file.
Typically it is the same as <cellName> for ease of association.
• AC specifies the AC subclass.
Default Value
None
Usage Conditions
The Cell wrapper is used in the PadLibrary wrapper.
You can refer to a family of cells that share the same pin functions by using a special escaped
expression for cellName. The syntax of the escaped expression is:
\<alphaNumeric>(<choiceList>)[<choiceList>]<alpha>
where expression values are as follows:
• The leading backslash (\) is required in accordance with the Verilog escaped-name
syntax rules.
• The name can start with zero or more alpha-numeric characters—for example, 3BD.
• The name can contain a required list of choices enclosed in parentheses (). The
choiceList is a comma separated list of alpha-numeric characters included one or more
times to form the cell names—for example, (4,6).
Pad Library
Cell
• The name can also contain an optional list of choices enclosed in braces []. The
choiceList is a comma separated list of alpha-numeric characters included zero or more
times to form the cell name—for example, [Pu, PD].
• The name can end with zero or more alpha-numeric characters—for example, RFSR.
• The trailing space at the end of the escaped name is required in accordance with the
Verilog escaped-name syntax rules.
The PadAttribute property can be specified at the Usage wrapper level in addition to the Cell
wrapper level:
• If specified at the Usage wrapper level, it apples only to that Usage wrapper.
• If specified at the Cell wrapper level, it applies to all Usage wrappers in the Cell
wrapper.
The Cell wrapper’s pin functions for the AC-mode pads are as follows:
• Group1: InitData, InitClk, TestData — This group is mandatory for all single-ended
and differential input AC pads, and all single-ended and differential bidirectional AC
pads.
• Group2: InitDataInv, TestDataInv — This group is mandatory for differential input
and bidirectional AC pads.
• ACMode — This mode is optional. When this mode is present, ETAssemble adds the
ACM subclass to the pad.
ETAssemble determines that if one pin function of either group1 or group2 is present, then all
other functions of the same group must be present too. The presence of any one of these
functions requires that the PadAttribute property is set to AC.
Note
There is no difference in the list of pin functions between an output-only AC pad and a
normal output-only pad.
Example
The following example indicates that the cellName specification
\3BD(4,6)[PU,PD]RFDR
applies to the following cells:
• 3BD4RFDR
• 3BD6RFDR
• 3BD4PURFDR
Pad Library
Condition
• 3BD6PURFDR
• 3BD4PDRFDR
• 3BD6PDRFDR
Condition
The Condition property forces ETAssemble to select the given Usage wrapper if the pad’s port
connections satisfy the Condition(s) specified in that Usage wrapper. This can affect how
ETAssemble views the pad for boundary-scan insertion.
Syntax
Condition: tiedHigh | tiedLow | open;
• tiedHigh — specifies the pin as tied to high in the netlist.

• tiedLow — specifies the pin as tied to low in the netlist.
• open — specifies the pin as unconnected in the netlist.
Default Value
None
Usage Conditions
The Condition property is used in the Cell:Usage:Pin wrapper.
• The Condition property and the Function property are mutually exclusive.
• The Condition property is useful only if more than one Usage wrapper is specified
inside the Cell wrapper. The pin descriptions and attributes in the selected Usage
wrapper can be used to infer some of the pad cell’s properties such as its direction
(input, output, inout), its output driver type (open-drain, open-source, tri-state), or its
associated pre-existing embedded pad or boundary-scan cell as specified with the
BlibCell property.
Example
• The following example tells ETAssemble how a bidirectional pad cell connected to a
top-level inout pin is being used in functional mode: as an input-only, an output-only, or
an actual bidirectional pin.
Pad Library
Condition
The pad description in the example is useful only in designs where all chip pads are
bidirectional and are connected to an inout port in the netlist. ETAssemble, by default,
always infers boundary-scan cells that match the direction of the netlist’s top-level pin to
which the pad is connected. Therefore, you would want to force ETAssemble to use one
of the three Usage wrappers in the following example to change that behavior and select
boundary-scan cells of the same direction as their functional usage in the design. In the
example:
o If the pad is instantiated in the netlist with nets connected to the PAD, CIN, DOUT,
and OEB ports, then the pad is considered to be bidirectional.
o If the pad is instantiated in the netlist with nets connected to the PAD and CIN ports,
the DOUT port is connected to 1'b0, and the OEB port is connected to 1'b1, then the
pad is considered to be input-only.
o If the pad is instantiated in the netlist with nets connected to the PAD, DOUT, and
OEB ports, and the CIN port is left unconnected, then the pad is considered to be
output-only.
Note
See the FIN and FOUT .pinorder file options for more discussion on port
direction, pad type, and boundary-scan cell inferred direction.
Pad Library
Condition
Cell (myBidirPad) {
Usage { // bidir; the pad has a padIO, enable, toPad, and
fromPad pins
Pin (PAD) {
Function: padIO ; // notice "padIO"
}
Pin (CIN) {
Function: fromPad;
}
Pin (DOUT) {
Function: toPad; }
Pin (OEB) {
Function: enableLow; // Output-Enable, active-low
}
}
Usage { // input-only; the pad's enable is deasserted, and
its toPad
// is tied low
Pin (PAD) {
Function: fromIO; // notice "fromIO"
}
Pin (CIN) {
Function: fromPad;
}
Pin (DOUT) {
Condition: tiedLow; // DOUT not used in netlist
(connected to
// 1'b0)
}
Pin (OEB) {
Condition: tiedHigh; // OEB is deasserted in
netlist(connected
// to 1'b1)
}
}
Usage { // output-only; the CIN pin is not connected to the
core
Pin (PAD) {
Function: toIO; // notice "toIO"
}
Pin (CIN) {
Condition: open; // CIN pin is not connected in netlist
}
Pin (DOUT) {
Function: toPad;
}
Pin (OEB) {
}
}
}
Pad Library
DefaultBcells
Note
Important Limitation: ETAssemble can only recognize tied-off pins if they are
connected to HDL-level constants such as 1'b0 or 1'b1. That excludes pad pins
connected to a named net, regardless of whether the net is tied off by an assign
statement, some combinational logic output, or a library tie-off cell.
DefaultBcells
The DefaultBcells wrapper identifies the custom boundary-scan cells used in a design and their
correspondence to Siemens EDA pad cells. Siemens EDA provides a set of pre-defined pad
cells classes that are identified using a class/subclass mechanism. The specified boundary-scan
cells are instantiated when a corresponding pad cell is located in the input netlist.
Syntax
The following syntax specifies the DefaultBcells wrapper:
DefaultBcells {
<BcellName1>: <class/subclass>;
<BcellName2>: <class/subclass>;
....
}
}
• BcellName is any valid Verilog or VHDL identifier. BcellName represents a boundary-

scan cell in your cell library. The cellName is used to instantiate a cell of the same name
as the boundary-scan cell when ETAssemble needs to generate a cell with the matching
class/subclass identifier.
• class/subclass identifier is any valid pad class/subclass combination as defined by
Siemens EDA. The following two tables describe the class attributes for pad cells and
the subclass attributes for pad cells, respectively.
Table 6-2. Pad Cell Class Attributes

Class Attribute Description
I Input cells
O Output cells
EN Enable cells
IO Bidirectional cells
Pad Library
DefaultBcells
Table 6-3. Pad Cell Subclass Attributes

SubClass Description
Attribute
M Mux. The 2:1 mux controlled by selectJtagInput/Output is inside the pad cell
(and hence the boundary scan cell should not have one)
2 2-state output or bidirectional pad.
DC, DV Differential current (DC) or Differential Voltage (DV) pads.
FD Has a forceDisable input pin.
P0 Output that has an internal pull0 resistor.
P1 Output that has an internal pull1 resistor.
AC, ACM, Apply to dot6 pads:
NFP AC — a 1149.6 compatible pad.
ACM — has an ACMode input pin.
NFP — has fromPad output pin.
II Inverted input pad on the functional path. A pad that inverts its signal has to
have a matching bcell.
IO Inverted output pad on the functional path. A pad that inverts its signal has to
have a matching bcell.
S Use sample-only boundary-scan cell.
MO Muxed output for IO class. The pad only has the SJO (selectJtagOutput) mux.
NJ Pad forces a non-JTAG pin, i.e., has no boundary-scan cell.
0 Default. For enable cells which control active low output pads.
1 For enable cells which control active high output pads.
DI, DO For bidirectional cells which have disabled input or disabled output functional
paths.
The DI and DO subclasses are automatically inferred by ETAssemble. Do not
manually add these subclasses using the BoundaryScan: Overrides wrapper in
the .etassemble configuration file. Otherwise, ETAssemble issues an error
message.
OD, OS For output pads that are open drain or open source cells.
SP Pad has a samplePad output port, which carries a buffered copy of the
functional input signal that goes to the core.
NJ Pad forces a non-Jtag pin, i.e., has no boundary-scan cell.
Pad Library
Function
You use the following syntax for class/subclass identifiers:
Class Attribute (Subclass Attribute1, Subclass Attribute2,...Subclass

Attributed)
Sample Syntax for Output Pad Cell

The syntax below indicates how to specify a two-state pad cell which is bidirectional and
includes the SelectJtagOutput (SJO) mux.
O (2,B,M)
The above pad class should connect to an output boundary-scan cell that does not include the
SJO multiplexer.
The following table displays the available subclasses for each pad cell class. The symbol ·
means that you can use the subclass with the applicable class.
Table 6-4. Available Subclasses for Each Pad Cell Class
Class M 2 DC DV II IO S DI DO OD OS MO 0 1 FD F0/1
I · · · · ·
O · · · · · · · · ·
IO · · · · · · · · · · · · · ·
EN · ·
Usage Conditions
The DefaultsBCell wrapper is used in the PadLibrary wrapper.
Example
The following is an example specification of a mapping between the custom boundary-scan
cells and Siemens EDA-defined boundary-scan cells in the pad library file.
DefaultBcells {
myEnableCell: EN(1);
myInputBCell: I;
myOutput2BCell: O(2);
}
Function
The Function property specifies the logical function of the pin. ETAssemble extracts the design
information from the input netlist by using the function information to identify ports of an I/O
cell. The nets connecting to these ports are then traced to identify the connection between the I/
O cells and the core module.
Pad Library
Function
Syntax
Function: <functionType>;
where functionType describes the pre-defined function type of a pin. The following table
describes pre-defined function types that are allowed values for the Function property:
Table 6-5. Pre-Defined Function Types in the Pin Wrapper
Function Type Description
forceDisable Disables the output driver when it is set to 1. Usually, this pin is
directly connected to the ForceDisable signal of the TAP. The
forceDisable function does not support an active-low polarity or a pre-
existing connection.
fromPad, toPad Input/Output connections from/to a pad and the core module.
Typically, these connections are intercepted and the boundary scan
cells are inserted.
samplePad Specifies that the pin is a test-only buffered copy of the fromPad
output pin. While the fromPad pin always carries the functional data to
the core, the samplePad pin reports the top-level pin state to the
boundary-scan cells or to any other embedded test structure without
disturbing the functional path timing.
enableHigh, enableLow Identify the active high or active low enable pins for bidirectional or
output pads.
fromSJEMux Specifies the output of the SJEMux and provides feedback to the
boundary-scan enable (EN) cell.
toSJEMuxLow, Specify the test enable signal from the boundary-scan EN cell.
toSJEMuxHigh
toSJIMux, fromSJIMux, Specify the output/input on the pad cells that are connected to the
toSJOMux, fromSJOMux Select JTAG Input (SJI) or output (SJO) multiplexer.
selectJtagEnable Specifies the connection for the SJEMux control signal, usually
connected directly to the selectJtagOutput pin of the TAP, except
when the pin is specified as an auxiliary output pin.
selectJtagInput, Specify the connection for the control signal, usually coming from the
selectJtagOutput TAP controller, which controls the updating of the boundary-scan
cell’s internal register.
fromIO Specifies the input connection from an input or inout top pin to its pad.
If the pad description has this cell pin function but neither toIO nor
padIO cell pin function, then the BSDL top pin direction will be forced
to input even if the direction of the associated top pin is inout.
Pad Library
Function
Table 6-5. Pre-Defined Function Types in the Pin Wrapper (cont.)

Function Type Description
toIO Specifies the output connection from an output or inout top pin to its
pad. If the pad description has this cell pin function but neither fromIO
nor padIO cell pin function, then the BSDL top pin direction will be
forced to output even if the direction of the associated top pin is inout.
padIO Specifies the input/output connection from a top pin to its pad. The top
pin can be any direction.
padIOInv Specifies the input/output connection from the second top pin of a
differential pin pair to its (differential) pad.
fromIOInv Specifies the input connection from the second top pin of a differential
pin pair which direction is input or inout to its (differential) pad.
toIOInv Specifies the output connection from the second top pin of a
differential pin pair whose direction is output or inout to its
(differential) pad.
parametric Specifies that the cell pin is used for parametric test.
DOT6-Related functions: Group1: InitData, InitClk, TestData—This group is mandatory for
all input and bidirectional AC pads.
Group2: InitDataInv, TestDataInv—This group is mandatory for
differential input and bidirectional AC pads.
ACMode—This mode is optional. When this mode is present,
ETAssemble adds the ACM subclass to the pad.
For details, refer to the section Pad Library File in Support for IEEE
1149.6 Boundary Scan.
Default Value
None
Usage Conditions
The Function property is used in the Pin wrapper.
• The Function property and Condition property are mutually exclusive.

• While the pre-defined function types are useful in identifying the inputs and outputs of
the pad cells, user-defined functions can be used to identify intermediate connections
between a pad cell and the I/O pin. In such cases, use an arbitrary character string to
identify the function type, as long as that function type is used by both an input pin and
an output pin of different cells, thus forming a connection between the two.
Pad Library
Function
Example
The following examples show cell definitions using the Function property syntax:
Cell (muxOutPad) {
Pin(A) {
Function: fromIO;
}
Pin(B) {
Function: toSJOMux;
}
Pin(S) {
Function: selectJtagOutput;
}
}
Cell (sampleInPad) {
Pin(A) {
Function: padIO;
}
Pin(Y) {
Function: fromPad;
}
Pin(S) {
Function: samplePad;
}
}
Figure 6-2 shows an example where the function types, including user-defined types, are used.
In this figure, the pre-defined function types are in bold, and the user-defined type is in bold-
italics.
Figure 6-2. Example Connections and Function Types
Pad Library
PadAttribute
PadAttribute
The PadAttribute property specifies the AC subclass.
Syntax
PadAttribute: AC;
Usage Conditions
The PadAttribute property is used in the following wrappers:
• This property must be present in the Cell wrapper for all AC pads.
• This property can be specified at the Usage wrapper level in addition to the Cell wrapper
level:
o If specified at the Usage wrapper level, it apples only to that Usage wrapper.
o If specified at the Cell wrapper level, it applies to all Usage wrappers in the Cell
wrapper.
PadLibrary
The PadLibrary wrapper is the top-level wrapper of a pad library file. All cell definitions are
included within the PadLibrary wrapper.
Syntax
The complete syntax for this top wrapper is shown in Figure 6-1 on page 374.
Note that padLibName is any arbitrary character string. The padLibName string is not used by
ETAssemble; however, you can use padLibName to reflect your vendor technology.
Pin
The Pin wrapper describes the functionality of the pins of a pad cell.
Syntax
The syntax for a Pin wrapper uses the following format:
Pin (<pinName>) {
}
Pad Library
Usage
where pinName is any valid Verilog or VHDL identifier. The pinName represents a pin or port
of the pad cell. The pinName is specific to a pad cell and should not be confused with a signal
name in the netlist.
Default Value
None
Usage Conditions
The Pin wrapper is used in the PadLibrary: Cell: Usage wrapper.
For each pin of a pad cell, include a separate Pin wrapper.
Example
The example below describes pin Y of the pad cell diffInPad:
Cell (diffInPad) {
Usage {
Pin (Y) {
Function: fromPad;
Attribute: DC;
}
}
}
Usage
The Usage wrapper contains the pin definitions for different usage modes of the pad cell.
Syntax
Usage {
PadAttribute: AC;
Pin(<pinName>) {
}
}
where the Usage wrapper specifies the functionality of the pins on a pad cell.
Default Value
None
Usage Condition
This wrapper is used in the Cell wrapper.
Pad Library
Usage
• You can include multiple Usage wrappers in the Cell wrapper.

• You can omit the Usage wrapper if the pad cell has only one usage mode. However, you
must include the Pin wrappers in the Cell wrapper.
• If a pad cell can be configured by a register or by logic other than from Tessent
BoundaryScan, you can specify dedicated IOs as input-only or output-only pins. Use the
FIN or FOUT pin type options in the Overrides wrapper of the ETAssemble
configuration file or in the Pin Order List Input File.
Example 1
Pad with a dual input buffer to two primary inputs
ETassemble will generate one separate input boundary-scan cell per Usage wrapper. Pins A1
and A2 are assumed connected to top-level primary input pins.
Cell (dualInputsPad) {
Usage {
Pin (A1) {
Function: fromIO;
}
Pin (Y1) {
Function: fromPad;
}
}
Usage {
Pin (A2) {
Function: fromIO;
}
Pin (Y2) {
Function: fromPad;
}
}
}
Example 2
Configurable open-drain pad
The pad is a two-state buffer when its pin ENP=1 and becomes an open-drain output pad when
ENP=0.
Pad Library
Usage
Cell (ConfOpenDrain) {
Usage { // selected if ENP=1. The pad is a tri-statable output pad.
Pin (Z) {
Function: toIO;
}
Pin (A) {
Function: toPad;
}
Pin (ENP) {
Condition: tiedHigh;
}
}
Usage {// selected if ENP=0. The pad is an open-drain pad.
Pin (Z) {
Function: toIO;
Attribute: openDrain;
}
Pin (A) {
Function: toPad;
}
Pin (ENP) {
Condition: tiedLow;
}
}
}
Pad Library
Usage
Chapter 7
Cell Library File
This chapter describes the cell library file for ETAssemble. Most input files described here are
optional; however, the design netlist, pad library and cell library files are required input to
ETAssemble. You run ETAssemble with the LV Flow.
Cell Library Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

AND2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
CellLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
CellsToUseOnFunctionalClockPaths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
ClockAnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
ClockBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
ClockGatingANDCell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
ClockGatingORCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
ClockInverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
ClockMultiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
ClockOr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
LogicalLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Or2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
RetimingFlop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
SynchronizerCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Cell Library File
Cell Library Input File

The cell library file, cell.library, serves as input to the ETAssemble tool. The cell.library file
describes library cells that ETAssemble can use when generating RTL or when inserting
required logic into your design.
A cell library file targeted to your technology must exist. Create this file if your ASIC vendor
does not have a cell library for your technology or if you are an ASIC vendor creating a cell
library.
Figure 7-1 illustrates the syntax of the cell library file.
Figure 7-1. Syntax Summary of the Cell Library File
Cell Library File
CellLibrary (<cellLibName>) {
LogicalLibrary: <libraryName>;
RetimingFlop (<cellName>) {
Port (<portName>): <portFunction>;
....
}
AND2 (<cellName>) {
....
}
Buffer (<cellName>) {
....
}
Inverter (<cellName>) {
....
}
Multiplexer (<cellName>) {
....
}
Or2 (<cellName>) {
....
}
SynchronizerCell (<cellName>) {
...
}
CellsToUseOnFunctionalClockPaths{
ClockGatingANDCell (<moduleName>) {
Port (<portName>): <function>;
}
ClockGatingORCell (<moduleName>) {
}
ClockInverter (<moduleName>) {
}
ClockMultiplexer (<moduleName>) {
}
ClockBuffer (<moduleName>) {
}
ClockAnd (<moduleName>) {
}
ClockOr (<moduleName>) {
}
}
UpdateGroupDelayElement(<cellName>) {
Port (<portName>):<portFunction>;
}
Cell (<cellName>) {// Repeatable for each new cell
Usage { // Optional when only one pair of signals within a cell
Cell Library File
AND2
Pin (<pinName>) {
}// End of Pin wrapper
}// End of Usage wrapper
}// End of Cell wrapper
}
The following sections provide detailed information on the available wrappers and properties of
the cell.library file.
AND2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Cell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
CellLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
CellsToUseOnFunctionalClockPaths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
ClockAnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
ClockBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
ClockGatingANDCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
ClockGatingORCell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
ClockInverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
ClockMultiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
ClockOr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
LogicalLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Or2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
RetimingFlop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
SynchronizerCell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
AND2
The AND2 wrapper defines a 2-input AND cell.
Cell Library File
Buffer
Syntax
AND2 (<cellName>) {
....
}
}
• portName—defines a name of the port.

• portFunction—defines the function of the port. The following port functions must be
defined for this cell:
o Input
o Output
Default Value
None
Usage Conditions
This wrapper is used inside the CellLibrary wrapper.
If no cell library is specified, or if the AND2 cell is not found in the cell library, then the
ETAssemble tool issues an error.
Example
The following example shows the syntax for the AND2 cell in the cell library file.
And2 (LVAND2) {
Port(I1): Input;
Port(I2): Input;
Port(O) : Output;
}
Buffer
The Buffer wrapper defines a buffer that is inserted on data paths to help facilitate the synthesis
and layout flows by providing anchor points for the synthesis/sdc/sta scripts.
Cell Library File
Cell
Syntax
Buffer (<cellName>) {
....
}
}
• portName — defines a name of the port.

• portFunction — defines the function of the port. The following port functions must be
o Input
o Output
Default Value
None
Usage Conditions
This wrapper is used inside the CellLibrary wrapper.
If no cell library is specified, or if the buffer cell is not found in the cell library file, then the
Example
The following example shows the syntax a buffer in the cell library file.
Buffer (BU1D0) {
Port(A): Input;
Port(Y) : Output;
}
Cell
The Cell wrapper contains one or more Usage wrappers which, in turn, contain one or more Pin
wrappers. The Cell wrapper is used to identify special cells in your library. For example, you
can define power isolation (PI) cells so that ETAssemble can connect dedicated isolation (DI)
cells on the correct side of the isolation cell. Similarly, scanGenerate can detect PI cells and
make scan control signal connections (for example, LV_TM) on the correct side of the isolation
cell.
Cell Library File
Cell
Syntax
The syntax for the Cell wrapper is as follows:
Cell (<cellName>) {
Usage {
Pin (<pinName>) {
}
}
}
}
where cellName is any valid Verilog or VHDL identifier. The cellName represents a module
such as a PI cell in your design. The cellName is used to reference that cell in the input netlist
that you provide to ETAssemble.
Default Value
None
Usage Conditions
The Cell wrapper is used in the CellLibrary wrapper. The following usage with PI cells applies:
When ELTCores are designed as power regions, PI cells are often present in the circuit
modified by ETAssemble. Before, when ETAssemble inserted DI cells, it inserted the DI cells
between the pin of the ELTCore and the PI cells. Now it is possible to insert DI cells on the
internal side of the PI cells as shown in Figure 7-2.
Figure 7-2. Dedicated Isolation Cells Automatically Moved Inside Power

Isolation Cells by ETAssemble
To insert DI cells behind PI cells, you must describe your PI cells in the cell.library file for
ETAssemble using the PowerIsoExt and PowerIsoInt pin Functions.
Cell Library File
Cell
Running ETAssemble identifies the PI cells in your design, and if any of these cells are
connected to primary inputs/outputs of the ELTCore that also has a DI cell, the DI cells are
inserted behind the PI cell.
As shown in Figure 7-3, running scanGenerate identifies PI cells in your design, and if any of
these cells are connected to primary input/output scan control pins of the ELTCore or Block,
scan control signal connections are made behind the PI cell. Examples of primary input/output
scan control pins are TestMode, ShiftPhase, ScanIn, and ScanOut.
Figure 7-3. Scan Control Signal Source Automatically Moved Inside Power
Isolation Cells by scanGenerate
Example
The following example indicates that two PI cells are present in the library.
Cell Library File
CellLibrary
Cell (myPwrIso_IType) {
Usage { // Optional when only one pair of signals within a cell
Pin (A) {
Function: PowerIsoExt;
}
Pin (Y) {
Function: PowerIsoInt;
}
}
}
Cell (myPwrIso_OType) {
Pin (A){
}
Pin (Y) {
}
}
CellLibrary
The CellLibrary wrapper is the top-level wrapper of a cell library file. All cell definitions are
included within the CellLibrary wrapper.
Syntax
The complete syntax for this top wrapper is shown in Figure 7-1 on page 400.
Note that cellLibName is any arbitrary character string. The cellLibName string is not used by
ETAssemble; however, you can use cellLibName to reflect your vendor technology.
CellsToUseOnFunctionalClockPaths
The CellsToUseOnFunctionalClockPaths wrapper is used to declare special library cells that
ETAssemble should use when inserting logic on any clock paths.
Many technologies have specific cells designed to be used on clock paths which are duty-cycle
balanced. Many design methodologies prevent any other cell types to be used on clock paths. If
you define the four clock cells supported in the CellsToUseOnFunctionalClockPaths wrapper
then ETAssemble will always instantiate clock cells on clock paths.
It is recommended that you specify at least one ClockMultiplexer cell. Without it, the
multiplexer often gets synthesized into AND-OR cell, and those often create harmful glitches
inside the Burst Clock controllers. Another important clock cell is ClockGatingANDCell. Many
technology libraries only have ClockGatingANDCells. If you do not have a
ClockGatingORCell in your library then get one built or do not define it at all. ETAssemble
will create one in RTL for you. Do not make a “soft” module with discrete cells in it and
describe the soft module as a ClockGatingORCell because it is not a cell. When you declare
Cell Library File
ClockAnd
clock cells then the SDC and STA scripts created by ETAssemble assume that they are cells,
and commands such as find_cell will fail if the specified clock cells are not real cells.
If you have a ClockGatingORCell then do define it. When you have both the
ClockMultiplexer and the ClockGatingORCell defined then the synthesis, layout, and static
timing analysis steps are greatly simplified as clock definitions get declared on cell pins from
the start, and no post synthesis remapping is needed. Refer to Timing Constraints and Clock
Tree Synthesis for a description of the timing constraints and the simplification that occurs when
the clock cells are defined.
Syntax
The syntax for this wrapper is as follows:
CellLibrary(<cellLibName>) {
CellsToUseOnFunctionalClockPaths {
ClockGatingANDCell (<moduleName>) {
}
ClockGatingORCell (<moduleName>) {
}
ClockInverter (<moduleName>) {
}
ClockMultiplexer (<moduleName>) {
}
ClockBuffer (<moduleName>) {
}
ClockAnd (<moduleName>) {
}
ClockOr (<moduleName>) {
}
}
}
Default Value
None
Usage Conditions
The CellsToUseOnFunctionalClockPaths wrapper is used in the CellLibrary wrapper.
ClockAnd
The ClockAnd wrapper defines a 2-input AND cell that scanGenerate must insert when it needs
to insert or build clock gating circuitry. Typically, this is a cell specially designed to preserve
Cell Library File
ClockBuffer
the duty cycle of clocks, and it corresponds to the behavior illustrated in Figure 7-4. Refer to
Timing Constraints and Clock Tree Synthesis for figures showing where the ClockAnd is used.
Figure 7-4. ClockAnd Cell Schematic
Syntax
The syntax for the ClockAnd wrapper is as follows:
ClockAnd (<cellName>){
}
}

o Input
o Output
Default Value
None
Usage Conditions
The ClockAnd wrapper is used in the CellsToUseOnFunctionalClockPaths wrapper.
ClockBuffer
The ClockBuffer wrapper defines a clock buffer that ETAssemble inserts at the base of some
clock trees, such as clockBscan in the JTAP. Typically, this is a cell specially designed to
preserve the duty cycle of clocks, and it corresponds to the behavior illustrated in Figure 7-5.
Cell Library File
ClockGatingANDCell
Figure 7-5. ClockBuffer Cell Schematic
Syntax
The syntax for the ClockBuffer wrapper is as follows:
ClockBuffer (<cellName>){
}
}

o Input
o Output
Default Value
None
Usage Conditions
The ClockBuffer wrapper is used in the CellsToUseOnFunctionalClockPaths wrapper.
ClockGatingANDCell
The ClockGatingANDCell wrapper defines a clock gating cell that forces the clock low when
disabled and corresponds to the behavior illustrated in Figure 7-6. Refer to Timing Constraints
and Clock Tree Synthesis for figures showing where the ClockGatingANDCell is used.
Figure 7-6. ClockGatingANDCell Schematic
Cell Library File
ClockGatingANDCell
If you do not have a ClockGatingANDCell in your library, you must either build one or not
define one at all. ETAssemble will create one for you in RTL. Do not make a “soft” module
containing discrete cells and describe the soft module as a ClockGatingANDCell because this
is not a cell. When you declare a clock cell, the SDC and STA scripts created by ETAssemble
assume that it is a cell, and commands such as find_cell will fail if the specified clock cell is not
a real cell.
Syntax
The syntax for ClockGatingANDCell property is as follows:
ClockGatingANDCell (<cellName>){
}
}
• cellName — specifies any valid Verilog or VHDL identifier that represents a cell in your
cell library. The cellName is used to instantiate the Verilog or VHDL module of the
same name as the cell in the design.
• portName — specifies a name of the port.
• portFunction — defines the function of the port. The following port functions can be
used for this cell:
o Clock
o ClockGated
o LogicHigh (Optional)
o LogicLow (Optional)
o AsynchEnable (Optional)
o AsynchEnableInv (Optional)
o AsynchDisable (Optional)
o AsynchDisableInv (Optional)
o FuncEnable
o FuncEnableInv (Optional)
o TestEnable (Optional)
o TestEnableInv (Optional)
Cell Library File
ClockGatingORCell
Default Value
None
Usage Conditions
The ClockGatingANDCell wrapper is used in the CellsToUseOnFunctionalClockPaths
wrapper.
When this cell is instantiated within a Burst Clock Controller (BCC), a specified
AsynchDisable/AsynchDisableInv port function will be tied to its inactive value. A specified
AsynchEnable/AsynchEnableInv port function will be connected to funcMode on the TAP so
that the clock gating is disabled in functional mode.
ClockGatingORCell
The ClockGatingORCell wrapper defines a clock gating cell that forces the clock high when
disabled and corresponds to the behavior illustrated in Figure 7-7. Refer to Timing Constraints
and Clock Tree Synthesis for figures showing where the ClockGatingORCell is used.
Figure 7-7. ClockGatingORCell Schematic
If you do not have a ClockGatingORCell in your library, you must either build one or not
define one at all. ETAssemble will create one for you in RTL. Do not make a “soft” module
containing discrete cells and describe the soft module as a ClockGatingORCell because this is
not a cell. When you declare a clock cell, the SDC and STA scripts created by ETAssemble
assume that it is a cell, and commands such as find_cell will fail if the specified clock cell is not
a real cell.
Syntax
The syntax for the ClockGatingORCell wrapper is as follows:
ClockGatingORCell (<cellName>){
}
}
Cell Library File
ClockInverter
• cellName — specifies any valid Verilog or VHDL identifier that represents a cell in your
cell library. The cellName is used to instantiate the Verilog or VHDL module of the
same name as the cell in the design.
• portName — specifies a name of the port.
• portFunction — defines the function of the port. The following port functions can be
used for this cell:
o Clock
o ClockGated
o AsynchEnable (Optional)
o AsynchEnableInv (Optional)
o AsynchDisable (Optional)
o AsynchDisableInv (Optional)
o FuncEnable
o FuncEnableInv (Optional)
o TestEnable (Optional)
o TestEnableInv (Optional)
Default Value
None
Usage Conditions
The ClockGatingORCell wrapper is used in the CellsToUseOnFunctionalClockPaths wrapper.
When this cell is instantiated within a Burst Clock Controller (BCC), a specified
AsynchDisable/AsynchDisableInv port function will be tied to its inactive value. A specified
AsynchEnable/AsynchEnableInv port function will be connected to funcMode on the TAP so
that the clock gating is disabled in functional mode.
ClockInverter
The ClockInverter wrapper defines an inverter that ETAssemble must use when a clock needs
to be inverted. Typically, this is a cell specially designed to preserve the duty cycle of clocks,
Cell Library File
ClockMultiplexer
and it corresponds to the behavior illustrated in Figure 7-8. Refer to the Timing Constraints and
Clock Tree Synthesis for figures showing where the ClockInverter is used.
Figure 7-8. ClockInverter Cell Schematic
Syntax
The syntax for the ClockInverter wrapper is as follows:
ClockInverter (<cellName>){
}
}

o Input
o Output
Default Value
None
Usage Conditions
The ClockInverter wrapper is used in the CellsToUseOnFunctionalClockPaths wrapper.
ClockMultiplexer
The ClockMultiplexer wrapper defines a multiplexer that ETAssemble must use when a clock
needs to be multiplexed. Typically, this is a cell specially designed to preserve the duty cycle of
clocks, and it corresponds to the behavior illustrated in Figure 7-9. Refer to Timing Constraints
and Clock Tree Synthesis for figures showing where the ClockMultiplexer is used.
Cell Library File
ClockOr
Figure 7-9. Clock Multiplexer Cell Schematic
Syntax
The syntax for the ClockMultiplexer wrapper is as follows:
ClockMultiplexer (<cellName>){
}
}

• portFunction — defines the function of the port. The following port functions must all
be defined for this cell:
o Input0
o Input1
o Output
o Select
Default Value
None
Usage Conditions
The ClockMultiplexer wrapper is used in the CellsToUseOnFunctionalClockPaths wrapper.
ClockOr
The ClockOr wrapper defines a 2-input OR cell that scanGenerate must inserts when it needs to
insert or build clock gating circuitry. Typically, this is a cell specially designed to preserve the
Cell Library File
Inverter
duty cycle of clocks, and it corresponds to the behavior illustrated in Figure 7-10. Refer to
Timing Constraints and Clock Tree Synthesis for figures showing where the ClockOr is used.
Figure 7-10. ClockOr Cell Schematic
Syntax
The syntax for the ClockOr wrapper is as follows:
ClockOr (<cellName>){
}
}

o Input
o Output
Default Value
None
Usage Conditions
The ClockOr wrapper is used in the CellsToUseOnFunctionalClockPaths wrapper.
Inverter
The Inverter wrapper defines an inverter cell.
Cell Library File
Function
Syntax
Inverter (<cellName>) {
....
}
}

o Input
o Output
Default Value
None
Usage Conditions
If no cell library is specified, or if the inverter cell is not found in the cell library file, then the
Example
The following example shows the syntax an inverter in the cell library file.
Inverter (LVINV) {
Port (I): Input;
Port (O): Output;
}
Function
The Function property specifies the logical function of the pin. ETAssemble extracts the design
information from the input netlist by using the function information to identify ports of a cell.
The nets connecting to these ports are then traced to identify the connection to the cells within
the core module.
Cell Library File
LogicalLibrary
Syntax
where functionType can be as follows:
• PowerIsoExt — identifies the pin on the power isolation cell that is connected to the
primary input or primary output port of the ELTCore.
• PowerIsoInt — identifies the pin on the power isolation cell that is connected to the
internal logic of the ELTCore.
Default Value
None
Usage Conditions
The Function property is used in the Cell: Pin or Cell: Usage: Pin wrappers.
The PowerIsoExt and PowerIsoInt pin functions are used when running ETAssemble or
scanGenerate on an ELTCore or Block module when power isolation (PI) cells are present. For
details on the insertion mechanism, refer to the Cell wrapper.
Example
The following example shows cell definitions using the Function property syntax:
Usage {
Pin (A) {
}
Pin (Y) {
}
}
}
Cell (myPwrIso_OType) {
Pin (A) {
}
Pin (Y) {
}
}
LogicalLibrary
The LogicalLibrary property specifies the logical library in which the cells listed in the
enclosing CellLibrary wrapper have been compiled.
Cell Library File
Multiplexer
Syntax
LogicalLibrary: <libraryName>;
...
}
where libraryName is the logical library into which the cells have been compiled.
Default Value
None
Usage Conditions
This property is used inside the CellLibrary wrapper.
For Verilog cells, this property is not needed. For VHDL cells, this property is needed only if
the cells are compiled in a logical library other than the library designated as WORK in the file
named in the VhdlRtlFileList property of the .etplan file.
Example
The following example shows a cell library with a LogicalLibrary property specified and
indicates that the cell myBuf from the logical library myCore is used as the buffer cell, and the
cell myMux from the same logical library is used as the multiplexer cell.
CellLibrary (myCellLib) {
LogicalLibrary: myCore;
Buffer (myBuf) {
Port (bufin): Input;
Port (bufout): Output;
}
Multiplexer (myMux) {
Port (A): Input0;
Port (B): Input1;
Port (Y): Output;
Port (EN): Select;
}
}
Multiplexer
The Multiplexer wrapper defines a 2:1 multiplexer which is used on data paths to help facilitate
the synthesis and layout flows by providing anchor points for the synthesis/sdc/sta scripts.
Cell Library File
Multiplexer
Syntax
Multiplexer (<cellName>) {
....
}
}

o Input0
o Input1
o Output
o Select
o Open (Optional)
Default Value
None
Usage Conditions
If no cell library is specified, or if the multiplexer cell is not found in the cell library file, then
the ETAssemble tool issues an error.
Example
The following example shows the syntax a multiplexer in the cell library file.
Multiplexer (MUXA) {
Port (A): Input0;
Port (B): Input1;
Port (S): Select;
Port (Z): Output;
}
Cell Library File
Or2
Or2
The Or2 wrapper defines a 2-input OR cell which is used on data paths to help facilitate the
synthesis and layout flows by providing anchor points for the synthesis/sdc/sta scripts.
Syntax
Or2 (<cellName>) {
....
}
}

o Input
o Output
Default Value
None
Usage Conditions
If no cell library is specified, or if the Or2 cell is not found in the cell library file, then
ETAssemble issues an error.
Example
The following example shows the syntax an Or2 cell in the cell library file.
Or2 (LVOR2) {
Port (I1): Input;
Port (I2): Input;
Port (O): Output;
}
Pin
The Pin wrapper describes the functionality of the cell pins.
Cell Library File
Pin
Syntax
Pin (<pinName>) {
}
where pinName is any valid Verilog or VHDL identifier. The pinName is specific to a pin and
should not be confused with a signal name in the netlist.
Default Value
None
Usage Conditions
The Pin wrapper is used in the following wrappers:
• Cell
The Pin wrapper is specified in the Cell wrapper when only one pair of signals is within
a cell.
• Usage
The Pin wrapper is specified in the Cell: Usage wrapper when more than one pair of
signals is within a cell.
Example
The following example describes multiple usages for the myPwrIso power isolation cell.
Cell (myPwrIso) {
Usage {
Pin (A) {
}
Pin (Y) {
}
}
Usage {
Pin (A) {
}
Pin (Y) {
}
}
}
Cell Library File
Port
Port
The Port property specifies the name and function of each pin of the specified cell.
Syntax
<cellTypeWrapper> (<cellName>) {
....
}
}
where the following is valid:
• cellName is any valid Verilog or VHDL identifier. cellName represents a cell in your
cell library. cellName is used to instantiate the Verilog or VHDL module of the same
name as the cell in the design.
• The valid portFunction is determined by the wrapper as shown in Table 7-1. Optional
port functions are marked with *.
Cell Library File
Port
Table 7-1. Valid portFunction Values for the Port property in Different Cell-Type
Wrappers
UpdateGroupDelayElement ClockAnd ClockBuffer ClockInverter ClockOr

Value
RetimingFlop SynchronizerCell
ClockGatingANDCell
ClockGatingORCell
ClockMultiplexer
Multiplexer
Inverter
Buffer
AND2
Or2
Clock 3 3 3
Input 3 3 3 3 3 3
Input0 3 3
Input1 3 3
Output 3 3 3 3 3 3 3 3
Select 3 3
LogicHigh 3* 3* 3* 3* 3* 3*
LogicLow 3* 3* 3* 3* 3* 3*
Open 3* 3* 3*
Cell Library File
Port
Wrappers (cont.)

Value
ClockGatingANDCell
ClockGatingORCell
ClockMultiplexer
Multiplexer
Inverter
Buffer
AND2
Or2
Clock 3 3
Gated
Asynch 3* 3*
Enable
Asynch 3* 3*
EnableInv
Asynch 3* 3*
Disable
Asynch 3* 3*
DisableInv
Func 3* 3*
Enable
Cell Library File
Port
Wrappers (cont.)

Value
ClockGatingANDCell
ClockGatingORCell
ClockMultiplexer
Multiplexer
Inverter
Buffer
AND2
Or2
Func 3* 3*
EnableInv
Test 3* 3*
Enable
Test 3* 3*
EnableInv
Default Value
None
Usage Conditions
The Port property is used inside the following wrappers:
• AND2
Cell Library File
Port
• Buffer
• ClockAnd
• ClockBuffer
• ClockGatingANDCell
• ClockGatingORCell
• ClockInverter
• ClockMultiplexer
• ClockOr
• Inverter
• Multiplexer
• Or2
• RetimingFlop
• SynchronizerCell
• UpdateGroupDelayElement
These usage conditions apply to this property:
• Table 7-1 summarizes the required/optional values for this property for different
available wrappers.
• You must list unused input ports using the LogicLow and LogicHigh port functions, and
unused output ports must use the Open port function. Table 7-1 shows the cell wrappers
that support the LogicHigh, LogicLow, and Open port functions.
Example 1
The following example shows the syntax for the AND2 cell in the cell library file:
And2 (LVAND2) {
Port (I1): Input;
Port (I2): Input;
Port (O) : Output;
}
Cell Library File
RetimingFlop
Example 2
The following example shows the syntax for SynchronizerCell in the cell library file:
SynchronizerCell (SYNCO1) {
Port (D): Input;
Port (CLK): Clock;
Port (Q): Output;
Port (QZ): Open;
Port (RSTN): LogicHigh;
}
RetimingFlop
The RetimingFlop wrapper defines the cell to be used as a retiming flip-flop in the design. A
retiming flip-flop is automatically inserted between any two scan chains that are concatenated
together in the scan-through-TAP mode.
Syntax
RetimingFlop (<cellName>) {
....
}
}

o Clock
o Input
o Output
o Open (Optional)
Default Value
None
Cell Library File
SynchronizerCell
Usage Conditions
This wrapper is used inside the main CellLibrary wrapper.
Because two scan chains being concatenated may belong to different clock domains, a retiming
flip-flop is necessary to synchronize data between the two chains.
Example
This example shows the specification of a retiming flip-flop in the cell library file.
CellLibrary (CellLibA) {
RetimingFlop (FFD1P) {
Port (CKN): Clock;
Port (D): Input;
Port (Q) : Output;
Port (RN) : LogicHigh;
Port (QB) : Open;
}
}
SynchronizerCell
The SynchronizerCell wrapper defines a two-stage synchronizer cell with setup and hold timing
checks. The synchronizer is used to resolve meta-stability when some signals in the
ETAssemble created RTL cross a clock domain boundary.
Figure 7-11. SynchronizerCell Schematic
If you do not have a SynchronizerCell in your cell library then get one built or do not define it at
all. ETAssemble will create one in RTL for you. Do not make a “soft” module with discrete
cells in it and describe the soft module as a SynchronizerCell because it is not a cell. When you
declare a synchronizer cell then the SDC and STA scripts created by ETAssemble assume that it
is a cell, and commands such as get_cells will fail if the specified synchronizer cell not a real
cell.
Cell Library File
SynchronizerCell
Syntax
SynchronizerCell (<cellName>) {
...
}

o Clock
o Input
o Output
o Open (Optional)
Default Value
None
Usage Conditions
This property is used in the CellLibrary wrapper.
If the synchronizer cell is not found in the cell library file, then ETAssemble creates its own
RTL synchronizer cell.
Forcing Notifiers
If you do not have a SynchronizerCell in your cell library then you might be required to force
notifiers on certain flops to resolve simulation artifacts when simulating with a timing-
annotated netlist. The steps needed to force these notifiers are outlined below:
1. Identify the flops on which the notifier must be forced to prevent X propagation.
2. For logic test, you must force the burstPhaseR[0] flop in the BurstClock controllers.
3. For memory BIST, you must force all MBIST_RETIMING_CELL.RETIME_REG[0]
flops in the memory BIST controllers and all NTC flops in any pre-7.0 memory BIST
controllers.
Cell Library File
UpdateGroupDelayElement
4. Create a file that will force the notifiers. For example, the file for a logicBIST pattern
might look like this:
module set_notifiers ();
initial begin
force
TB.DUT_inst.CHIP..LV_BURST_CLK_CTRL_I1.burstPhaseR_reg_0_.VT =
1'b0;
end
endmodule
Note
A notifier file will need to be created for each pattern being simulated. All the
notifier files will be forcing the same flop but the hierarchical instance path to the
flop is different for each pattern.
5. When the simulation is run pass the notifier file to the simulator. For example, in the
lvWorkSpace the command would be:
make sim cmdOptions=”-select logicbistv_core
set_notifier_logicbistv.v”
Example
This example shows the specification of a synchronizer flip-flop in the cell library file.
CellLibrary (CellLibA) {
SynchronizerCell (SYNCO1) {
Port (D): Input;
Port (CLK): Clock;
Port (Q): Output;
Port (QZ): Open;
Port (RSTN): LogicHigh;
}
}
UpdateGroupDelayElement
The UpdateGroupDelayElement wrapper defines the cell to be used as a delay element to
control ground bounce during the update boundary-scan update cycle. One or more of these
elements are inserted by ETAssemble to stagger the times at which the update occurs.
Syntax
The following syntax specifies this wrapper and its properties:
UpdateGroupDelayElement (<cellName>) {
Port (<portName>):<portFunction>;
}
}
Cell Library File
Usage

o Input
o Output
Default Value
None
Usage Conditions
None
Example
This example shows a delay element in the cell library file.
UpdateGroupDelayElement (BUF4) {
Port(A) : input;
Port(Y) : output;
}
Usage
The Usage wrapper contains the pin definitions for different usage modes of the cell.
Syntax
Usage {
Pin (<pinName>) {
}
}
Default Value
None
Usage Condition
The Usage wrapper is used in the Cell wrapper.
• You can include multiple Usage wrappers in the Cell wrapper.
Cell Library File
Usage
• You can omit the Usage wrapper if the cell has only one usage mode. However, you
must include the Pin wrappers in the Cell wrapper.
Example
The example below describes pin A and Y of the pad cell myPwrIso_IType:
Usage {
Pin (A) {
}
Pin (Y) {
}
}
}
Cell Library File
Usage
Chapter 8
Pin Order Input File
This chapter describes the optional pin order list file, <designName>.pinorder. It serves as
input to ETAssemble and provides the package-pin data and the boundary-scan chain sequence.
Pin Order List Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

PinName Column Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
PinNumber Column Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
PinType Column Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Sides Column Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Pin Order List Input File

The optional pin order list file, <designName>.pinorder, serves as input to ETAssemble and
provides the package-pin data and the boundary-scan chain sequence. You can also specify
device identification in this file. The .pinorder file comprises four columns, separated by space,
in which you enter data. The row order of the columns indicates the sequence in which
boundary-scan chains are arranged.
You can find more information about the entries in each of these columns in the following
sections:
• PinName Column Entries

• PinNumber Column Entries
• PinType Column Entries
• Sides Column Entries
ETAssemble automatically creates a pin order list file when you invoke the tool and the -
genPinTemplate Yes option of the command line. For example, the following syntax instructs
ETAssemble to generate the .pinorder file.
etassemble top top.v -genPinTemplate On
where top is the name of your top-level netlist. Figure 8-1 illustrates a sample
<designName>.pinorder file format, with each column name in the correct order after edits
were made to the file.
Figure 8-1. Sample Pin Order List File
Pin Order List Input File
// PinName PinNumber PinType Side

// --------- ------------ ---------- -----------
IN1 1 - left_0
IN2 2 - -
GND1[2] 3 GND -
GND1[1] 3A GND left_1
GND1[0] X1 GND top_0
IN3 4 - -
IN4 5 - top_1
OUT1 6 - -
OUT2 7 - right_0
VDD1 Y1 PWR -
TN 9 CE1 bottom
SCANIN 10 NJTAG bottom
NC1 N1 NC right_0
TCKP 11 TCK right_0
TMSP 12 TMS right_0
TRSTP 13 TRST right_0
TDIP 15 TDI right_0
TDOP 16 TDO right_0
The following usage conditions apply to the .pinorder file:
• Use a dash (-) to indicate a non-entry in a column.

• Specify only one entry per row, per column.
• Specify the .pinorder file with the runtime option -pinOrderList. ETAssemble searches
the current working directory for the default pin order list <designName>.pinorder,
where designName is the name of the chip and the prefix that ETAssemble uses for all
generated output files.
If ETAssemble cannot locate the default file, then the tool creates a
<designName>.pinorder file using information that the tool automatically extracts from
your design netlist.
• Specify the device information on a single line in the pin order list file. For example,
PinName Column Entries
//pin order file generated by lvxsetup

device_id = 32'b001000000100101011000001101

// --------- --------- ------- -----
IN1 1 - left_0
You also can specify device ID information in the .etassemble configuration file using
the DeviceIdCode, ManufacturersIdCode, and RevisionCode properties.
If the device ID information is specified in both the .pinorder and .etassemble files, the
value in the .etassemble file has the highest priority. If no device ID information in
specified in either file, the device ID register is not created in the TAP.
• The first row in the .pinorder file is closest to the TDI pin.
• The last row in the .pinorder file is closest to the TDO pin.
Note
The settings in the .etassemble configuration file override the data in the .pinorder
file. You can use the configuration file’s BoundaryScan:Overrides wrapper to
change the PinType and the BoundaryScan:Sides wrapper to change the pin Sides (or
boundary scan group). An added advantage of editing the .etassemble configuration file
is that its syntax supports pin name regular expressions.
PinName Column Entries

PinName is the name of the first column in the .pinorder file. You specify the name of your pins
in this column. The name of the pin must be a valid HDL character string. The following
restrictions apply to the entries in this column:
• Bus pins must be specified bit-by-bit. For example, a bus pin data[3:0] is specified as
data[3], data[2], data[1], and data[0] on four separate rows.
• A pin name must be unique across all rows under this column.
• The order of the rows describes the sequence of the boundary-scan register. List each
row according to the order in which the pins appear around the die of the chip. The TAP
controller is assumed to be placed before the first row (which is also after the last row).
• A dash (-) cannot be specified as an entry under this column.
• An I/O port name of en<n> is not allowed.
PinNumber Column Entries
PinNumber Column Entries

PinNumber is the second column in the .pinorder file. In this column, specify the package-pin
number corresponding to the pin name specified in the PinName column. ETAssemble uses the
pin number information to generate a valid BSDL file for your chip. The following restrictions
apply to the entries in this column:
• For the pin number entry, you use any alpha-numeric character string that is a valid
BSDL identifier.
• A dash (-) can be specified only as an entry under this column—if the pin type is NC. In
this case, the pin information is not written into the BSDL file.
PinType Column Entries

PinType is the third column in the .pinorder file. In this column, specify the purpose of the pin.
ETAssemble uses the information in the PinType column to generate a valid BSDL file for your
chip.
Valid values in this column are as follows:
• - (dash) indicates a non-entry.

• PWR indicates that a pin is a power source.
• GND indicates that a pin is a ground source.
• NC indicates that a pin is not connected.
• CLK adds a CLK type boundary-scan cell to an identified pad.
• ANLG adds an analog pin as a linkage pin in BSDL.
• SAMPLE adds a sample pin type that requires a SampleOnly boundary-scan cell.
Dedicated TAP Pins
• TDI identifies TAP Test-Data-In Pin.
• TDO identifies TAP Test-Data-Out Pin.
• TMS identifies TAP Test-Mode-Select Pin.
• TRST identifies TAP Test Reset Pin.
• TCK identifies the TAP dedicated test clock pin.
Note
The default .pinorder file will contain “-” PinType column entries for the dedicated
TAP pins. The tool will correctly assign the appropriate PinType for these pins if
the ETChecker and ETPlanner steps are properly completed. The .pinorder file can be
edited to declare or modify the PinType entries, or even change the Side entries if
desired.
Note
If the design does not have an external TRST pin, then that pin name will not be
included in the .pinorder file.
Shared TAP Pins Muxed With Functional Pins

• STDI identifies shared TAP Test-Data-In Pin.
• STDO identifies shared TAP Test-Data-Out Pin.
• STMS identifies shared TAP Test-Mode-Select Pin.
• STRST identifies shared TAP Test Reset Pin.
• STCK identifies the shared TAP test clock pin.
Note
You must specify the TAP pins as either all shared or all dedicated; that is, in the
.pinorder file, you can specify only the set TDI, TDO, TMS, TRST, TCK or the set
STDI, STDO, STMS, STRST, STCK—not both.
• STAPENO identifies shared TAP Enable Active Low Pin.

• STAPEN1 identifies shared TAP Enable Active High Pin.
Note
You must identify the shared TAP enable pin with either STAPENO or STAPEN1 if
you use shared TAP pins in the .pinorder file.
You cannot identify a shared TAP enable pin if the TAP pins are dedicated.
Direction Specification Pin Types

• FIN (functional input) forces ETAssemble to process the pin as an input-only pin during
boundary-scan insertion even if the actual pin direction is inout in the netlist and the pin
is connected to a bidirectional pad cell. The generated BSDL file will document the pin
as input, and the pin will connect to an input-type boundary-scan cell.
• FOUT (functional output) forces ETAssemble to process the pin as an output-only pin
during boundary-scan insertion even if the actual pin direction is inout in the netlist and
the pin is connected to a bidirectional pad cell. The generated BSDL file will document
the pin as output, and the pin will connect to an output-type boundary-scan cell.
• FIO (functional inout) identifies the pin as an IO. FIO is valid only for inout pins.
Note the following considerations when using the FIN, FOUT, and FIO pin types:
• The FIN and FOUT options are used only in chip design flows that force all top-level
pin directions to inout and connect to pad cells with bidirectional capabilities (bidir
pads) even when some pins are used as input-only or output-only in functional mode. In
the netlist, such input-only pins would tie off their bidir pad’s driver-enable control pin,
and output-only pins would leave their pad’s fromPad pin unconnected.
By default, ETAssemble inserts boundary-scan cells whose functions match their
associated netlist top-level pin directions. That means ETAssemble would insert a
bidirectional boundary-scan cell for an inout pin. If you want an input-type boundary-
scan cell when the pin is a functional input or an output-type boundary-scan cell when
the pin is a functional output, you can specify FIN or FOUT, respectively, in the
.pinorder file to force insertion of that direction. The generated BSDL will then closely
reflect the chip’s functional mode pin directions.
Note
Keeping all top-level pins bidirectional is useful if you want to implement wafer-
based minimum pin count IO tests or if you want to add more diagnostic capabilities
to your board-level interconnect test.
• The FIN, FOUT, and FIO pin types are mutually exclusive; you cannot specify more
than one for the same pin.
• When using FIN, FOUT, or FIO, you must specify complete buses as either input,
output, or inout; you cannot specify different directions for individual bus members.
Figure 8-2 provides a .pinorder file example showing four IO pins (io_in[0] to io_in[3])
that are used as inputs, four IO pins (io_out[0] to io_out[3]) that are used as outputs, and
two IO pins (io_io[2] and io_io[3]) that are asserted as inouts. The pins io_io[0] and
io_io[1] are IO pins but are not asserted.
Figure 8-2. Sample Pin Order List File Showing Direction Specifications

// ------------ --------------- ----------- -------
TDI 1 – –
TMS 2 – –
TCK 3 – –
TRST 4 – –
TDO 5 – –
io_in[0] 6 FIN –
io_in[1] 7 FIN –
io_in[2] 8 FIN –
io_in[3] 9 FIN –
io_out[0] 10 FOUT –
io_io[0] 14 – –
io_io[1] 15 – –
io_io[2] 16 FIO –
io_io[3] 17 FIO –
Other Pin Types

• NJTAG does not add a boundary-scan cell to the pads connected to this pin.
• DontTouch specifies that the pin should not be connected to a boundary-scan cell. This
value is similar to the NJTAG value; however, it is more restrictive: when specified for
output or bidirectional pads, the pad enable is not gated with the forceDisable signal
from the TAP.
• CE0 does not add a boundary-scan cell to the pad connected to this pin. During JTAG
testing, this pin is asserted to logic 0. Additionally, this pin is listed in the BSDL file as a
compliance-enable pin.
• CE1 does not add a boundary-scan cell to the pad connected to this pin. During JTAG
testing, this pin is asserted to logic 1. Additionally, this pin is listed in the BSDL file as a
compliance-enable pin.
• SET adds a sample only boundary-scan cell to the pad connected to this pin.
• RESET adds a sample only boundary-scan cell to the pad connected to this pin.
• AUX identifies the pin as an auxiliary-scan port.
• NOAUX identifies this type of pin as one that cannot be an auxiliary-scan port. PWR,
SET, RESET, GND, NC, CLK, TDI, TDO, TMS, TCK, and TRST pins are automatically
considered as NOAUX pins.
Note
You can use either the AUX option or the NOAUX option in the .pinorder file—not
both.
Sides Column Entries
Sides Column Entries

Sides is the last column in the .pinorder file. In this column, you specify the side or group to
which a boundary-scan cell corresponding to a pin must belong. Grouping of boundary-scan
cells in this manner is useful for floorplanning purposes. The following usage conditions apply
to this column:
• Specify a side name that is a valid HDL character string.
• Specify the name of a group in the Sides column only once—entering a dash (-) for each
row under a group name indicates that the row belongs to the same group.
• Include the top-most rows, which only have dashes above them, in the side grouping of
the bottom rows. Because the TAP controller is always before the first row, you can
group cells to the left and to the right of the TAP controller into a single side grouping.
• Enter a dash (-) in this column to indicate a non-entry, if the following occurs:
o A side name is not entered in the previous row.
o A dash (-) is entered in the PinType column of the same row.
In addition to the boundary-scan cell grouping, the Sides column entry also specifies the
boundaries for the enable groups. Sharing a common enable boundary-scan cell among multiple
output or bidirectional pins is allowed among pins with the same side name.
Chapter 9
ETAssemble Runtime Options
Based on the test specifications you include in multiple input files, ETAssemble reads in a chip-
level netlist and generates a fully assembled top-level module that can include boundary-scan
cells, an IEEE 1149.1-compliant test access port (TAP) controller, a logicTest controller, and
other embedded test structures. By specifying runtime options, you control how the
ETAssemble tool operates.
This chapter describes all available runtime options in alphabetic order:
ETAssemble Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

-arch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
-CADEnvFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
-cellLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
-clockGatingScanModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
-config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
-define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
-defineFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
-embeddedTestSpecification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
-etDefFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
-extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
-f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
-f_sv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
-flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
-fvScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
-genPinTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
-genTemplate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
-hdleInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
-HDLwarningFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
-ICTechFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
-incDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
-lvlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
-macroSynthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
-mfcu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
-modifiedExtension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
-outDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
-padLibrary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
-pinOrderInfoFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
-pinOrderList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
-pragma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
ETAssemble Syntax
-r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
-rtlExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
-stopMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
-structuralExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
-timingscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
-userLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
-y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
-yvhdl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Language Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
ETAssemble Syntax
The complete syntax for running ETAssemble from the command line is listed below.
ETAssemble Syntax
etassemble
etassemble -help
etassemble <designName> <sourceFileName1>
<sourceFileName2>...
-arch <architectureName>
-CADEnvFile <fileName>
-cellLibrary <fileName>
-clockGatingScanModel On | (Off)
-config <configName>
-define <macro_name> |
<macro_name>=”<macro_string>”
-defineFile <defineFileName>
-embeddedTestSpecification <fileName>
-etDefFile <fileName>
-extension <libExt1>:<libExt2>:<libExtN>...
-flow chip | block | EBScan
-fvScript On | (Off)
-genPinTemplate On | (Off)
-genTemplate On | (Off)
-hdleInfo On | (Off)
-HDLwarningFilter Off | Low | (High)
-ICTechFile <fileName>
-incDir <includeDirectoryName>
-log <fileName>
-lvlib <lvlibFileName>
-modifiedExtension <modifiedExtension>
-outDir <directoryName>
-padLibrary <fileName>
-pinOrderInfoFile <fileName>
-pinOrderList <fileName>
-pragma <pragmaName>
-r <topModuleName>
-rtlExtension <extension>
-stopMod <moduleName1>:<moduleName2>...
-structuralExtension <extension>
-timingscript (No) | Yes
-userLib <fileName>
-v <libraryFileName>
-y <libraryDirectoryName>
-yvhdl <vhdlLibraryName>
Valid values for command-line options are case-insensitive.
In the syntax above, the variables represent the following:
• designName identifies the prefix for all generated module names and all design-related
output files, except the log file. designName also specifies the default prefix for the input
configuration file.
• sourceFileName specifies one or more design files that you want ETAssemble to load
for analysis.
Specifying the -help option displays a summary of the command-line syntax and usage. Typing
etassemble without any parameters also displays this summary.
-arch
The available language options are described in detail in the section Language Options.
-arch
The -arch option specifies the architecture body of the top-level VHDL entity declaration that
the tool reads.
Syntax
The following syntax specifies this option:
-arch <architectureName>
where architectureName is a VHDL identifier.
Default Value
The default architecture is the last architecture compiled for the VHDL entity declaration that is
specified using the -r option.
Usage Conditions
• topArchitectureName must refer to an architecture body contained in a source file or in a

file that is declared by a file compilation rule appearing in the lvlib file. This file
compilation rule must be specified for the logical library designated as WORK.
• You cannot use -arch with -config.
• You must use the -arch option in conjunction with the -r option to specify the top-level
VHDL design entity.
Example
This example specifies the defg architecture of the top VHDL entity declaration blockA using
designExtract. In the example, myDesign.vhds refers to the file describing the circuit design.
etassemble myDesign.vhds -r blockA -arch defg
-CADEnvFile
The -CADEnvFile option allows you to specify file name that contains the CAD environments
and commands that are to be used to perform specific CAD operations. For example, the file can
define the default simulator and the simulation commands to be used, the type of the synthesis
tool to be used, the name of the command to create a directory, change directory, etc. Typically,
this file is defined by the central CAD group. The default values for this file are extracted from
the LV_CADENV_FILE environment variable.
-cellLibrary
Syntax
-CADEnvFile <fileName>
where fileName can be any identifier that is a valid operating system filename. fileName might
also include the path name information.
Default Value
None
Usage Conditions
This option is used only when -genTemplate is set to On.
If you have a CADEnvFile that you use with ETPlanner, point to it using the -CADEnvFile
option when running ETAssemble with -genTemplate On. This enables creation of a simScrip
file consistent with your simulation environment.
Example
The following example points to ETAssemble to read in the specified CADSetup file.
etassemble myDesignA -CADEnvFile MyCadEnvFile
-cellLibrary
The -cellLibrary option specifies the name of the cell library file that defines library cells
available for ETASsemble to use.
Syntax
-cellLibrary <fileName>
where fileName can be an actual file path specification or a file that can be located using the
paths specified with the -y option.
Default Value
The default file name is cell.library in the current working directory.
Usage Conditions
• If you did not specify -cellLibrary, ETAssemble looks for the library cells it can use
within the file specified by the -padLibrary command line option.
-clockGatingScanModel
• This option can be repeated to read in multiple cell library files.

• If a cell is declared more than once in the same cell library, ETAssemble issues a
warning. However, if the same cell is declared in a subsequent cell library file, then the
last declaration overrides all others.
Examples
This syntax example specifies the cell library file, myCellLibrary.lib, which is in the ../libs/
directory.
etassemble top top.v -cellLibrary ../libs/myCellLbrary.lib
-clockGatingScanModel
The -clockGatingScanModel option specifies whether:
• When set to On—ETAssemble generates a separate scan model file that describes the
clock gating in the Burst Clock controllers. This file can then be read into designExtract
so it can trace through the Burst Clock Controllers clock gating circuitry.
• When set to Off, ETAssemble generates the Burst Clock controllers with a Verilog pre-
preprocessor ifdef statement that describes the clock gating to designExtract so it can
trace through the Burst Clock controllers clock gating circuitry.
Syntax
-clockGatingScanModel On | (Off)
Default Value
The default is Off.
Usage Conditions
None
Example
This example instructs ETAssemble to generate a separate scan model file.
etassemble myDesign -clockGatingScanModel On
-config
The -config option specifies a top-level VHDL configuration declaration for the circuit. It
provides a convenient means of indirectly specifying a top design entity with a specific
architecture body using a single option.
-define
Syntax
-config <topConfigurationName>
where topConfigurationName is a VHDL identifier.
Default Value
None
Usage Conditions
• topConfigurationName must refer to a configuration declaration contained in a source

file or in a file that is declared by a file compilation rule appearing in the lvlib file. This
file compilation rule must be specified for the logical library designated as WORK.
• You cannot use -config with -arch.
Example
This example specifies defg as the VHDL configuration declaration for the circuit using the
designExtract tool. In the example, myDesign.vhds refers to the file describing the circuit
design.
etassemble myDesign.vhds -config defg
-define
The -define option defines variable names as empty text or as string macros throughout the
compilation process (global macros).
Syntax
The following syntax specifies this option when it defines a macro name as an empty text:
-define <macro_name>
The following syntax specifies this option when it defines a macro name as a string:
-define <macro_name>=”<macro_string>”
Default Value
None
-defineFile
Usage Conditions
• The -define option is similar to a‘define line in a design file because it enables you to
control which section of a design file is used.
• The scope of a macro definition, such as a ‘define line, in a Verilog design file is limited
to that design file. The -define option enables you to define a macro that remains in
scope throughout the compilation of every Verilog design file.
• The -define option can be specified multiple times.
Example
The syntax below uses the NOCHECKS macro to turn off timing checks in a simulation model.
In this example, myDesign.v refers to the source file.
etassemble myConfig myDesign.v -define NOCHECKS
-defineFile
The -defineFile option specifies the name of a file containing macro definitions that remain in
scope throughout the compilation of each Verilog design file.
Syntax
-defineFile <defineFileName>
where defineFileName is a valid operating system file name.
Default Value
None
Usage Conditions
• The scope of a macro definition, such as a ‘define line, in a Verilog design file is limited
to that design file. The -defineFile option provides a facility for defining macros that
remain in scope throughout the compilation of each Verilog design file.
• The file specified by defineFileName must contain only macro definitions and
comments using standard Verilog syntax.
• The macro definitions can contain macro text (unlike macros specified using -define).
• If defineFileName is specified as a relative path, it is assumed to be relative to the
directory in which you invoked ETAssemble.
-embeddedTestSpecification
• The -defineFile option can be specified multiple times.

Example
In the following example, the configuration file is top.etassemble. The circuit file is
myDesign.v, and the file myDefines.v contains the global macro definitions.
etassemble top.etassemble myDesign.v -y ./myLibrary \

-defineFile myDefines.v
Macros defined in myDesign.v,as well as those defined in library directory files, are limited in
scope to the file in which they are defined. Macros defined in myDefines.v are global in scope;
that is, they are visible in myDesign.v as well as in all library directory files.
-embeddedTestSpecification
The -embeddedTestSpecificaion option specifies the name of the .EmbeddedTest file created
by ETPlanner that feeds forward embedded test specifications.
Syntax
-embeddedTestSpecification <fileName>
where fileName is a valid operating system file name.
Default Value
Default is LV_WORKDIR/<designName>.EmbeddedTest.
Usage Conditions
None
-etDefFile
The -etDefFile option specifies the name of the file that contains the embedded test default
settings. Typically, this file is defined by the central DFT group or ASIC vendor. It defines all
default settings for embedded memory and logic BIST, diagnostic settings, power settings, and
other general embedded test requirements.
Syntax
The syntax for this option is as follows:
-etDefFile <fileName>
-extension
where fileName can be any identifier that is a valid operating system character string defining a
filename or a complete pathname.
Default Value
None
Usage Conditions
If you have an ETDefFile that defines the EmbeddedBScanPortNaming wrapper, point to it

using the -etDefFile option when running ETAssemble with -genTemplate On. This enables the
generated .etassemble file to be automatically generated with your default
EmbeddedBScanPortNaming convention.
Example
This example instructs ETAssemble to read the specified .etDef file.
etassemble myDesignA -etDefFile ETCorp.etDef
-extension
The -extension option specifies the list of file extensions used in conjunction with the -y option.
These extensions define the order in which ETAssemble searches files within a Verilog library
directory to locate a module name.
Within a given library directory, ETAssemble tries to resolve a module name by sequentially
looking up file names composed of moduleName.extension. ETAssemble initially searches files
with the first extension, then files with the second extension, and so on.
Syntax
-extension <libExt1>:<libExt2>:<libExtN>...
where each libExt is a valid file extension.
Default Value
None
Usage Conditions
• This option is required when you specify a library directory with the -y option.
• Use colons (:) to separate multiple extensions.
-f
• Do not supply the period (.) separating the extension from the file name.
Example
The following syntax instructs ETAssemble to use the extensions scan and vb1 when searching
files within the Verilog library directory lib1. The search terminates when a file with the
extension .scan or .vb1, in that order, is found in the library lib1.
etassemble top coreBlock.v -y lib1 -extension scan:vb1
-f
The ETAssemble -f runtime option is used to specify the path of a command file containing
your Verilog design files. It might also contain standard Verilog options such as -y, -v, +incdir.
Each design file and option must be placed on a separate line.
The -f runtime option corresponds to the VerilogDashFFile ETPlanner property. See the
VerilogDashFFile property in the ETPlanner Tool Reference manual for complete information.
Syntax
-f <optionFileName>
where optionFileName is a valid operating system file name.
Default Value
None
Usage Conditions
• You can specify several option files by repeating the -f option multiple times. Note the
following:
• An option file must be an ASCII file where each option is specified on a separate line.
• Nested files can be specified as well.
Note
To point to files containing SystemVerilog RTL files to compile, use the -f_sv
option instead of the -f option.
-f_sv
Example
A sample command file entitled commandFile1 contains these lines:
../design/block1.vb
../design/block2.vb
-y ../vlogfileslib
-libext .vb
In this example, ETAssemble will forward commandFile1 directly to the compilation engine.
The file itself specifies where to find the Verilog modules block1.vb and block2.vb as well as the
Verilog library vlogfileslib.
etassemble myDesignA -f commandFile1
-f_sv
The ETAssemble -f_sv runtime option is used to specify the path of a command file containing
your SystemVerilog design files. It might also contain standard Verilog options such as -y, -v,
+incdir. Each design file and option must be placed on a separate line.
The -f_sv runtime option corresponds to the SystemVerilogDashFFile ETPlanner property. See
the SystemVerilogDashFFile property in the ETPlanner Tool Reference manual for complete
information.
Syntax
-f_sv <path to the file containing SystemVerilog design files>
Default
None
Usage Conditions
None
-flow
The -flow option allows you to specify if you are following the standard LV Flow and inserting
embedded test structures at the chip or block level or running ETAssemble to equip a sub-
module with boundary scan cells.
-flow
Syntax
-flow (chip) | block | EBScan
• chip — indicates that the embedded test structures are generated at the chip level.
• block — indicates that the embedded test structures are generated at a sub-block level.
The sub-block module is either a block or an ELTCore module.
• EBScan — indicates that you are running ETAssemble to insert boundary-scan cells
inside a sub-block.
Default Value
The default value is chip.
Usage Conditions
When -flow is set to block, ETAssemble can generate and insert the following test structures:
• A logicTest controller
• One or more memory BIST controllers
• A WTAP controller
When -flow is set to chip, ETAssemble can generate and insert the following test structures:
• Boundary scan cells

• An IEEE 1149.1-compliant TAP controller
• A logicTest controller for performing logic BIST
• One or more memory BIST controllers
When -flow is set to EBScan, ETAssemble generates and inserts the following test structures:
• Boundary scan cells

To insert boundary scan cells inside a Block or ELTCore module, you first run ETAssemble
with -flow EBScan to insert the boundary scan cells. Running ETAssemble with command
option -genTemplate On will create a template .etassemble and a Makefile to run ETAssemble
in -flow EBScan. Once you have completed the EBScan flow, you then run the normal LV Flow
to insert the rest of the Embedded Test structures with -flow block.
-fvScript
Example
The following syntax specifies to ETAssemble that it is operating at the chip level in the normal
LV Flow:
etassemble top coreBlock.v -flow chip
-fvScript
The -fvScript option specifies whether ETAssemble generates Formal Verification script files
for your design. The script files are created in the directory specified by the -outDir option
Syntax
-fvScript On | (Off)
Default Value
Usage Conditions
None
Example
The following syntax instructs ETAssemble to generate Formal Verification script files for your
design:
etassemble top coreBlock.v -fvScript On
-genPinTemplate
The -genPinTemplate option instructs ETAssemble to automatically create a starter template
for the input pin order list file.
Syntax
The following information specifies this option:
-genPinTemplate On | (Off)
• On — instructs ETAssemble to automatically create a .pinorder starter template that

contains a list of the top-level pins in the chip design. The top-level pins are the ports of
the top module. That module is selected as specified in the description of the -r option.
• Off — prohibits ETAssemble from creating a .pinorder starter template.
-genTemplate
Default Value
Usage Conditions
• Edit this file to define the boundary-scan groups, to specify the pins to the TAP, and to
specify clock pins in your design.
• Specifying the pin order list file as input to ETAssemble provides a more completely
filled-in .etassemble starter template.
• This option is valid only when -flow is set to chip.
Example
The following syntax instructs ETAssemble to create the top.pinorder starter template in the
current working directory.
etassemble top top.v -genPinTemplate On
-genTemplate
The -genTemplate option generates a starting .etassemble file to use in the EBScan (Embedded
Boundary Scan) flow. ETAssemble also generates a Makefile with available targets to generate
and verify your Embedded Boundary Scan implementation.
Syntax
-genTemplate On | (Off)
• On — instructs ETAssemble to generate a starting .etassemble file.

• Off — indicates to run ETAssemble in normal mode.
Default Value
Usage Conditions
When -genTemplate set to On, ETAssemble generates a starting .etassemble template for the
EBScan (Embedded Boundary Scan) flow as illustrated in Figure 3-5.
If you have an ICTechFile that you use with ETPlanner, point to it using the -ICTechFile
command-line option when running ETAssemble with -genTemplate On. This enables the
-genTemplate
Makefile to automatically point to your library files. If you do not have an available ICTechFile,
simply add the -y and -v options in the <designName>.f file you create to point to your design
files.
If you have a CADEnvFile that you use with ETPlanner, point to it using the -CADEnvFile
command-line option when running ETAssemble with -genTemplate On. This enables creation
of a simScript file consistent with your simulation environment.
If you have an ETDefFile that defines the EmbeddedBScanPortNaming wrapper, point to it

using the -etDefFile command-line option when running ETAssemble with -genTemplate On.
This enables the generated .etassemble file to be automatically generated with your default
EmbeddedBScanPortNaming convention.
Example
The following syntax specifies to ETAssemble to generate a starting block.etassemble file, a
Makefile, and a SimScript to be used in the EBscan flow. The generated files are illustrated in
Figure 9-1.
etassemble block -genTemplate On

-CADEnvFile <cadEnvFile> \
-etDefFile <etDefFile> \
-ICTechFile <ICTechFile>
-hdleInfo
Figure 9-1. Generated File When Using -genTemplate On
-hdleInfo
The -hdleInfo runtime option allows you to issue an information message for each
designAssemble insertion command executed by Tessent Editing Engine. The message echoes
the insertion command and its arguments. This option is used when you run ETAssemble from
the command line.
Syntax
-hdleInfo On | (Off)
-HDLwarningFilter
Default
Default is Off.
Usage Conditions
None
-HDLwarningFilter
The -HDLwarningFilter option specifies which level of messages are filtered during an
ETAssemble run.
Syntax
-HDLwarningFilter Off | Low | (High)
• Off — indicates that no messages are filtered during an ETAssemble run.

• Low — indicates that unimplemented RTL warning messages occurring during
compilation of VHDL packages are not filtered.
• High — indicates that all unimplemented RTL warnings are filtered.
Default Value
The default value is High.
Usage Conditions
None
Example
The following example specifies that no message filtering is used.
etassemble top coreBlock.v -HDLwarningFilter Off
-ICTechFile
The -ICTechFile option specifies the name of the file that contains all pointers to technology
files, simulation models, synthesis models, and library files, Siemens EDA LV models and
library files. Typically, this file is defined by the central CAD group.
-incDir
Syntax
-ICTechFile <fileName>
where fileName can be any identifier that is a valid operating system character string defining a
filename or a complete pathname.
Default Value
None
Usage Conditions
If you have an ICTechFile that you use with ETPlanner, point to it using the -ICTechFile
option when running ETAssemble with -genTemplate On. This enables the Makefile to
automatically point to your library files. If you do not have an available ICTechFile, simply add
the -v and -y options in the <designName>.f file you create to point to your design files.
Example
This example instructs ETAssemble to read the specified file ICTech13.ictech.
etassemble myDesignA -ICTechFile ICTech13.ictech
-incDir
The -incDir option specifies the name of a directory to be searched in resolving Verilog include
file names.
Syntax
-incDir <includeDirectoryName>
where includeDirectoryName is a valid operating system directory name.
Default Value
None
Usage Conditions
• If includeDirectoryName is specified as a relative path, it is assumed to be relative to the

directory in which you invoked ETAssemble.
-log
• An include file name which appears in a Verilog design file is resolved by first searching
the current directory and then searching the incdir directories in the order in which they
are specified.
• The -incDir option may be specified multiple times.
Example
In the following example, the configuration file is top.etassemble. The circuit file is
myDesign.v, and the -incDir option is specified twice:
etassemble top.etassemble myDesign.v -incDir \

myIncludeDir1 -incDir myIncludeDir2
An include file specified in myDesign.v is resolved by first searching the current directory. If it
is not found there, then the directory myIncludeDir1 is searched. If it is not found there, then the
directory myIncludeDir2 is searched.
-log
The -log option specifies the name of the log file generated by ETAssemble.
Syntax
-log <fileName>
where fileName is a valid operating system filename.
Default Value
The default file name is etassemble.log.
Usage Conditions
• If you do not specify a log file using the -log option, then ETAssemble writes the log file
to the output directory specified using -outDir as <outputDirectory>/etassemble.log.
• If you specify the -log option on the command line with only a file name without a
directory delimiter (/), then the log file is stored in the directory specified by -outDir. If
you specify a file name that contains directory delimiters (/), then the log file is stored in
the directory to which the -log option points.
Example
This example runs ETAssemble and generates a log file, etassemble.log in the out1 directory.
-lvlib
etassemble myDesign.v -log etassemble_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
etassemble myDesign ./etassemble.log
etassemble myDesign -outDir out out/etassemble.log
etassemble myDesign -log mylog ./mylog
etassemble myDesign -outDir work \
-log ../logdir/mylog ../logdir/mylog
etassemble myDesign -outDir work \
-log mylog work/mylog
-lvlib
The -lvlib option specifies the name of the VHDL library description file lvlib. You create the
lvlib file to map logical VHDL library names to physical paths. In this file, you also specify the
files contained in each logical library. The lvlib file is used to resolve names appearing in
VHDL architectures.
If your design contains VHDL files that must be compiled in accordance with the IEEE 1076-
1987 standard (VHDL-87), you must append _87 as a suffix to the library’s output path
specification as illustrated in Example 1.
Sometimes more than one library specification is required for a given library.
• If the same library contains both VHDL-87 and VHDL-93 files, at least two library
specifications are required for that library, and each must have a unique name. All files
within a particular library must have the same version.
• If your design has compilation dependencies across libraries or version dependencies
within a library, more than one library specification may be necessary for a given library
to preserve the required compilation order. Each library specification must have a
unique name.
When multiple library specifications are required for a particular library, the naming must
adhere to the following convention:
• One library name is considered the base name

• The other library names must be in the form
<baseName>_@MG_<unique_integer>
-lvlib
The library specifications are compiled in the order given. Refer to Example 2.
If your design has a mix of VHDL and Verilog (and/or SystemVerilog) and one or more VHDL
files are dependent upon Verilog files (that is, the Verilog files must be compiled before the
VHDL files which depend upon them), then those Verilog files must be listed with the
appropriate library and they must appear before the VHDL files which depend upon them.
Syntax
-lvlib <lvlibFileName>
where lvlibFileName can be any absolute or relative pathname that is a valid operating system
path specification.
Default Value
When defined, the following three lvlib files are always read by designExtract prior to reading
lvlib files specified on the command line with the -lvlib runtime option:
• Siemens EDA LV-defined default $LVLIBHOME/lvlib describes IEEE and Synopsys

libraries. Other lvlib files can override definitions in these libraries. If you do not specify
a lvlib file, $LVLIBHOME is automatically set to <lvision_install_dir>/lib/technology/
icbist/vhdl/lvlib when Siemens EDA tools are run.
• User-defined $HOME/lvlib, when it exists, describes libraries that are stable across
every project belonging to a user.
• User-defined $PWD/lvlib, when it exists, describes project-specific library data.
Usage Conditions
The -lvlib option is used by ETAssemble and the following ETAnalysis tools:
• designExtract
• designGrabber
• ruleAnalyze
• scanGenerate
ETPlanner automatically creates the lvlib file. However, you must create the lvlib manually if
you are running ETAssemble standalone (without running ETPlanner).
-macroSynthesis
Example 1
The file ./myLvlibFile is a VHDL library description file that contains the following text:
topLib => ./topLib

extLib => ./extLib_87 // The suffix “_87” indicates that the files in the
// library need to be compiled using the 87
// compiler.
topLib <= ./*.vhd ./*.vhds

extLib <= ./ext/*.vh ./ext/*.vhd
work := topLib
The following syntax sets ./myLvlibFile as the name of the lvlib file that the ETAssemble tool
uses.
etassemble -lvlib./myLvlibFile
Example 2
In the following example, library liba contains a file on which library libb depends, and another
file that depends on files in library libb. In other words, the two libraries have cross
dependencies. The files for library liba, therefore, must be split into two parts, each with a
unique library name. The two parts will be merged into the same library (liba) as long as the
naming convention (described earlier) is followed. The library specifications are compiled in
the order specified.
// The following is the first specification for library liba.

liba => ./liba
liba <= ./file1a.vhd
libb => ./libb

libb <= ./file1b.vhd
// The following is the second specfication for library liba and

// will be merged into library liba at compilation time.
liba_@MG_1 => ./liba_@MG_1
liba_@MG_1 <= ./file2a.vhd
libc => ./libc

libc <= ./file1c.vhd
work := libc
-macroSynthesis
The -macroSynthesis option turns the SYNTHESIS macro on or off. By default, the macro is
on. Use this option to turn off the macro.
-mfcu
Syntax
-macroSynthesis (On) | Off
Default
Default is On.
Usage Conditions
None.
-mfcu
The -mfcu option is used to indicate whether the SystemVerilog design files listed in a -f_sv
option command arguments file are to be treated as one multi-file compilation unit (on) or as
individual compilation units (off). The option is on by default. Use this option to turn off
multi-file compilation.
Syntax
-mfcu (On) | Off
Default
Default is On.
Usage Conditions
Use this option (-mfcu off) when you want the scope of an import statement (or other statements
declared outside any module declaration) to be limited to the file in which it appears.
-modifiedExtension
The -modifiedExtension option specifies the extension that ETAssemble appends to output
files containing the top-level assembly of the chip and the generated design objects.
Syntax
-modifiedExtension <modifiedExtension>
where modifiedExtension is a valid operating system character string.
-outDir
Default Value
None
Usage Conditions
Do not confuse -modifiedExtension option with the -extension option:
• -extension specifies the extensions that ETAssemble checks when searching design
files.
• The -modifiedExtension option specifies the extension that ETAssemble appends to the
modified output netlist filenames.
Example
This syntax example adds the extension _et to ETAssemble output files.
etassemble myeta myDesign.v -modifiedExtension _et
-outDir
The -outDir option identifies the directory in which ETAssemble places all output files for the
design objects. ETAssemble also generates a top-level assembly file consisting of your original
design and the generated design objects. This assembly file is written to the same directory as
the location of the original design netlist.
Syntax
-outDir <directoryName>
where directoryName can be any identifier or path name that is a valid operating system
character string.
Default Value
The default output directory is the directory from which you invoked ETAssemble.
Usage Conditions
If you specify a directory that does not exist, ETAssemble creates the directory.
Example
In this syntax example, ETAssemble creates the directory Run1 and stores all ETAssemble
output files in Run1. The final assembly file top.v_etassemble is written out to the directory
design, since that is where the original netlist is located.
etassemble top design/top.v -outDir Run1
-padLibrary
-padLibrary
The -padLibrary option specifies the name of the pad library file that defines the pads in your
design.
Syntax
-padLibrary <fileName>
where fileName can be an actual file path specification or a file that can be located using the
paths specified with the -y option.
Default Value
The default file name is pad.library in the current working directory.
Usage Conditions
• If you did not specify -padLibrary, ETAssemble looks for the default pad library file
pad.library in the search path you specified using the -y command line option.
• This option can be repeated to read in multiple pad library files.
• If a cell is declared more than once in the same pad library, ETAssemble issues a
warning. However, if the same cell is declared in a subsequent pad library file, then the
last declaration overrides all others.
Examples
This syntax example specifies the pad library file, myPadLibrary.lib, which is in the ../libs/
directory.
etassemble top top.v -padLibrary ../libs/myPadLbrary.lib
-pinOrderInfoFile
The -pinOrderInfoFile option specifies whether or not ETAssemble should read the
.pinOrderInfo file created by ETPlanner to automatically fill in the PinName column of the
.pinorder file.
Syntax
-pinOrderInfoFile <fileName>
where fileName can be any valid operating system filename, with or without the absolute path.
-pinOrderList
Default Value
None
Usage Conditions
• This option is used only in conjunction with -genPinTemplate On and -flow chip.
• ETPlanner creates the .pinOrderInfo file only if you specify a DEF file that contains pin
ordering information. See the -defFile option in ETPlanner Tool Reference for more
information.
Examples
The following syntax specifies the .pinOrderInfo file, top.pinOrderInfo, which is in the ../
etCheckInfo directory:
etassemble top top.v -genPinTemplate On -pinOrderInfoFile \

../../etCheckInfo/top.pinOrderInfo
-pinOrderList
The -pinOrderList option specifies the name of the pin order file that defines the pin names
and pin numbers of the design.
Syntax
-pinOrderList <fileName>
where fileName can be any valid operating system filename, with or without the absolute path.
Default Value
If you did not specify -pinOrderList, ETAssemble looks for the default pin order file
<designName>.pinInfo in the current working directory. If the default file
<designName>.pinInfo cannot be located, ETAssemble creates a default pinInfo file using the
information extracted from your design netlist.
Usage Conditions
None
Examples
The following syntax specifies the pin order file, myPinorder.pinInfo, which is in the ../../
etCheckInfo directory.
-pragma
etassemble top top.v -pinOrderInfoFile \

../../etCheckInfo/myPinorder.pinInfo
-pragma
The -pragma option specifies a prefix for synthesis pragmas.
Syntax
-pragma <pragmaName>
where pragmaName is the prefix for the synthesis pragma.
Default Values
The following default values apply: mentor, synopsys, pragma.
The same default values apply both for Verilog and VHDL languages; you do not need to
specify default separately.
Usage Conditions
• Typically, <pragmaName> translate_off and <pragmaName> translate_on are used to

surround HDL code that is not to be synthesized by Synopsys synthesis tools. The
ETAssemble tool skips over such code during parsing.
• This option can be specified multiple times.
• Use the -pragma nopragma option to disable all synthesis pragmas.
Example
In this example, the syntax specifies to ETAssemble the prefix to use for synthesis pragmas. A
block of code that begins mypragma translate_off with and ends with mypragma translate_on is
skipped during parsing.
etassemble myDesign.v -r top -pragma mypragma
-r
The -r option specifies the name of the top-level Verilog module of the design.
Syntax
-r <topModuleName>
-rtlExtension
where topModuleName is a Verilog identifier.
Default Value
If you do not specify the -r option, the first module or entity declaration name located in the
source files specified on the command line is used as the top. The ETAssemble tool searches
these source files from left to right.
Usage Conditions
topModuleName must refer to a module or an entity declaration contained in a source file or in a
file that is specified by a file compilation rule appearing in the lvlib file. This file compilation
rule must be specified for the logical library designated as WORK.
Example
This example sets blocka as the top-level module.
etassemble top top.v -r blocka
-rtlExtension
The -rtlExtension option specifies the extension that ETAssemble adds to the RTL code files it
generates.
Syntax
-rtlExtension <extension>
where extension can be any valid operating system character string.
Default Value
The default file extension is vb.
Usage Conditions
None
Example
The following syntax instructs ETAssemble to append the extension vb1 to all RTL code files.
etassemble top top.v -rtlExtension vb1
-stopMod
-stopMod
The -stopMod option specifies the names of one or more of the modules/entities that will be
treated as a black box during the design data extraction phase of ETAssemble.
Syntax
-stopMod <moduleName1>:<moduleName2>...
where each moduleName is a Verilog identifier.
Default Value
None
Usage Conditions
ETAssemble extracts design data from the input netlist to trace the connections between the top-
most design blocks and the I/O pads. In some cases, it can be necessary to treat some modules in
the netlist as black boxes, so that the extraction does not see the hierarchy below that specified
module. This option can be used in such cases.
Example
The following syntax instructs ETAssemble to treat the module block1 as a black box.
etassemble top top.v -stopMod block1
-structuralExtension
The -structuralExtension option specifies the extension that ETAssemble adds to the write
commands in the synthesis script files that it creates.
Syntax
-structuralExtension <extension>
where extension is a valid operating system character string.
Default Value
The default file extension is vb.
-timingscript
Usage Conditions
In the synthesis script generated by ETAssemble, the Synopsys dc_shell reads in the RTL
design file that has the extension specified by -rtlExtension. The dc_shell then writes the gate-
level design file using the extension specified by the -structuralExtension option.
Example
In the following syntax, ETAssemble inserts the extension vb1 into the write command in the
synthesis script.
etassemble top top.v -structuralExtension vb1
-timingscript
The -timingscript option instructs ETAssemble to generate the timing files (SDC and STA).
Syntax
-timingscript (Off) | On
• Off — instructs ETAssemble not to generate the timing files (SDC and STA).
• On — instructs ETAssemble to generate the timing files (SDC and STA).
Default Value
Usage Conditions
None
Example
In this example, ETAssemble generates timing files for myDesign.
etassemble myDesignFile.v -timingscript Off
-userLib
The -userLib option specifies the name of a library file containing descriptions of custom
boundary scan cells, or other cells needed by ETAssemble.
-v
Syntax
-userLib <fileName>
where fileName is a valid operating system character filename.
Default Value
None
Usage Conditions
• Repeat this option for each library file that you want ETAssemble to read.
• Specify this option if you require ETAssemble to use custom cells. When this option is
not specified, ETAssemble uses Siemens EDA-defined boundary-scan cells as needed.
Example
This example instructs ETAssemble to use a custom library file named mybcells.lvbscan.
etassemble top top.v -userLib mybcells.lvbscan
-v
The -v option adds the name of a Verilog library file to the search path that ETAssemble uses
for resolving names appearing in Verilog modules.
Syntax
-v <libraryFileName>
where libraryFileName is a valid operating system file name.
Default Value
None
Usage Conditions
• ETAssemble resolves names in module instantiation statements by searching through

libraries specified with the -v and -y options in the order in which they are specified; that
is, ETAssemble searches from first to last, or left to right, on the command line.
-y
In a library file, all modules in the file are potential candidates for resolving a name
appearing in Verilog modules.
• ETAssemble accepts multiple library file names. Precede each file name with the -v
option.
• Unless you specify a directory path preceding libraryFileName, ETAssemble searches
for the specified file in the directory in which you invoked ETAssemble.
Example
In this example, ETAssemble loads the source file top.v and searches the library file block1.vb
for any unresolved name bindings.
etassemble top top.v -v block1.vb
-y
The -y option adds the name of a Verilog library directory to the search path that ETAssemble
uses for resolving names appearing in Verilog modules.
Syntax
-y <libraryDirectoryName>
where libraryDirectoryName is a valid operating system directory name.
Default Value
None
Usage Conditions
• If you are using Siemens EDA tools for scan test, logic BIST, or both, you must specify
that -y point to the location where you ran the LV Flow on each of your core modules.
This points ETAssemble to the .scaninfo file generated by ruleAnalyze during the LV
Flow phase.
• Names in module instantiation statements are resolved by searching through libraries
specified with the -v and -y options in the order in which they are specified; that is, from
first to last, left to right on the command line.
• In a library directory file, only the module whose name is the same as the file name is a
potential candidate for resolving a name located outside the file.
• For resolving a name located inside a library directory file, ETAssemble first checks for
a match with a Verilog or Siemens EDA LV primitive. If no match is found, the tool
-yvhdl
checks the other modules in the file for a potential match. If there is no match, then
ETAssemble checks the source files followed by the normal library search.
• The ETAssemble tool accepts multiple library directory names. Precede each directory
name with the -y option.
• You must use -extension in conjunction with this option.
• A library directory file should contain at least one module or UDP; it can contain a
complete hierarchy as long as its top module has the same name as the file.
-yvhdl
The -yvhdl option adds the name of a VHDL logical library to the search path that the tool uses
for resolving names appearing in Verilog modules. This feature enables the binding of Verilog
module instances to VHDL entity declarations.
Syntax
-yvhdl <vhdlLibraryName>
where vhdlLibraryName is a VHDL logical library name.
Default Value
None.
Usage Conditions
• These search directives specify the names of libraries described in one or more lvlib
files. They are referred to as logical libraries to distinguish them from library files and
library directories.
• You can intermix -yvhdl search directives with -v and -y search directives.
• The tool resolves names in Verilog module instantiation statements by searching
libraries indicated by the -v, -y, and -yvhdl options in the order they are specified; that
is, from first to last, or left to right, on the command line.
• You must also define the value of the -yvhdl option (the VHDL library) as a logical
library name in an lvlib file (library description file).
Example
In this example, top is the design’s top-level module or design entity. It must reside in
myDesign.v or in the library which is designated as WORK in the lvlib file $project/
lvlib.project.
Language Options
designe myDesign.v -r top -v mod1.v \

-yvhdl extLib -lvlib $project/lvlib.project
The tool resolves names in Verilog files as follows:
• It first checks for a match with a Verilog or Siemens EDA LV primitive.

• If no match is found, the tool searches the top.v source file, then the library file mod1.v.
All modules in mod1.v are visible.
• If a match still is not found, the tool checks the VHDL library extLib. All VHDL design
entities from extLib are searched in a case-insensitive manner.
The tool resolves names in VHDL files by searching the VHDL libraries specified in the
appropriate use clauses.
Language Options
The following language options can be used while running ETAssemble:
• +define+
This option defines variable names as empty text or as string macros throughout the
compilation process (global macros). This option is equivalent to -define in
functionality, but the syntax and usage are different.
The +define+ option has the following syntax when it defines a macro name as empty
text:
+define+<macro_name>
• The +define+ plus option has the following syntax when it defines a macro name as a
string:
+define+<macro_name>="<macro_string>"
• The number of +define+ plus options on the command line is unlimited. As well, several
definitions can be done in a single +define+ option by inserting a ‘+’ between each
definition. For instance:
+define+useSpecialGates+specialPortWitdh=64+specialGateType=”OR333”
• is equivalent to having several +define+ on the command line:

+define+useSpecialGates +define+specialPortWitdh=64 \
+define+specialGateType=”OR333”
Language Options
Note
If you define the same macro name differently in a command-line +define+ plus
option and a `define compiler directive, the command-line plus option overrides the
compiler directive.
• +incdir +
The +incdir+ option specifies the directories that the tool searches for the files that you
have specified with the `include compiler directive. This option is equivalent to -incDir
in functionality, but the syntax and usage are different.
The +incdir+ option has the following syntax:
+incdir+<directory1>+<directory2>+...<directoryN>
• There is no limit to the number of +incdir+ options that you can specify. The tool
searches for these directories in the order in which you list them on the command line.
Note
The tool does not check the characters between the two plus characters for errors. It
assumes that all of these characters are part of the directory name.
• +libext+
The +libext+ option specifies library directory file extensions. This option is equivalent
to -extension in functionality, but the syntax is different.
The +libext+ option has the following syntax:
+libext+<string1>+<string2>+...<stringN>
• To specify a library directory file extension, you put +libext+ in the command-line
followed immediately by the characters that make up the extension, as demonstrated in
the following example:
rulea source1.v -y /usr/me/proj/lib/cmos +libext+.v+
Note
Only extensions beginning with a dot (‘.’) are supported.
Chapter 10
Output Files for ETAssemble
The Siemens EDA ETAssemble tool creates multiple output files that serve as input to other
Siemens EDA tools. Chapter topics follow this sequence:
Summary of Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Output Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Design Summary File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Boundary Scan Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
TAP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Logic Test Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Memory BIST Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Diagnostic Interface File (DIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
WTAP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
TimingGen Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
fvGenerate Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Summary of Output Files

ETAssemble generates multiple output files, as the sections below detail. For full filenames,
except output log files, the chip design name precedes the extension—for example,
<chipDesignName>_LVISION_LOGICTEST.config
In the RTL filenames given below, the default values for the extension ext are as follows: v for
Verilog.
Output Netlist
The output design netlist consists of a modified Verilog description of the design that can
include boundary-scan cells, an IEEE 1149.1-compliant TAP controller, a logicTest controller,
and other embedded test objects—depending upon the chosen options. You need to run this
netlist through a logic synthesis tool for technology mapping and optimization.
Log File
Log File
The log file lists the values of all runtime options you selected for the ETAssemble run. The log
file also lists the filenames of the generated files and includes any error messages. The default
name is etassemble.log, and the default directory is the directory from which you launched the
tool unless you specify otherwise.
Pin Order List File

ETAssemble automatically extracts the top-level pin information from your design netlist and
stores this information in the pin order list file. You then edit this file to identify the types of
top-level pins in your netlist.
Design Summary File

This file contains a summary of what has been inserted in the design. The file is located at
LV_WORKDIR/<designName>.summary, a copy of the file will also be stored in the LVDB
when it is generated. The design summary file contains information such as the BistPort
assigned to each controller, the clocks used and their frequencies, the memories tested, etc.
Figure 10-1 shows the syntax within the DataForPhysicalRegion wrapper. This wrapper will
be present for each Top, ELTCore, or Block module in the design. If the physical region
contains a TAP/WTAP then the TapController wrapper will be present with a BistPort
wrapper for each controller connected to the TAP/WTAP.
Figure 10-1. DataForPhysicalRegion Wrapper Syntax
DataForPhysicalRegion (<relativeInstancePathToPhysicalRegion>) {
Type: TOP | ELTCore | Block;
ModuleName: <moduleName>;
TapController {
Instance: <instanceName>;
BistPort (BP# | WBP#) {
<controllerSpecificInformation>
}
}
Figure 10-2 shows the syntax used in the BistPort wrapper for a logicTest controller. The
ShiftClockController wrapper contains the shift clock sources and their respective frequencies.
A BurstClockController wrapper will be created for each BCC inserted in the physical region
and it will show all of the hierarchical pins where the BCC injected a clock and their respective
frequencies.
Design Summary File
Figure 10-2. BistPort Wrapper Syntax for a LogicTest Controller

ControllerType: LogicTest;
ShiftClockController {
ShiftClockSource1: <relativeHierarchicalPin>;
ShiftClockSource2: <relativeHierarchicalPin>;
ShiftClockSource1Freq: <freqInMHz>;
ShiftClockSource2Freq: <freqInMHz>;
DefaultShiftClockSource: ShiftClkSrc1 | ShiftClkSrc1/2 | ...;
}
}
BurstClockController (#) {// Repeatable
Instance: <BccInstance>;
SyncClockGroup: <syncGroupId>;
TestClockSource: <relativeHierarchicalPin>;
ClockDomainLabelList: <clkDomainLabel1>, <clkDomainLabel2>, ...;
InjectPin (<relativeHierarchicalPin>) {// Repeatable
FreqRatioRelToGroup: 1.0 | 0.5 | 0.25;
Frequency: <freqInMHz>;
}
}
Figure 10-3 shows the syntax used in the BistPort wrapper for a memory BIST controller. All
of the Step’s run by the controller will be shown along with all the memory instances and their
respective collar instances.
Figure 10-3. BistPort Wrapper Syntax for a Memory BIST Controller

ControllerType: ETMemory_SoftProg | ETMemory_HardProg;
BistClkConnection: <hierarchicalPin>;
BistClkFrequency: <freqInMHz>;
ReferenceClock: <PinOnPhysicalRegionSourcingBistClk>;
ReferenceClockInv: <DifferntialPinOnPhysicalRegionSourcingBistClk>;
ReferenceClockFrequency: <freqInMHz>;
Step (#) {// Repeatable
MemoryInstance: MEM#; // Repeatable
MISR: MEM#; // Repeatable
}
MemoryCollar (MEM#) {// Repeatable
CollarModuleName: <moduleName>;
MemoryModule: <moduleName>;
MemoryInstance: <hierarchicalInstanceName>;
CollarInstance: <hierarchicalInstanceName>;
}
}
Boundary Scan Files
Boundary Scan Files

ETAssemble generates the following files during the boundary-scan generation phase:
• _LV_CELLS.blib — Library entries for Siemens EDA boundary-scan cells
• _LV_CELLS.ext — Verilog RTL for all Siemens EDA boundary-scan cells used in this
design.
• .bsdl — BSDL information for the design.
• _LV_BGROUP_synthesis.script — Synthesis dc_shell script start-up shell script.
• _LV_BGROUP.synopsys_tcl — Tcl synthesis script for all bgroups that the Synopsys
Design Compiler processes.
• _LV_BGROUP_synthesis.script_tcl — Tcl synthesis script start-up shell script.
• _LV_BGROUP_<bgroupName>.ext — RTL file for bgroup where bgroupName is the
side name as specified in the input pin order list file or in the .etassemble configuration
file.
• _LV_BSCAN.designa — file providing the boundary-scan cell assembly instructions to
ETAssemble during the final assembly phase.
TAP Files
ETAssemble generates the following files during the TAP controller generation phase:
• _LVISION_JTAP.ext — Verilog RTL description of the TAP controller.
• _LVISION_JTAP.designa — File providing the TAP assembly instructions to
• _LVISION_JTAP_STRAP.ext — Verilog file for wiring the device ID.
• _LVISION_JTAP.config — Configuration file of the TAP controller that ruleAnalyze
requires as input for final, chip-level rules checking.
• _LVISION_JTAP.synopsys_tcl — Tcl synthesis script for the TAP controller that the
Synopsys Design Compiler processes.
• _LVISION_JTAP_CLK_MUX.designa — File providing assembly instructions to
• _LVISION_JTAP.gtool_info — Information file used by designExtract.
Logic Test Files
Logic Test Files

ETAssemble generates the following files during the logicTest controller generation phase:
• _LVISION_LOGICTEST.gtool_info — Information file used by designExtract.
• _LV_SHIFT_CLK_CTRL.ext — File containing the RTL description of the shift clock
controller. Synopsys requires this file as input.
• _LV_BURST_CLK_CTRL_BL#.ext — File containing the RTL description of a
synchronous burst clock controller, where # indicates its burst length. Synopsys requires
this file as input.
• _LV_BURST_CLK_CTRL_SYNCxy_BL#.ext — File containing the RTL description
of a synchronous burst clock controller, where # indicates its burst length and xy
indicate the frequency ratios of the synchronous clocks. The value of xy can be 2, 4, or
both. Synopsys requires this file as input.
• _LV_SE_CTRL_BL#.ext — File containing the RTL description of the scanEnable/
clockEnable controller, where # indicates the supported burst length of the scanEnable/
clockEnable controller. Synopsys requires this file as input.
• _LVISION_LOGICTEST.config — Configuration file of the logicTest controller that
ruleAnalyze requires as input for rules checking. During the ETVerify step, ruleAnalyze
uses this file when the tool performs final, chip-level rules checking.
• _LVISION_LOGICTEST.ext —File containing the RTL description of the customized
logicBIST controller. Synopsys requires this file as input.
• _LVISION_LOGICTEST.designa — File providing the logicTest assembly instructions
to ETAssemble during the final assembly phase.
• _LVISION_LOGICTEST.synopsys_tcl — Tcl synthesis script for logicBIST controller
that the Synopsys Design Compiler processes. This script is automatically invoked by
the ETAssemble-generated top-level synthesis script to create a gate-level version of
your logicTest controller.
• _LVISION_DIRECTSCAN_MUXES.ext — File containing the RTL description on the
multiplexers for direct scan ATPG mode. Synopsys requires this file as input.
Memory BIST Files

Depending on the runtime options you select, Tessent MemoryBIST can produce the following
output files:
• RTL code files
• Files for the ETAnalysis tools
• Files for ETVerify
Memory BIST Files
• Diagnostic Interface file (DIF)

The following table lists each LV Flow output file, provides brief descriptions of each file, and
lists the runtime options necessary to create a given output file.
Table 10-1. LV Flow Output Files for Memory BIST
Output File Name Prefix is Description Conditions Upon
<configFileName>_ Generating
cntrl.ext RTL code for the memory
BIST controller
LVISION_MBIST_NTC_FLOP.ext No timing check flip-flop
LVISION_MBIST_RETIMING_CELL. Negative clock edge retiming
ext flip-flop
<InstName1>_collar.ext RTL code for the collared
...<InstNameN>_collar.ext(One file memories
per instance in the LV Flow
configuration file)
<InstName1>_collar_straps.ext RTL code for the straps for
...<InstNameN>_collar_straps.ext(On MISR compare value for a
e file per ROM instance in the LV ROM
Flow configuration file)
assembly.ext RTL code for the assembly
containing the memory BIST
controller and collared
memories
<InstName1>_collar.synopsys_tcl Synthesis constraints for the -genSynthesisScript
..<InstNameN>_collar.synopsys_tcl memory collar in Synopsys All | TCL
Design Compiler Tcl syntax
assembly.synopsys_tcl Synthesis constraints for the -genSynthesisScript
memory controller in Synopsys All | TCL
Design Compiler Tcl syntax
assembly.tcm Test Connection Map for the
memory assembly
*.designa SoftProgrammable
and
HardProgrammable
controllers
cntrl.lvmcp List of all flip-flops in the UseMultiCyclePaths:
memory BIST controller that Yes;
source data into multi-cycle
paths. This file is used by the
ETAnalysis tools
Diagnostic Interface File (DIF)
Table 10-1. LV Flow Output Files for Memory BIST (cont.)

Output File Name Prefix is Description Conditions Upon
<configFileName>_ Generating
<InstName1>_collar.lvmcp List of all flip-flops in the UseMultiCyclePaths:
...<InstNameN>_collar.lvmcp(One file memory collars that source Yes;
per instance in the memory BIST data into multi-cycle paths.
configuration file) These files are used by the
ETAnalysis tools
<memoryCellName1>.scan Scan module for the memories
...<memoryCellNameN>.scan(One file required by the ETAnalysis
per memory cell that maps to an tools
instance. File names are not prefixed
with <configFileName>_)
cntrl.gtool_info Information file used by the
tools in the LV Flow

The Diagnostic Interface file (DIF) provides enough information to the fail data decoder to
process the memory BIST fail data file. The file gives a detailed account of the algorithm flows
that are applied to each of the memories. These details provide enough information to map a
cycle number to a particular memory, algorithm phase, address, and bit.
A complete description of the DIF properties and property wrappers follows Figure 10-4 on
page 486.
Figure 10-4. Example of Diagnostic Interface File (DIF) Syntax
Chip(<chipName>) {
MemoryController (<controllerID>) {
Initialization {
NumberOfCycles: x;
}
Step (<stepNum>) {
Memory (<RAMInstName>) {
} //end of Memory wrapper
.
. //repeat for each memory tested
.
TestPort (<testPortId>) {
AlgorithmPhase (<phaseID>) {
NumberOfCycles: x; RowAddress { Begin: x; End: y;
ColumnAddress { Begin: x; End: y; MemoryBit { Begin: x; End: y;
NumberOfCycles: x; ExpectedValuePolarity: VerilogExpression; if
(VerilogExpression) { NumberOfCycles: x; ExpectedValuePolarity:
VerilogExpression; } elseif (VerilogExpression) { NumberOfCycles: x;
ExpectedValuePolarity: VerilogExpression; } elseif ...
... else { NumberOfCycles: x;
ExpectedValuePolarity: VerilogExpression; } } //end of MemoryBit wrapper
} //end of ColumnAddress wrapper
} //end of RowAddress wrapper
} //end of AlgorithmPhase wrapper
. . //repeat for each algorithm phase
. } //end of TestPort wrapper
. . //repeat for each test port
. } //end of Step wrapper
. . //repeat for each controller step
. } //end of MemoryController wrapper
. } //end of Chip wrapper
DIF Properties and Wrappers

The following sections describe the DIF properties and property wrappers shown in Figure 10-4
on page 486.
Chip Wrapper
This is the top-level wrapper that encloses all properties and property wrappers for the chip
being tested. chipName is optional and typically refers to an ASIC design name.
MemoryController Wrappers
A chip can contain several memory BIST controllers. Therefore, separate wrappers are needed
to describe the memories and algorithms associated with each controller. controllerIDs are used
to number the controllers in the order that they are accessed during the chip test. When a TAP is
used, the controllerID corresponds to BIST ports.
Step Wrapper
This wrapper contains necessary information about the algorithm that is applied to the current
memory within a given BIST controller step. It provides enough information to map a failing
cycle number to a particular test port, algorithm phase, address, and memory bit.
Memory Wrappers
Each controller can test several embedded memories. Each RAMInstName value identifies a
memory by its design instance name.
TestPort Wrapper
Complete test algorithms are applied to memories on a per-test-port basis. This wrapper
provides the necessary test port distinction. The testPortId value provides for a cross-reference
to physical memory ports.
NumberOfCycles Property
This property specifies a relative clock cycle count. The nested wrappers within the
AlgorithmPhase wrapper essentially describe a nested looping description of the algorithm.
Each encounter of the NumberOfCycles property within any wrapper describes the number of
clock cycles to add to the running clock cycle count.
AlgorithmPhase Wrapper
You use this wrapper to separately define each algorithm phase. Different phases can have
different address sequences and might apply different patterns. The phaseID value identifies the
algorithm phase number described in Memory BIST Algorithms of the Tessent MemoryBIST
RowAddress Wrapper
You use this wrapper to describe the row address sequence within the current algorithm phase.
Note that the nesting of the RowAddress and ColumnAddress wrappers can be interchanged
to accommodate a fast row c or fast column counting sequence.
Begin Property
This property appears in the ColumnAddress, RowAddress, and MemoryBit wrappers.
Depending on the wrapper in which it appears, this property specifies either the starting column
address, row address, or bit value.
End Property
This property appears in the ColumnAddress, RowAddress, and MemoryBit wrappers.
Depending on the wrapper in which it appears, this property specifies either the ending column
address, row address, or bit value.
WTAP Files
ColumnAddress Wrapper
You use this wrapper to describe the column address sequence within the current algorithm
phase. Note that the nesting of the RowAddress and ColumnAddress wrappers can be
interchanged to accommodate a fast row-counting sequence.
MemoryBit Wrapper
You use this wrapper to describe the bit sequence within the current algorithm phase. An if-
elseif construct is available to specify different NumberOfCycles and ExpectedValuePolarity
property values based on Verilog logical expressions defined in terms of the column address,
row address, and memory bit iteration. If the number of cycles within the memory bit sequence
extends beyond the number of bits in the data word, then the extra cycles are applied to the
MSB of the word.
ExpectedValuePolarity Property
This property specifies the expected bit value at each MemoryBit iteration. This property value
can be expressed as a Verilog logical expression defined in terms of the column address, row
address, and memory bit iteration.
WTAP Files
When you run ETAssemble to insert a WTAP, several additional WTAP-related design files are
created as described in the following table
.
Table 10-2. ETAssemble WTAP-Related Design Files
File Name Description Options Affecting the
Generation
RTL Files:
<designName>_LVISION_WTAP.e Verilog RTL description of the Generated when the WTAP
xt WTAP controller. wrapper is present in the
.etassemble file.
<designName>_LVISION_WTAP Verilog RTL for wiring the Generated when the DevID
_STRAP.ext device ID outside the WTAP. property is set to On in the
.etassemble file.
<designName>_LVISION_WTAP_ Verilog RTL description of Generated when the
AUX_PORT.ext auxiliary port muxing circuit. AuxiliaryTestPort wrapper
is present in the .etassemble
file.
Synthesis Scripts:
TimingGen Files
Table 10-2. ETAssemble WTAP-Related Design Files (cont.)

File Name Description Options Affecting the
Generation
<designName>_LVISION_WTAP. Tcl synthesis script for the Generated when the WTAP
synopsys_tcl WTAP controller that Synopsys wrapper is present in the
Design Compiler processes. .etassemble file
<designName>_LVISION_WTAP csh script that launches Generated when the WTAP
_synthesis.script Synopsys Design Compiler wrapper is present in the
with the script mentioned .etassemble file.
above.
Gate-Level Files:
<designName>_LVISION_WTAP. Verilog Gate description of the Generated when the WTAP
ext WTAP controller generated by wrapper is present in the
the synthesis tool. .etassemble file.
Files for Siemens EDA LV Tools:
<designName>_LVISION_WTAP. Configuration file of the WTAP Generated when the WTAP
config controller that ruleAnalyze wrapper is present in the
requires as input for rule .etassemble file
checking at higher hierarchy
level.
<designName>_LVISION_WTAP. File providing the WTAP Generated when the WTAP
designa assembly instructions inside the wrapper is present in the
collared core .etassemble file.
<designName>_LVISION_AUX_P File providing the assembly Generated when the
ORT.designa instruction for the auxiliary port AuxiliaryTestPort wrapper
muxing circuit inside the is present in the .etassemble
collared core file.
<designName>_LVISION_WTAP. Information file that describes Generated when the WTAP
gtool_info the WTAP controller. This file wrapper is present in the
serves as input to ruleAnalyze, .etassemble file.
designExtract, and ETVerify.
<designName>.wtap Intermediary configuration file Generated when the WTAP
used to create most of the files wrapper is present in the
listed in this table. .etassemble file.
TimingGen Files
Optionally, when using the -timingscript runtime option ETAssemble generates a TimingGen
file.
This is described in more detail in Timing Constraints and Clock Tree Synthesis.
fvGenerate Files
fvGenerate Files
Optionally, when using the -fvScript runtime option, ETAssemble generates as well formal
verification files.
This is described in more detail in the “Formal Verification With Embedded Test” in the LV
Flow User’s Manual.
Appendix A
Adding a User Data Register to the
Boundary-Scan Chain
Tessent BoundaryScan enables you to include user data registers as part of a boundary-scan
chain. You also can use this capability with the multiple bonding option feature to support
different configurations where user data registers can be switched in and out.
The ability to add a user data register to the boundary-scan chain addresses the requirements of
some customers for low pin count access (JTAG only for packaged devices), high reliability,
and low area. Low-area requirements necessitate a single TAP implementation as opposed to a
multiple-TAP technique.
Background and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Background and Overview

Tessent BoundaryScan handles existing boundary-scan segments through the .lvbscan file
mechanism.
A .lvbscan file describes the existing boundary scan hardware in a module that is instantiated
one or more times into the design. This file also describes the boundary-scan segments inside
the module and the ports to access these segments. Then ETAssemble hooks up the boundary-
scan segments into the newly created boundary-scan register and describes the parts in the
BSDL file. It is assumed that the functional connections of the user data register already exist or
that they will be made later in the flow.
The .lvbscan file syntax has always had the ability to describe internal cells, but a segment
consisting only of internal cells is ignored.
Tessent BoundaryScan uses the .pinorder file to determine the position of the segment in the
boundary-scan register.
The tracing in the PadExtractor determines the relationship between the top-level pins and the
existing boundary-scan segments. This works for all segments that have at least one non-
internal boundary-scan cell because a non-internal boundary-scan cell needs a connection to the
top via a pad cell.
For segments containing only internal cells, Tessent BoundaryScan needs additional
information to know where the segment should be in the boundary-scan register. You must use
the .etassemble configuration file wrapper, InternalBScanSegment, to provide this information.
Adding a User Data Register to the Boundary-Scan Chain
Limitations
If you want to bypass the register using the multiple bonding option feature, the register must be
in its own boundary-scan group. Because this boundary-scan group cannot be specified in the
.pinorder file or in the Sides wrapper of the .etassemble configuration file, you must use the
property, DedicatedBGroupName, to specify this information. If the information is not
provided, the register will go into the boundary-scan group of the pin that precedes the user data
register in the boundary-scan register.
Limitations
You must provide a .lvbscan file that describes your user data register. The register must behave
like a segment of internal boundary-scan cells.
Index
-- in comments, 21 appending to the end of a line, 20, 21

Index
including in your input files, 20, 21

— Symbols —
_LV_BGROUP_.ext, 482 —D—
_LV_CELLS.ext, 482 Tick: Dataproperty, 251
_LVISION_JTAP.ext, 482, 483 DataOutStageproperty, 254
_LVISION_LOGICBIST.ext, 483 Diagnostic Interface File (DIF) syntax
// in comments, 21 example, 486
%d scalar notation, 259, 304, 330, 335 Port: Directionproperty, 257
<custom>.blib
cell wrapper, 383, 388, 403, 404, 405, 407, —E—
417, 420, 421, 428, 431 -extensionproperty, 452, 471, 472
cellLib wrapper, 394, 407 —F—
syntax sum mary, 342 Files
—A— _LV_BGROUP_.ext, 482
AddressCounter: LogicalAddressMapwrapper, _LV_CELLS.ext, 482
280 _LVISION_JTAP.ext, 482, 483
ATDproperty, 236 _LVISION_LOGICBIST.ext, 483
AddressCounter: Functionwrapper, 260
—B—
bgroups, 482 —G—
BitGroupingproperty, 238 generating
BitsValue, 19 log files
tapbistGenerate, 462
—C— GenericMapproperty
cell wrapper, 383, 388, 403, 404, 405, 407, 417, memory library files, 279
420, 421, 428, 431
cellLib wrapper, 394, 407 —L—
cellName, 388, 424 log files
CellNameproperty specifying
memory library files, 241 tapbistGenerate, 462
circuit file name, specifying -logcommand
ruleAnalyze, 474 tapbistGenerate, 462
commands Port: LogicalPortproperty, 282
-log LogicalPortsproperty, 283, 284
tapbistGenerate, 462 —M—
-padLibrary, 447, 468, 469 memory library file
-v syntax summary, 232
ruleAnalyze, 474 MemoryTypeproperty, 286
comments

—N— -structuralExtension, 472
notation,scalar %d, 259, 304, 330, 335 Tick: Data, 251
NumberOfBitsproperty TransparentMode, 336
memory library files, 289
NumberOfWordsproperty —R—
Port: Retimedproperty, 312
ROMContentsFileproperty
—O— memory library file, 313
-outDirproperty, 467 RTL files
_JTAP.ext, 482
—P— _LV_BGROUP_.ext, 482
pad library files _LV_CELLS.ext, 482
specifying, 447, 468, 469
-padLibrarycommand, 447, 468, 469 —S—
pads.blib Port: SafeValueproperty, 319
custom syntax, 342 scalar notation, 259, 304, 330, 335
PhysicalDataMap, 297, 299 setting
Port: Polarityproperty, 302 clock parameters
Port: BusRange propertBusRange], 237 period, 446, 448
Port: BusRangepropertBusRange], 241 synthesis timing constraints, 446, 448
Portwrapper, 303 ShadowReadproperty, 322, 324, 326
properties signal ports, specifying
ATD, 236 data ranges for bused ports, 237, 241
BitGrouping, 238 direction, 257
CellName polarity, 302
memory library files, 241 safe values for input ports, 319
-clockPeriod, 446, 448 specifying
DataOutStage, 254 circuit file name
-extension, 452, 471, 472 ruleAnalyze, 474
GenericMap log files
memory library files, 279 tapbistGenerate, 462
LogicalPorts, 283, 284 pad library files, 447, 468, 469
MemoryType, 286 -structuralExtensionproperty, 472
NumberOfBits Syntax for custom cells, 342
NumberOfWords —T—
TransparentModeproperty, 336
-outDir, 467 —V—
Port: BusRange, 237, 241 Variables
Port: Direction, 257 cellName, 388, 424
Port: LogicalPort, 282 -vcommand
Port: Polarity, 302 ruleAnalyze, 474
Port: Retimed, 312
Port: SafeValue, 319 —W—
ROMContentsFile, 313 Wrappers
ShadowRead, 322, 324, 326

cell, 383, 388, 403, 404, 405, 407, 417, 420,
421, 428, 431
cellLib, 394, 407
wrappers
AddressCounter: LogicalAddressMap, 280

Third-Party Information
Details on open source and third-party software that may be included with this product are available in the
<your_software_installation_location>/legal directory.

Et Assemble Reference

Uploaded by

Document Information

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

Et Assemble Reference

Uploaded by

Copyright:

Available Formats

SIEMENS EDA

Support Center: support.sw.siemens.com

ETAssemble Tool Reference, v2021.2 and Later 3

4 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 5

6 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 7

8 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 9

10 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 11

12 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 13

Figure 7-8. ClockInverter Cell Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

14 ETAssemble Tool Reference, v2021.2 and Later

Table 3-1. Properties in the Connections Wrapper in the TAP Wrapper . . . . . . . . . . . . . . . 77

ETAssemble Tool Reference, v2021.2 and Later 15

16 ETAssemble Tool Reference, v2021.2 and Later

• Angle brackets, < >

ETAssemble Tool Reference, v2021.2 and Later 17

18 ETAssemble Tool Reference, v2021.2 and Later

Command Line and Property Options

• Properties — Yes / No. For example:

• x — is an integer that identifies the number of bits in value.

ETAssemble Tool Reference, v2021.2 and Later 19

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

20 ETAssemble Tool Reference, v2021.2 and Later

All input files support this syntax.

• All identifiers must begin with a letter.

Port (\lalala) {...

ETAssemble Tool Reference, v2021.2 and Later 21

Special Characters in File Names

22 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 23

ETAssemble Input Files

.etassemble Configuration File

Memory Library File

24 ETAssemble Tool Reference, v2021.2 and Later

Pad Library File

Cell Library File

Pin Order List File

ETAssemble Tool Reference, v2021.2 and Later 25

26 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 27

.etassemble Configuration File Structure

• Figure 3-1: Complete syntax of .etassemble when running ETAssemble in -flow

.etassemble Syntax (-flow EBScan)

28 ETAssemble Tool Reference, v2021.2 and Later

ConstantLogic0Inputs: vcc, Ten3[2:1], Ten4[2]a;

.etassemble Syntax (-flow chip | block)

ETAssemble Tool Reference, v2021.2 and Later 29

30 ETAssemble Tool Reference, v2021.2 and Later

ETAssemble Tool Reference, v2021.2 and Later 31

RevisionCode: 4’b<revId> | (4’h<revId>);

32 ETAssemble Tool Reference, v2021.2 and Later

WTAP { Bypass: Yes | No; DeviceIdCode: <number>; ManufacturersIdCode:

ETAssemble Tool Reference, v2021.2 and Later 33

34 ETAssemble Tool Reference, v2021.2 and Later

FeedThroughMux:(<PO>): <PI_in>, <PI_en>[, <PI_in>. <PI_en>]*;

Sample .etassemble Starter Templates

The following legend applies to these examples: