LVflow

This manual is part of a fully-indexed Tessent documentation set.
To search across all Tessent manuals, click on the binocular icon

or press Shift-Ctrl-F. Note that this index is not available if you are
viewing this PDF in a web browser.
LV Flow Users Manual
Software Version 2014.2
June 2014
2009-2014 Mentor Graphics Corporation
All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics
trademarks may be viewed at: www.mentor.com/trademarks.
The registered trademark Linux
is used pursuant to a sublicense from LMI, the exclusive licensee of

Linus Torvalds, owner of the mark on a world-wide basis.
Mentor Graphics Corporation
8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: www.mentor.com
SupportNet: supportnet.mentor.com/
Send Feedback on Documentation: supportnet.mentor.com/doc_feedback_form
LV Flow Users Manual, v2014.2 3
June 2014
Table of Contents
Chapter 1
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Manual Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Character Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
BitsValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Bus Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 2
Introducing Hierarchical Test Concept, LV Flow, and Environment. . . . . . . . . . . . . . . . 23
Introducing the LV Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
BurstMode Logic BIST Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Using the LV Flow in Your Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Chapter 3
Completing the LV Flow Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Using Required Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Library Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Creating Models for Rules Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Guidelines for Creating Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Instantiating Mentor Graphics Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Cells that Require Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Verifying Models for Rules Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Creating Specific Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Basic Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Combinational Cells that Contain UDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Multiplexer that Contains UDPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Programmable Pull-Up with UDP/Unsupported Primitive. . . . . . . . . . . . . . . . . . . . . . . . . 58
Reviewing Verilog Syntax Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Netlist Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Signal Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Assign Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Specify Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Language Binding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Verilog Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
VHDL Name Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table of Contents
4
June 2014
LV Flow Users Manual, v2014.2
Top-Level Design Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Creating Mapping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Creating the Scan Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Generating Testpoint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Creating a Testpoint Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Creating Priority Data Flip-Flops and Testpoint Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Running the scanMake Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Creating Synchronizer Cell Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Creating Priority Data Flip-Flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Updating the Scan Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Adding the UDP Wrapper to the Simulation Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Chapter 4
Reviewing ETChecker Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Step 1: ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Running ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapter 5
Planning and Generating the LV Flow Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Step 2: ETPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Generating the Embedded Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Input Files to ETPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Running ETPlanner to Create Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Generated .etplan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Editing the Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Validating the Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
.ETSummary File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Fixing Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Verifying the Regular Expression Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Generating the LV Flow Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Running ETPlanner to Generate the LV Flow Environment . . . . . . . . . . . . . . . . . . . . . . . 115
Output from ETPlanner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Managing Updates of the RTL- or Gate-Level Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Chapter 6
Inserting and Verifying Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Understanding the LV Flow Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Makefile and Make Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
lvWorkSpace Linking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Chip Example to Illustrate the Steps of the Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Step 3: ETAssemble. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Generating and Inserting the Embedded Test Structures . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Performing Verification in ETAssemble Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Step 4: ETScan and Pre-Layout ETSignOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
ETScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Pre-Layout ETSignOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Table of Contents
June 2014
Using Tessent FastScan as LogicBIST Fault Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Step 5: Final ETSignOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Additional Make Targets for Final ETSignOff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Constraining ET Logic for Synthesis and Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Performing Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Managing the ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Selecting the Implementation Style of Testpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Preventing Corruption of the Logic Test Signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
signatureAnalyze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
FastScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Controlling ETSignOff Test Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Archiving Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Appendix A
Using Gated Clocks with Scan and Logic BIST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Overview of Designs with Gated Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Inserting Scan Chain and Gated Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Synthesizing With Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Describing Your Clock Gating Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Using Capture-By-Domain Through Clock-Gating Cells . . . . . . . . . . . . . . . . . . . . . . . . . 166
Appendix B
Re-Using PLL and Functional Clock Dividers During Embedded Test . . . . . . . . . . . . . . 167
Enabling a PLL During Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Enabling Clock Dividers During Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Re-Using Functional Divider When Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Local Feedback for PLL Needed During Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Manually Inserting Local Feedback in RTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Inserting Local Feedback with ETAssemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Appendix C
Logic Test and Memory BIST Clocking on Chip Examples. . . . . . . . . . . . . . . . . . . . . . . . 175
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Chip Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Chip Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Clocking During Internal Logic Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Clocking During External Logic Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Chip Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Clocking During Internal Logic Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Clocking During External Logic Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Using the Bottom-Up Test Insertion Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Physical Regions Without LogicTest Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Clocking When Using Memory BIST Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chip Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Chip Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Table of Contents
6
June 2014
Appendix D
Fault Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Measuring Fault Coverage With Ndetect Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Using Ndetect Fault Coverage As a Quality Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Reviewing Fault Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Fault Classification Report in the rulea.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Stuck-At Fault Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Stuck-At Fault in Unused Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Stuck-At in Faults External Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Fault Classification Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Title Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Vector Set Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Scan-Testable Fault Classification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Scan-Testable Fault Coverage Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Non Scan-Testable Fault Classification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Total Number of Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
At-Speed Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Example of Chip-Level Fault Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Runtime Options for Creating Fault Coverage Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Special ETVerify Output Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Undetected Fault List .ufl_all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Aborted Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Redundant Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Unpruned Fault List .scanTestableFaultList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Fault Classification Differences between Tessent FastScan and signatureAnalyze . . . . . . . 234
Stuck-at Fault Classification Difference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Transition Fault Classification Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Appendix E
Managing Your ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Overview of ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Enabling Your Chip to Handle ECO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Performing Your Functional ECO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Analyzing the Post-functional ECO Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Customizing the Post-ECO Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Performing LV-ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Verifying the LV Post-ECO Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Removing Testpoints From Critical Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Identifying Multi-Cycle Path Flip-flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
ecoGenerate Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Usage of ecoGenerate Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Syntax for .lveco Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
ECOGateInstancePrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
ScanFlipFlop (<PathToFlop>) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
ScanChainPorts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Action (RemoveFromScanChain). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Table of Contents
June 2014
Action (InsertInScanChain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Action (Connect). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Action (Intercept) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Gate (<GateType>) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
TestPointRemoval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Syntax for .ecoinfo Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
ScanChainGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
ruleAnalyze Input File for ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Syntax for Critical Paths File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Runtime Options for ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
-config. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
-configFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
-define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
-defineFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
-extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
-HDLwarningFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
-incDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
-language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
-lvlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
-modifiedExtension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
-outDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
-r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
-y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
-yvhdl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Output Files for ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
ecoGenerate Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
ruleAnalyze Generated .lveco File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
ruleAnalyze Generated .ecoinfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Appendix F
Formal Verification with Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
README File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Preparing for Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Generating and Editing the Formal Verification Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Formal Verification User Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Formal Verification Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Performing Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Final RTL vs. Customer Golden Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Pre-Scan vs. Post-Scan Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Pre-Layout vs. Customer Golden Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Pre-Layout Netlist vs. Post-Layout Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Checking Formal Verification Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Table of Contents
8
June 2014
Appendix G
Adding Embedded Boundary Scan Into Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Embedded Boundary Scan Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Recursive Integration and Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Changes to ETCreate Block/ELTCore Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Performing Stand-Alone Verification of Custom Embedded BScan Cells . . . . . . . . . . . . . . 333
Custom Boundary-Scan Cell Support Limitations and Solutions . . . . . . . . . . . . . . . . . . . 335
Appendix H
Integrating Modules With Pre-Existing Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Introduction of Hard Module Concept in ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Legacy 4.x ELT Core or Block Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Blocks With Third-Party Scan Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Memories With Internal Scan Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Example Memory With Internal Scan Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Example Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Example Memory Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
ruleAnalyze Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Example of a Memory Within Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Appendix I
Providing Direct Scan Access for ATPG Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Adding Third-Party ATPG Access to Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Enabling ATPG Access to Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Mentor Graphics Technology and Flow Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Capture-By-Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Rules Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Appendix J
Reusing Functional Shift Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Enabling Functional Shift Register Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Output Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
scanGenerate .scang_scan Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
ruleAnalyze .scandef Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Appendix K
Two-Pass Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Purpose of the LV Two-Pass Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Pass 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Pass 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Appendix L
Utilizing Flop Trays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Flop Trays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Table of Contents
June 2014
Using Flop Trays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Flop Tray Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Appendix M
LV Flow Migration to Tessent Editing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Overview of Migration to Tessent Editing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Syntax for Setting Up an Editing Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Usage Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Auto-Uniquification Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Design with System Verilog Not Supported by Legacy Editing Engine . . . . . . . . . . . . . . 367
Design with VHDL Not Supported by Legacy Editing Engine . . . . . . . . . . . . . . . . . . . . . 367
Design with System Verilog Keywords Supported by Legacy Editing Engine . . . . . . . . . 368
Limitations on Language Support in the LV Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Limitations Applicable to the ETChecker Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Limitations Applicable to the Tessent Editing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Other Flow Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Appendix N
Power-Aware Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Scan Chain Concatenation with Multiple Power Domains. . . . . . . . . . . . . . . . . . . . . . . . . 379
Appendix O
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Third-Party Information
End-User License Agreement
10
June 2014
List of Figures
Figure 2-1. Chip with Embedded Test from the LV Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 2-2. BurstMode Timing Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-3. The Implementation of the Timing Architecture . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 2-4. Effective Timing Margin with Capture-By-Domain. . . . . . . . . . . . . . . . . . . . . . 28
Figure 2-5. Steps of the LV Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 2-6. Design Flow with Embedded Test Insertion at the RTL Stage. . . . . . . . . . . . . . 32
Figure 2-7. Design Flow with Embedded Test Insertion in the Gate-Level Netlist . . . . . . . 33
Figure 2-8. Timing Impact of TestPoints Cancelled by Physical Synthesis . . . . . . . . . . . . . 34
Figure 3-1. Directory Structure for Mentor Graphics Libraries . . . . . . . . . . . . . . . . . . . . . . 37
Figure 3-2. Parallel Buffer Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 3-3. Determining When to Create Scan Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 3-4. Flow for Verifying Your Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 3-5. Scan Model for Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 3-6. Scan Model for Scan Flip-Flop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 3-7. Scan Model for Non-Scan Flip-Flop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 3-8. Verilog Simulation Model for Sample Combinational Cell with a UDP . . . . . . 52
Figure 3-9. BF202 Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 3-10. Custom Scan Model for Combinational Cell Omitting the UDP . . . . . . . . . . . 54
Figure 3-11. BF202 Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 3-12. Custom Scan Model for Instantiated UDP in Combinational Cell . . . . . . . . . . 55
Figure 3-13. aoiudp Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 3-14. Verilog Simulation Model for Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 3-15. Scan Model for Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 3-16. Model for Programmable Pull-Up with UDP/Unsupported Primitive . . . . . . . 59
Figure 3-17. Scan Model for Programmable Pull-Up with Power-Down Control . . . . . . . . 60
Figure 3-18. Pull-Up with Power-Down Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 3-19. Scannable Flip-Flops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 3-20. Sample Syntax of Library Wrapper and Module Specifications . . . . . . . . . . . 65
Figure 3-21. Sample Module Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 3-22. Pin Specifications for Scan Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 3-23. Pin Specifications for PriorityData Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 3-24. Pin Specifications for Non-Scan Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 3-25. Module Specification for Identical Scan/Nonscan Pin Names and Functions . 74
Figure 3-26. Module Specification for Nonscan Pin Names . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 3-27. Pin Specifications for Pipeline Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 3-28. scang.lib File Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 3-29. Testpoint Module SpecificationStyle3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 3-30. Synchronizer Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 3-31. Scannable Version of Synchronizer Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 3-32. Model of Synchronizer Cell dfs1.v. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
List of Figures
June 2014
Figure 3-33. Model of Scannable Version of Synchronizer Cell sdfs1.v celldefine . . . . . . . 84
Figure 3-34. Priority Data Version of Synchronizer Cell pd_sdfs1.v . . . . . . . . . . . . . . . . . . 85
Figure 3-35. Priority Data Synchronizer Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 3-36. Scan Mapping File Entries for Synchronizer Cells. . . . . . . . . . . . . . . . . . . . . . 85
Figure 3-37. Model with UDP Wrappers of Synchronizer Cell sdfs1.v . . . . . . . . . . . . . . . . 86
Figure 4-1. Running ETChecker on the Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 4-2. Top.etchecker Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 4-3. Flow for Verifying the Compliance of Your RTL . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 5-1. Sub-Steps for Running ETPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 5-2. Generating the Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 5-3. Syntax for the .etplan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 5-4. Example Top.etplan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 5-5. Specifying the Fault Simulator in ETPlanner Input Files . . . . . . . . . . . . . . . . . . 106
Figure 5-6. Example on Using Regular Expressions in .etplan. . . . . . . . . . . . . . . . . . . . . . . 108
Figure 5-7. Validating the Embedded Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 5-8. Example .ETSummary File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 5-9. Generating the LV Flow Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Figure 6-1. ET Environment Directory and File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Figure 6-2. Information Transfer Between lvWorkSpaces in Top-Down Methodology. . . . 124
Figure 6-3. Information Transfer Between lvWorkSpaces in Bottom-up Methodology. . . . 125
Figure 6-4. Merge Flow Example Chip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figure 6-5. Results After Running ETAssemble on Your ChipETAssemble . . . . . . . . . . 128
Figure 6-6. Perform Scan Chain and Testpoint InsertionETScan . . . . . . . . . . . . . . . . . . . 134
Figure 6-7. DI Faults in the Log File Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Figure 6-8. ETVerify Configuration File Syntax for Masking Files . . . . . . . . . . . . . . . . . . . 157
Figure A-1. Synopsys Power Compiler Clock-Gating Module. . . . . . . . . . . . . . . . . . . . . . . 164
Figure A-2. Capture-By-Domain for Cross-Domain Paths Through Clock-Gating Cell . . . 166
Figure B-1. Controlling PLL inputs During Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . 168
Figure B-2. Bypassing a Functional Clock Divider During Test. . . . . . . . . . . . . . . . . . . . . . 170
Figure B-3. Providing Local Feedback for PLLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure B-4. Wrapping PLL and Multiplexer in a Module When Implemented in RTL . . . . 173
Figure B-5. Custom Object Syntax to Insert Local Feedback with ETAssemble . . . . . . . . . 174
Figure C-1. Example 1Functional Clock Domains Described to ETChecker . . . . . . . . . . 177
Figure C-2. Example 1Clocking During LogicTest Mode . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure C-3. Example 2Clocks Described to ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Figure C-4. Example 2Functional Clock Domains After Clock Tree Synthesis . . . . . . . . 180
Figure C-5. Example 2Clocking During Internal Logic Test Mode . . . . . . . . . . . . . . . . . 181
Figure C-6. Example 2Clocking During External Logic Test Mode. . . . . . . . . . . . . . . . . 182
Figure C-7. Example 3Functional Clock Domains Described to ETChecker . . . . . . . . . . 183
Figure C-8. Example 3Clocking During Internal Logic Test . . . . . . . . . . . . . . . . . . . . . . 184
Figure C-9. Example 3Clocking During External Logic Test . . . . . . . . . . . . . . . . . . . . . . 185
Figure C-10. Example 3Clocks at the Core Level Described to ETChecker. . . . . . . . . . . 186
Figure C-11. Example 3Clocking During Internal Logic Test at the ELT Core Level . . . 187
Figure C-12. Example 3Clocks at Top Level with ET-Inserted ELT Cores in ETChecker 188
Figure C-13. Example 3Clocking When Physical Regions are Blocks. . . . . . . . . . . . . . . 189
List of Figures
12
June 2014
Figure C-14. Example 3Clocks Described to ETChecker Using Memory BIST Only . . . 190
Figure C-15. Example 3Clock Muxing When Using Memory BIST Only. . . . . . . . . . . . 191
Figure C-16. Example 4Clocks with SerdesTest Macros Described to ETChecker . . . . . 192
Figure C-17. Example 4Clocking During Internal Test Modes. . . . . . . . . . . . . . . . . . . . . 193
Figure C-18. Example 4Clocking During External Logic Test Mode. . . . . . . . . . . . . . . . 193
Figure C-19. Example 5Clocks with SerdesTest Macros Described to ETChecker . . . . . 195
Figure C-20. Example 5Clocks/NS Pins Described to ETChecker . . . . . . . . . . . . . . . . . . 196
Figure D-1. Example of LogicTestVectors Wrapper in ETVerify Configuration File . . . . . 199
Figure D-2. Fault Coverage Report in the rulea.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Figure D-3. Example of a Fault List File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Figure D-4. Pruned Redundant Tied Faults Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Figure D-5. Pruned Potentially Detected Tied Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Figure D-6. Pruned Potentially Detected Testmode Faults Example . . . . . . . . . . . . . . . . . . 204
Figure D-7. Pruned Untested Faults Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Figure D-8. Blocked Faults Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Figure D-9. Fault Coverage Report of a Top-Level Module with Two ELTs. . . . . . . . . . . . 209
Figure D-10. Fault Coverage Report with Transition and N-Detect Coverage . . . . . . . . . . . 217
Figure D-11. Example of Chip-Level Fault Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Figure D-12. Fault Coverage Report for fifo_ic_COLLAR in the rulea.log File . . . . . . . . . 220
Figure D-13. Fault Coverage Report for fifo_oc_COLLAR in the rulea.log File. . . . . . . . . 221
Figure D-14. Fault Coverage Report for the fifo_ic_COLLAR block . . . . . . . . . . . . . . . . . 222
Figure D-15. Fault Coverage Report for the fifo_oc_COLLAR block . . . . . . . . . . . . . . . . . 223
Figure D-16. Fault Coverage Report for Chip_50 in the rulea.log File. . . . . . . . . . . . . . . . . 224
Figure D-17. Top Level Fault Coverage Report for Chip_50 (not including ELTs). . . . . . . 225
Figure D-18. Cumulative Fault Coverage Report for Chip_50 (including ELTs). . . . . . . . . 226
Figure D-19. Aborted Fault List File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Figure D-20. Example of a Redundant Fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Figure D-21. Equivalent Circuit for Figure D-20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Figure D-22. Example of a False Redundant Fault prior to Pruning. . . . . . . . . . . . . . . . . . . 232
Figure D-23. Example of a False Redundant Fault after Pruning . . . . . . . . . . . . . . . . . . . . . 233
Figure D-24. Transition Faults on Multi-Cycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Figure D-25. Transition Faults on False Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Figure D-26. Transition Faults Excluded from Relevant Fault List . . . . . . . . . . . . . . . . . . . 238
Figure D-27. Transition Faults in the Fan-Out Cone of TX Flip-Flops. . . . . . . . . . . . . . . . . 239
Figure D-28. Control Signals Sourced by SE Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Figure E-1. Restoring the Proper LogicTest Mode of Operations. . . . . . . . . . . . . . . . . . . . . 242
Figure E-2. Complete Syntax for the .lveco File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Figure E-3. Complete Syntax for the .ecoinfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Figure E-4. Example for Inserting New Flip-Flops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure E-5. The .lveco File for Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure E-6. Complete Syntax for the .lveco File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Figure E-7. Complete Syntax for the .ecoinfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Figure E-8. Sample .ecoinfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Figure F-1. Formal Verification Tasks During the LV Flow . . . . . . . . . . . . . . . . . . . . . . . . 311
Figure F-2. Sample file - ETAssemble/<moduleName>_etassemble_user.fms . . . . . . . . . . 313
List of Figures
June 2014
Figure F-3. Sample File - ETAssemble/outDir_fv/<moduleName>_funcmode.fms . . . . . . 316
Figure F-4. Sample File - ETSignOff/outDir_fv
<moduleName>_disable_scanchains_and_tps.fms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Figure F-5. Sample Verification Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Figure G-1. Boundary-Scan Cell Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Figure G-2. Generated Files When Using -genTemplate On . . . . . . . . . . . . . . . . . . . . . . . . 328
Figure G-3. Sample ETAssemble Starter Template for Embedded Boundary Scan Flow . . 329
Figure G-4. Generated .etEarlyVer File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Figure G-5. Recursive Embedded Boundary Scan Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Figure G-6. ETCreate Flow for Cores with Embedded Boundary Scan . . . . . . . . . . . . . . . . 332
Figure G-7. Embedded Boundary Scan Usage in ELT Core. . . . . . . . . . . . . . . . . . . . . . . . . 333
Figure H-1. Illustration for Hard Module Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Figure H-2. Example Schematic View of Memory Model with Internal Scan Logic . . . . . . 343
Figure H-3. Example Memory Library File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Figure H-4. Example SYNC_1RW_16x8.rulea File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Figure H-5. The .etcScanData File for the Example Memory. . . . . . . . . . . . . . . . . . . . . . . . 347
Figure H-6. Example Verilog Model Within Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Figure I-1. Direct Scan Tasks within the LV Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Figure I-2. Example .etassemble Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Figure J-1. Functional Shift Registers Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Figure K-1. Pass 1 of the LV Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Figure K-2. Pass 2 of the LV Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Figure L-1. Example Flop Tray Cell with 3 Flip-Flops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Figure L-2. Flop Tray Module Specification Syntax in scang.lib . . . . . . . . . . . . . . . . . . . . . 363
Figure L-3. Example Flop Tray Module Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Figure N-1. The make scan_partition Target in the ETScan Step. . . . . . . . . . . . . . . . . . . . . 377
Figure N-2. Chain Segment Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
14
June 2014
List of Tables
Table 3-1. Standard Verilog Primitives Supported by ruleAnalyze . . . . . . . . . . . . . . . . . . 40
Table 3-2. Mentor Graphics Latch and Flip-Flop Primitives . . . . . . . . . . . . . . . . . . . . . . . 41
Table 3-3. Cells and Their Corresponding Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 3-4. Primitive Ports Mapping to the Ports of the Cell . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 3-5. Compiler Directives Supported by ruleAnalyze . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 3-6. Compiler Directives Ignored by ruleAnalyze . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 3-7. Scan Module Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Table 3-8. Pin Types Within Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Table 3-9. Available Testpoint Cell Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Table 3-10. Asynchronous Testpoint Control and Observation Modules . . . . . . . . . . . . . . 79
Table E-1. Spare Cells Required by the LV ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Table E-2. Valid PortFunctions by GateType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Table E-3. Valid PortFunctions by GateType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Table M-1. Syntax for Setting Up an Editing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
June 2014
Chapter 1
About This Manual
This manual provides information on how to get started with the LV Flow quickly and easily.
For the complete list of Mentor Graphics Tessent-specific terms, refer to the Tessent Glossary.
Refer to Getting Help for information on support options and related documentation.
This preface covers the following topics:
Manual Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Character Formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
BitsValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Bus Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Manual Contents
This manual comprises the following sections:
Introducing Hierarchical Test Concept, LV Flow, and Environment briefly reviews key
concepts associated with the LV Flow. It is intended to provide background information
on using the Mentor Graphics ease-of-use capability, WorkSpace, for automating many
steps in the LV Flow, from design environment setup through verification and sign-off
of your test-ready chip design. This chapter also provides an overview of key concepts
related to embedded test clocking, physical implementation process, and timing closure
of embedded test.
Completing the LV Flow Prerequisites describes the setup tasks of each technology that
you must complete in order to work in the LV Flow.
Reviewing ETChecker Step briefly reviews Step 1: ETChecker of the LV Flow. This
chapter describes the purpose of ETChecker and shows how it provides a clear
separation between your responsibilities, the RTL designer, and the DFT engineer. This
chapter provides instructions on how to use the Mentor Graphics ETChecker capability.
About This Manual
Manual Contents
June 2014
Planning and Generating the LV Flow Environment describes in detail
Step 2: ETPlanner of the LV Flow. This chapter explains how to plan and generate the
LV Flow environment for inserting embedded test structures into your design using the
ETPlanner tool.
Inserting and Verifying Embedded Test describes in detail Steps 3-5 of the LV Flow.
This chapter explains how to create and verify embedded test for your design using the
LV Flow environment.
Using Gated Clocks with Scan and Logic BIST describes designs with gated clocks and
explains how to implement Tessent scan and logic BIST in a design containing gated
clocks.
Re-Using PLL and Functional Clock Dividers During Embedded Test describes when
and how PLL and functional clock dividers must be used during operation modes of
embedded test. Special focus is given to at-speed logic test ATPG and logic BIST.
Logic Test and Memory BIST Clocking on Chip Examples provides chip examples to
illustrate how functional clocking is described to ETChecker and to show the clocking
circuitry inserted into the chips to perform memory BIST and internal and external logic
test modes.
Fault Coverage explains fault coverage considerations when using logic BIST vs. ATPG
patterns. It provides detailed information on fault coverage achieved using Mentor
Graphics LogicBIST, as well runtime options for customizing your fault coverage
reports and examples of the ETVerify output files that include fault coverage
information.
Managing Your ECO Process describes how to perform a functional ECO to your circuit
and how to restore the proper LogicTest mode of operation following a functional ECO.
The chapter also describes how to remove testpoints from critical paths.
Formal Verification with Embedded Test describes support for Formal Verification with
Synopsys Formality.
Adding Embedded Boundary Scan Into Your Design provides an overview of the steps
required to add boundary-scan cells directly into any core containing I/O cells.
Integrating Modules With Pre-Existing Scan Chains describes how to integrate different
objects with pre-existing non-burst-ready scan chains into the LV Flow.
Providing Direct Scan Access for ATPG Tools describes how to direct scan for use with
ATPG tools.
Reusing Functional Shift Registers describes how to reuse Functional Shift Registers in
Tessent LogicBIST and SoCScan.
Two-Pass Flow describes how to delay the insertion of Logic Test in the LV Flow by
running ETAssemble twice.
About This Manual
Syntax Conventions
June 2014
Utilizing Flop Trays describes how to use flop trays (multiple flip-flop cells) in designs
to save on power requirements by sharing clock inverters within the multi-bit cell.
LV Flow Migration to Tessent Editing Engine describes the LV Flow migration to the
Tessent Editing Engine including usage scenarios and existing limitations.
Power-Aware Scan Insertion describes the method for making the testpoint and scan
chain insertion power-aware by reading a Common Power Format or Universal Power
Format file into Tessent Shell. Also, this method enables you to create scan partitions so
that scan chains can be restricted to specific instances.
Syntax Conventions
Before you begin creating input files or specifying runtime options, familiarize yourself with
syntax conventions used throughout this manual and 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, { }
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.
About This Manual
Syntax Conventions
June 2014
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
Syntax Rules
June 2014
Underlining
Underlining identifies default valid values or default valid options in syntax descriptions.
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:
xbvalue | xhvalue
Formats
where
xis an integer that identifies the number of bits in value.
b, hare literals that identify whether value is in binary or in hex format, respectively.
valueis a string of literal bit values.
If there are fewer bits in value than specified by x, Mentor Graphics tools pad the left bits with
logic 0s.
Note
Do not specify a value of 1 outside the range specified by x. If you do, Mentor Graphics
tools generate an error.
Examples
The examples below show sample syntax.
This first sample syntax corresponds to 1.
1b1
The syntax below corresponds to 1010 or hex A.
4b1010
Finally, the following syntax corresponds to 0101111.
7h2F
About This Manual
Syntax Rules
June 2014
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.
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:
About This Manual
Syntax Rules
June 2014
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.
About This Manual
Syntax Rules
June 2014
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. The space terminates the identifier.*/
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.*/
June 2014
Chapter 2
Introducing Hierarchical Test Concept, LV
Flow, and Environment
The LV Flow uses a suite of software automation tools that delivers a set of embedded test
controllers into your chip to fully test and diagnose your circuit with high level of quality and
robustness.
This chapter introduces the LV Flow and explains how it fits into your design flow.
This chapter follows this sequence:
Introducing the LV Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
BurstMode Logic BIST Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Using the LV Flow in Your Design Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Introducing the LV Flow
The LV Flow uses a suite of software automation tools which delivers a set of embedded test
controllers into your chip to fully test and diagnose your circuit with high level of quality and
robustness.
Features, such as a top-down or bottom-up RTL rule checker with the extraction of design
information from the RTL or netlist, greatly improve the embedded test insertion predictability.
The introduction of the WTAP, a distributed version of the central TAP using the IEEE 1500
protocol, allows complete physical block footprint predictability.
Tessent embedded test includes a revolutionary logic test timing architecture which eliminates
all difficult DFT decisions by removing all negative impact on the physical flow. At the same
time, Tessent embedded test allows testing of each clock domain at its true functional
frequency. This architecture is described in more detail in BurstMode Logic BIST Architecture.
The simplified LV Flow allows a complete RTL insertion process fully compatible with your
design flow. The LV Flow is comprehensive and allows testing of all aspects of your chip.
Figure 2-1 illustrates various embedded test objects that can be inserted into your design using
the LV Flow tools. These include the following:
Memory BIST controllers
LogicTest controllers
Boundary scan registers
Introducing Hierarchical Test Concept, LV Flow, and Environment
June 2014
IEEE 1149.1 Circuit test access port (TAP)
IEEE 1500 Core wrapper test access ports (WTAP)
Figure 2-1. Chip with Embedded Test from the LV Flow
Note
The WTAPs are connected to the top-level TAP. This enables a seamless pattern
generation for manufacturing test as well as enable the use of Serial Vector Format (SVF)
on the chip. The LV Flow does not support WTAP controlled from top-level pins of the
chip.
Note that it is very important to match the embedded test partitioning with your physical block
partitioning for logic BIST. In the previous ICBIST products, such reasons as power, true at-
speed testing, block speed binning could have forced you to partition the embedded test logic
differently than the physical one. In the next section, BurstMode Logic BIST Architecture, we
explain why this test-specific partitioning is no longer necessary.
June 2014
Physical blocks that are large enough are best tested with a local logicTest controller. This
makes the test self-contained and simplifies the test interface at the block boundary. Those
physical blocks are declared as lv.ELTCoreModule in ETChecker.
Smaller physical blocks can be tested by the top-level logicTest controller. They are declared as
lv.BlockModule in ETChecker.
BurstMode Logic BIST Architecture
The benefits of the BurstMode logic BIST architecture can be summarized as follows:
True at-speed testing on all clock domains with both logic BIST and ATPG patterns
No timing critical inter-domain signals
No clock alignment or maximum latency requirements which existed with the previous
architecture
Complete short and long-term power management
Independent speed binning per clock domain
Only one controller per layout region because there is no need to further partition for
power, true at-speed, or clock speed binning requirements
The BurstMode logic BIST architecture offers all timing closure advantages of the well-known
double capture scan test method without its disadvantages. Like the double capture method, the
timing architecture, referred to as the burst architecture, separates the shift phase from the
capture phase. The scan chains are loaded/unloaded at a common frequency independent of the
functional speed of the clock domains. The shift frequency defaults to 100MHz and is
adjustable to produce a trade-off between test quality, power requirements, timing closure
requirements, and test time. Best quality results are obtained when the shift frequency generates
a toggle rate comparable to the functional mode of operation as measured by the continuous
current.
Once all scan chains are loaded, they are closed into rotating segments, and each clock domain
is allowed to burst for a small number of clock cycles. The values inside each scan segment
rotate at the true functional speed, causing the needed at-speed activity before the single capture
cycle.
Figure 2-2 on page 26 illustrates the timing waveforms of this architecture. The number of
clock cycles during the burst phase is called the burst length. It defaults to 5 but can be specified
as small as two cycles. A burst length of 5 cycles corresponds to four rotating shift cycles
followed by a single capture cycle. The shift clock cycles during the BurstMode can be slowed
down at run time to precisely tune the instantaneous power level around the capture edge to
match the true worst case of instantaneous functional power.
June 2014
Figure 2-2. BurstMode Timing Diagram
Figure 2-3 on page 27 shows the hardware used to implement the BurstMode logic BIST
architecture. The logicTest controllers consist of a state machine, counters, a PRPG, and a
MISR. A single shift clock controller is used to generate the common shift clock and toggle the
circuit between shift and burst phase. One Burst Clock controller is used per clock source to
generate a burst of clocks per functional frequency.
This distributed architecture allows true at-speed test on all clock domains in parallel and also
greatly simplifies the timing closure requirements of the test mode.
The BurstMode logic BIST architecture limits the number and scope of test-specific timing
critical signals. Only the paths from pipelining stages of the scanEnable signal and, if
necessary, clockEnable signals are timing critical. However, all timing constraints are imposed
within each clock domain which simplifies timing closure significantly.
There are no timing critical paths between the various components of the architecture
logicTest controller, shift clock controller, and Burst Clock controller, including the diagnostic
signals. There are also no timing critical paths between the serial input/output of the scan chains
of the various clock domains and the logicTest controller due to the reduced shift frequency.
Finally, all asynchronous cross-domain paths (referred as CBD in Figure 2-3) are tested at
reduced speed using an improved version of the patented Capture-by-Domain technique.
June 2014
Figure 2-3. The Implementation of the Timing Architecture
The relaxation of all inter-domain paths is the reason why all difficult DFT decisions have been
removed with the timing architecture. Even the final clock domain latency does not affect the
timing margin provided by the capture-by-domain method in the cross-domain capture paths.
As shown in Figure 2-4, the capture-by-domain circuit provides 8 shift clock cycles of setup
and 8 clock cycles of hold around the capture edge (at 100MHz that is 80ns!).
June 2014
Figure 2-4. Effective Timing Margin with Capture-By-Domain
Flip-flops that are source of asynchronous cross-domain paths (TX flops) are configured in hold
mode during the entire burst phase when the destination flip-flops (RX flops) are configured in
capture mode. These paths are essentially false paths and eliminate any clock alignment
requirements between clock domains.
Note
Note for existing users of icBISTthe transmitMCP specification is now obsolete.
Using the LV Flow in Your Design Flow
June 2014
The LV Flow comprises five steps which are performed at different stages within the rest of
your design flow. Figure 2-5 illustrates the steps of the LV Flow. Brief descriptions for each
step follow the figure.
Figure 2-5. Steps of the LV Flow
Step 1: ETCheckerChecks if a design meets the embedded test requirements,
identifies where testpoint locations and dedicated isolation will be inserted and extracts
all pertinent design information from the RTL or netlist.
Step 2: ETPlannerPlans your embedded test insertion and generates the needed LV
Flow environment.
June 2014
Step 3: ETAssemble
o In the lower-level physical regions or coresInserts the embedded test controllers,
such as WTAP, memory BIST, and logicTest controllers, creates scan ports on the
block module and inserts any Dedicated Isolation cells when creating logicTest
controllers.
o At the chip top levelGenerates and inserts all embedded test, such as JTAP,
boundary scan, logic test, and memory BIST, etc.
o Performs early verification of the embedded test in your design.
Step 4: ETScan and Pre-Layout ETSignOffInserts the scan chains and testpoints in
the netlist. Performs pre-layout ETSgnOff using rule checkers, Static timing analysis,
formal verification, and simulations.
Step 5: Final ETSignOffPerforms final post-layout ETSignOff using rule checkers,
Static timing analysis, formal verification and simulations.
The following figures illustrate several scenarios of using the steps of the LV Flow in the
context of the complete design flow:
Figure 2-6The flow where the embedded test hardware is inserted into the RTL.
Figure 2-7The alternate flow where the embedded test is inserted into the gate-level
netlist.
The design flow shown in Figure 2-6 on page 32 provides advantages never possible before.
With the design information extracted from the RTL by ETChecker, ETAssemble is capable of
inserting all embedded test logic in one step and freezing the physical layout block foot print at
the RTL level. It allows RTL synthesis of each block with all embedded test visible and no ports
being added on the block boundaries after synthesis. The ETScan step grouped in the graybox
is not present when you are not inserting logic test.
The design flow shown in Figure 2-7 on page 33 shows the steps when the embedded test
process is performed on the gate-level netlist. This alternate flow does not allow to freeze the
block foot print at the RTL level but has the advantage of clearly separating the design process
between the RTL designer, the DFT engineer, and the physical engineer, as described below:
The RTL designer focuses on the RTL and the functional SDC and takes care of the RTL
synthesis of the functional logic. The RTL designer has ETChecker available to verify
the DFT compliance of the RTL design. The .etchecker file also serves as a
communication tool to the DFT engineer to describes the clock domain bases and their
respective frequencies. For details on the .etchecker file, refer to ETChecker
Properties in the manual ETChecker Users and Reference Manual.
The DFT engineer is responsible for the entire embedded test insertion process. The
turnaround predictability is very high when the RTL designer has already run
ETChecker. With the clocks defined in the .etchecker file, the netlist, and the
June 2014
automation provided by ETPlanner, the DFT engineer has all information and tools to
quickly insert the embedded test in an optimal manner with near zero impact on the
functional behavior of the chip.
The physical engineer receives the ET-Inserted netlist, the final SDC, and scandef file.
Because of the physical synthesis step that is now part of the back-end flow, the quality
of result is identical whether or not the DFT insertion was performed at the RTL- or
gate-level netlist. As illustrated in Figure 2-8 on page 34, even the impact of testpoints
on timing is canceled by the physical synthesis step.
June 2014
Figure 2-6. Design Flow with Embedded Test Insertion at the RTL Stage
June 2014
Figure 2-7. Design Flow with Embedded Test Insertion in the Gate-Level Netlist
June 2014
Figure 2-8. Timing Impact of TestPoints Cancelled by Physical Synthesis
Before Incremental Optimization
After Incremental Optimization
June 2014
Chapter 3
Completing the LV Flow Prerequisites
Before you begin working in the LV Flow, you must perform certain setup tasks. Although, you
are not required to perform these steps in a specific order, you must complete all of the steps
before you work in the LV Flow. You perform these setup tasks only once for each technology
that you use to fabricate your ICs (that is, if you use more than one technology, you complete all
the steps for all the technologies).
This chapter covers the following topics:
Using Required Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Library Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Creating Models for Rules Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Guidelines for Creating Scan Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Instantiating Mentor Graphics Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Cells that Require Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Verifying Models for Rules Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Creating Specific Scan Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Basic Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Combinational Cells that Contain UDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Multiplexer that Contains UDPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Programmable Pull-Up with UDP/Unsupported Primitive. . . . . . . . . . . . . . . . . . . . . . . . . 58
Reviewing Verilog Syntax Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Netlist Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Signal Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Assign Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Specify Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Language Binding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Verilog Name Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
VHDL Name Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Top-Level Design Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Creating Mapping Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Creating the Scan Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Generating Testpoint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Creating a Testpoint Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Creating Priority Data Flip-Flops and Testpoint Cells . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Running the scanMake Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Using Required Libraries
June 2014
Creating Synchronizer Cell Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Creating Priority Data Flip-Flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Updating the Scan Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Adding the UDP Wrapper to the Simulation Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
You must use libraries for several of the tools in the design flow. These libraries are generally
technology-dependent and describe cell characteristics in a format that is compliant with the
tools. You can create these libraries on a per-design basis or obtain them from a chip
manufacturer or, in some cases, from Mentor Graphics.
In general, Mentor Graphics libraries are required to support rules checking, scan and testpoint
insertion, and pad cell insertion.
Libraries are required to support the following capabilities in the LV Flow Step 3:
ETAssemble, Step 4: ETScan and Pre-Layout ETSignOff, and Step 5: Final ETSignOff:
Extracting connectivity with designExtract
Checking design rules with ruleAnalyze
Inserting testpoints and scan chains with scanGenerate
Library Hierarchy
Figure 3-1 illustrates the directory and file hierarchy for Mentor Graphics-supplied scan
libraries. This hierarchy ships with your Mentor Graphics software. There are two main
directories tgc1000 and icbist.
June 2014
Figure 3-1. Directory Structure for Mentor Graphics Libraries
.../lib/technology/tgc1000
The .../lib/technology/tgc1000 directory stores Texas Instruments (TI) technology-specific data
as an example of a technology-specific directory. The directory contains two subdirectories:
/verilog contains an edited copy of the tgc1000 technology-specific library of Verilog
simulation models, including all user-defined primitives (UDPs). Mentor Graphics has
edited this directory to remove all timing information, per agreement with Texas
Instruments. You will need to install a library similar to this one if you plan to do
Verilog simulations. Your installed library, which should include timing information,
can exist anywhere within your directory structure. It does not need to be in
.../lib/technology. You will need to specify the path to the Verilog models to the
ETPlanner in the .LVICTech File using the SimModelDir or SimModelFile properties.
/lvision contains an example of scan models for the tgc1000 library. This directory
also contains the scang.lib File, which is a template for creating a mapping between
non-scan and scan flip-flops. This file also contains the scan-related pins of the testpoint
modules. You will need to specify the path to the scan models to the ETPlanner in the
.LVICTech file using the SimModelFile or SimModelDir properties. The scang.lib File
lib
technology
tgc1000
icbist
lvision verilog
generic example
LV_MUX.v
LV_SDFF_P_SB_RB.v
testpoint
descriptions
Simulation
Models
MU111.v
TBD21.v
scang.lib
MU111.v
TBD21.v
lvision
Scan
Models
Testpoint
Descriptions
LV Primitives
for Scan Modeling
verilog vhdl
generic generic
LVMUX.v
LVREGP.v
LVMUX.vhds
LVREGP.vhds
LV Primitives
for Simulation
LV Primitives
for Simulation
tpStyle<n>.scangLib
Creating Models for Rules Checking
June 2014
will need to be specified to the ETPlanner in the .LVICTech File using the ScangLib
property.
.../lib/technology/icbist
The .../lib/technology/icbist directory contains the lvision sub-directory:
/lvision This directory contains the following sub-directories and files:
o /example contains examples of mapping files for the style3 of testpoints that
Mentor Graphics supports. These files are in the format required by Mentor
Graphics. By default scanGenerate looks for tpStyle(n)scang.Lib File (the testpoint
mapping files) in .../lib/technology/icbist. The files provided in this directory
describe the testpoints as they are created using scanMake. Do not edit these files. If
you have testpoints which were not created by scanMake, and they have port and
module names different than what is described in the supplied testpoints mapping
files, use the supplied version as a starting copy but do not modify the original files.
o /generic contains the Mentor Graphics scan model primitives that you use when
creating your technology-dependent scan models. It also contains scan models for
several basic cells such as a 2-input AND gate, a multiplexer, and a flip-flop.
o /designa contains customization scripts that implement the specifications of the
CustomObject wrappers in the ETAssemble configuration file .etassemble.
The Mentor Graphics products support a subset of the standard Verilog primitives. For ASIC
cells that do not use primitives of this supported subset, you must create scan models using the
Mentor Graphics-supplied primitives.
Before you perform rules checking or insert scan chains, you must create a scan model library
that contains models for the following:
Sequential cells, such as flip-flops and latches
Memory cells
Cells defined at RTL
Individual transistors or groups of transistors (not cells)
Non-scannable circuitry, such as asynchronous logic and nonscan flip-flops, including
R-S or JK flip-flops
Protected models
Cells that contain user-defined primitives (UDPs)
June 2014
For other cells, ETChecker and ruleAnalyzeMentor Graphics rules checkersread in the
Verilog simulation model directly, and no scan model is required.
This section describes general guidelines for creating scan models. The section Creating
Specific Scan Models presents sample scan models.
Note
Mentor Graphics tools use the same models, a sub-set of Verilog primitives, with both
Verilog and VHDL netlists. A separate set of models is not used for VHDL designs.
You can use the information in this section to configure your technology libraries. This section
also instructs you on how to create scan models for non-scannable circuitry.
To create a scan model library, you might need to understand how the Mentor Graphics
ruleAnalyze tool handles the various constructs of Verilog syntax. Refer to Reviewing Verilog
Syntax Rules.
The scan model library that you need might already be available from your ASIC vendor.
Note that the same models are used by designExtract if unresolved primitives are found while
tracing connectivity.
Guidelines for Creating Scan Models
This section provides general guidelines for creating scan models that are required by Mentor
Graphics tools.
Parallel Drivers
The ruleAnalyze tool supports parallel drivers of the same type that drive the same net. For
example, in Figure 3-2, two buffers driven from the same source drive the same net.
Figure 3-2. Parallel Buffer Example
When you use ruleAnalyze, it prunes the parallel buffer construct and includes only a single
buffer in the generated Mentor Graphics format of your netlist. Because of this pruning,
ruleAnalyze excludes parallel drivers from the generated list of design modulesthe .macinfo
filethat the testpointAnalyze tool uses when it considers modules for testpoint insertion.
June 2014
Pull-Ups and Pull-Downs
The ruleAnalyze tool supports pull-ups and weak drivers that are modeled using the standard
Verilog primitives pullup and pulldown.
In addition, ruleAnalyze supports programmable pull-ups that are modeled using pull strengths
on the standard Verilog primitives bufif0, bufif1, notif0, and notif1.
Signals
The signal names that you specify in a scan model for cell ports must correspond to the signal
names in the Verilog model. The order and signal names for the ports that you specify in the
scan model must correspond to the ones in the Verilog model.
In addition, the pin order in the scan model must correspond to the pin order in the Verilog
model. The name and the order of the pins in the scan model must correspond to the ones in the
Verilog model.
Tristateable Constructs
The ruleAnalyze tool supports tri-statable constructs that are modeled using the standard
Verilog primitives bufif0, bufif1, notif0, and notif1.
User-Defined Primitives (UDPs)
The ruleAnalyze tool does not support UDPs. You must provide equivalent structural models
for all cells with UDPs. Alternatively, you can create new models for UDPs that only use
standard Verilog primitives supported by Mentor Graphics tools.
Verilog Primitives, Standard
The ruleAnalyze tool supports the Verilog primitives listed in Table 3-1.
Table 3-1. Standard Verilog Primitives Supported by ruleAnalyze
and nor pulldown
buf not pullup
bufif0 notif0 xnor
bufif1 notif1 xor
nand or
June 2014
Scan Model Primitives, Mentor Graphics
Mentor Graphics provides a directory of supported scan model primitives with your software.
You can use these primitives to create your technology-dependent scan models. The following
directory is the default location for these primitives:
.../lib/technology/icbist/lvision/generic
The section Instantiating Mentor Graphics Primitives provides the naming conventions for the
primitives.
Instantiating Mentor Graphics Primitives
Although the Mentor Graphics primitives operate in the same manner as built-in Verilog
primitives, you instantiate a primitive into a scan model in the same manner as for a regular
module.
Use the following syntax to instantiate a primitive:
<moduleName>
<instName>] ( <portConnection
1
>,
<portConnection
2
>,
.
.
.
<portConnection
n
>
;
where the above criteria represent the following:
moduleName identifies the primitive that you are instantiating.
instName uniquely identifies the name of the module instance. You can make the
instance name identical to the module name.
portConnection
1...n
specifies one or more port connections. You can use both
positional and name-based port mapping for designs. Named-based port mapping is
recommended as it is less error-prone.
The latch, non-scan flip-flop, and scan flip-flop primitives use the following naming
conventions as listed in Table 3-2.
Table 3-2. Mentor Graphics Latch and Flip-Flop Primitives
Transparent Latch LV_LATCH{polarity}{set/reset}
Non-Scan Flip-Flop LV_DFF{polarity}{set/reset}
Scan Flip-Flop LV_SDFF{polarity}{set/reset}
June 2014
The {polarity} field can either be _P or _N to indicate whether the latch or flip-flop is positive-
edge or negative-edge respectively.
For example, the primitive LV_DFF_N.v models a negative-edge (_N) non-scan flip-flop.
The {set/reset} field is an optional field used to indicate whether a latch or flip-flop has set
and/or reset functions and active polarities.
The {set/reset} field naming conventions are as follows:
_S for active high set
_SB for active low set
_R for active high reset
_RB for active low reset
For example, the primitive LV_SDFF_P_SB.v models a positive-edge (_P) scan flip-flop with
an active low set (_SB) function.
Furthermore, if a latch or flip-flop has both set and reset functions, then the order in which the
{set/reset} fields are named denotes the precedence of the two functions. For example, the
primitive LV_LATCH_P_R_SB.v models a positive-edge (_P) latch with active high reset (_R)
and active low set (_SB) functions. Also, since the reset is listed before the set (_R_SB), the
reset has precedence over the set for the condition when both functions are active.
The primitives use the following port naming conventions for latches and flip-flops:
CK for clock ports
D for data ports
Q and QB for output ports
S and SB for set ports
SD for scan data ports
SM for scan mode (scan enable) ports
R and RB for reset ports
June 2014
The primitive LV_MUX.v uses the following port naming conventions:
Sample syntax is as follows:
LV_MUX LV_MUX (.A(A),.B(B),.S(S),.Y(Y));
Cells that Require Scan Models
You must create scan models for the following:
Sequential cells, such as flip-flops and latches
Memory cells
Cells defined at RTL
Individual transistors or groups of transistors (not cells)
Nonscannable circuitry, such as asynchronous logic and nonscan flip-flops, including R-
S or JK flip-flops
Protected models
Cells that contain UDPs
To help you decide whether you need to create a scan model for a given cell, obtain a cell list
and answer the questions in Figure 3-3 for each cell. For cells that do not require scan models,
ruleAnalyze reads in the Verilog structural simulation model instead.
Mentor Graphics provides an example of a scan model library with your software at the
following default location:
/<tessent_software_tree>/lib/technology/tgc1000/lvision
The section Creating Specific Scan Models provides examples of scan models.
June 2014
Figure 3-3. Determining When to Create Scan Models
Creating Specific Scan Models
June 2014
Verifying Models for Rules Checking
After you create any required scan models, and before you insert scan chains and testpoints,
Mentor Graphics recommends that you verify the scan models. Figure 3-4 shows the
recommended flow.
Figure 3-4. Flow for Verifying Your Scan Models
This section describes how to create scan models for specific ASIC cells. Before you read this
section, refer to Creating Models for Rules Checking.
June 2014
Basic Instructions
You construct a scan model library, using guidelines that Mentor Graphics provides, to use as
input to the ruleAnalyze and scanGenerate tools. This library is a collection of technology-
dependent scan models. Table 3-3 provides an example of the mapping from Verilog models to
scan models, using Mentor Graphics and Verilog primitives, for tgc1000.
Table 3-3 summarizes the process that you use to create your scan model library, as described in
the following sequence:
1. Identify the cells in your design that require scan models.
2. Locate the Verilog simulation model library for your targeted technology.
3. Copy the simulation model for each cell requiring a scan model.
Table 3-3. Cells and Their Corresponding Primitives
Model Name Path to Verilog
Model
Mentor
Graphics
Primitive
Path to Mentor
Graphics
Primitive
Path to Scan
Model
Examples
Standard Replacements
LAH20.v
Transparent Latch
.../lib/technology/
tgc1000/verilog/L
AH20.v
LV_LATCH_P .../lib/technology/
icbist/lvision/gen
eric/LV_LATCH
_P
.../lib/technology
/tgc1000/lvision/
LAH20.v
TDN20.v
PosEdge Scan FF
.../lib/technology/
tgc1000/verilog/T
DN20.v
LV_SDFF_P .../lib/technology/
icbist/lvision/gen
eric/LV_SDFF_P
.../lib/technology
/tgc1000/lvision/
TDN20.v
DTN12.v
PosEdge,
non-scan FF
...//lib/technology
/tgc1000/verilog/
DTN12.v
LV_DFF_P .../lib/technology/
icbist/lvision/gen
eric/LV_DFF_P
.../lib/technology
/tgc1000/lvision/
DTN12.v
MU111.v
2:1 multiplexer
.../lib/technology/
tgc1000/verilog/
MU111.v
LV_MUX .../lib/technology/
icbist/lvision/gen
eric/LV_MUX
.../lib/technology
/tgc1000/lvision/
MU111.v
Special Cells Requiring Special Instructions
Combinational
cell
BF202.v
.../lib/technology/
tgc1000/verilog//
BF202.v
Use Verilog
primitives
Not applicable
because Verilog
primitives are
used
.../lib/technology
/tgc1000/lvision/
BF202.v
PR010.v
programmable
pull-up
.../lib/technology/
tgc1000/verilog/P
R010.v
Use Verilog
primitive bufif0
Not applicable
because Verilog
primitive is used
.../lib/technology
/tgc1000/lvision/
PR010.v
June 2014
4. Edit the simulation model.
Refer to the following examples:
o Figure 3-5 shows the latch scan model LV_LATCH_P, which is used for the cell
LAH20.
o Figure 3-6 shows the scan flip-flop LV_SDFF_P, which is used for the cell TDN20.
Note that the ports description in the primitive module LV_SDFF_P maps the
primitive module ports to the ports of the cell as shown in Table 3-4:
o Figure 3-7 shows the nonscan flip-flop LV_DFF_P, which is used for the cell
DTN12.
o Examples of scan models for the tgc1000 cell library example are located at the
following default path:
.../<tessent_software_tree>/lib/technology/tgc1000/lvision/<cellName>
For details on creating scan models for the following complex cells, refer to these
sections:
o Combinational Cells that Contain UDPs
o Multiplexer that Contains UDPs
o Programmable Pull-Up with UDP/Unsupported Primitive
Table 3-4. Primitive Ports Mapping to the Ports of the Cell
Primitive Module
Port
Cell Port
.CK
.D
.SD
.SM
.Q
.QB
(CLK),
(D),
(SD),
(SCAN),
(Q),
(QZ),
June 2014
Figure 3-5. Scan Model for Latch
June 2014
Figure 3-6. Scan Model for Scan Flip-Flop
June 2014
Figure 3-7. Scan Model for Non-Scan Flip-Flop
Combinational Cells that Contain UDPs
In this section, you perform the following tasks:
Determine whether or not a sample combinational cell requires a scan model.
If a scan model is required, determine whether you create a scan model for the
combinational cell or for the instantiated user-defined primitives (UDPs).
If required, create the required scan model(s).
BF202.v is a combinational cell containing UDPs. Follow these general steps to create a scan
model for it:
1. View the simulation model for the sample combinational cell BF202.v, shown in
Figure 3-8. The inset in Figure 3-8 represents the Verilog simulation model for the UDP
aoiudp.
Y = (A1 * A2) + (B1 * B2) + (C1 * C2) + (D1 * D2)
June 2014
Note
For combinational cells that do not use UDPs, you do not need to create a scan model. If
ruleAnalyze does not find a scan model for a given cell, ruleAnalyze automatically reads
the appropriate Verilog simulation model for that cell.
2. Copy and edit the model to include only the required information as shown in Figure 3-
10.
3. Replace the aoiudp and its associated Verilog primitives with an equivalent description
consisting only of supported, standard Verilog primitives.
June 2014
Figure 3-8. Verilog Simulation Model for Sample Combinational Cell with a UDP
June 2014
Figure 3-9. BF202 Schematic
June 2014
Figure 3-10. Custom Scan Model for Combinational Cell Omitting the UDP
Figure 3-11. BF202 Schematic
June 2014
Instead of creating a scan model for the combinational cell by replacing the instantiated UDPs
with supported, standard Verilog primitives, you can create a scan model for the UDP as shown
in the sample file in Figure 3-12.
Figure 3-12. Custom Scan Model for Instantiated UDP in Combinational Cell
Figure 3-13. aoiudp Schematic
Multiplexer that Contains UDPs
In this section, you create a scan model for the cell MU111.v using the Verilog primitive
LV_MUX.
Because MU111.v is a multiplexer that contains UDPs, it requires a scan model. To use the
Verilog primitive LV_MUX when creating a scan model for this multiplexer, follow these
general steps.
1. View the cell MU111.v.
June 2014
This cell is provided with your software at the following location:
.../<tessent_software_tree>/lib/technology/tgc1000/verilog/MU111.v.
Figure 3-14 presents the Verilog simulation model for MU111.v. The inset in Figure 3-
14 presents the Verilog simulation model for the UDP mu1udp.
2. Copy and edit the model to include only the required information, which is shown in
Figure 3-15.
3. Replace the multiplexer UDP with the Verilog primitive LV_MUX.
Mentor Graphics provides this primitive with your software at the following default
location:
.../<tessent_software_tree>/lib/technology/icbist/lvision/generic/LV_MUX.
June 2014
Figure 3-14. Verilog Simulation Model for Multiplexer
June 2014
Figure 3-15. Scan Model for Multiplexer
Programmable Pull-Up with UDP/Unsupported
Primitive
In this section, you create a scan model for the cell PR010.v using the standard Verilog
primitive bufif0.
Because PR010.v contains a user-defined primitive and an unsupported Verilog primitive, you
need to create a scan model as follows:
1. View the cell PR010.v.
This cell is provided with your software at the default location
.../<tessent_software_tree>/lib/technology/tgc1000/verilog/PR010.v.
Figure 3-8 presents the Verilog simulation model for PR010.v.
2. Copy and edit the model to include only the required information, as shown in Figure 3-
7.
3. Replace the unsupported standard Verilog primitive and UDP with the standard Verilog
primitive bufif0.
June 2014
Figure 3-16. Model for Programmable Pull-Up with UDP/Unsupported Primitive
Reviewing Verilog Syntax Rules
June 2014
Figure 3-17. Scan Model for Programmable Pull-Up with Power-Down Control
Figure 3-18. Pull-Up with Power-Down Control
The cell output (TAP) is connected to a peripheral input pad. The input PWRDN is connected to
an internal switch that, when taken to its active state, disables the pull-up function.
The following subsections define rules to follow when writing Verilog syntax regarding netlist
types, signal format, assign statements, comments, compiler directives and specify statements.
Netlist Type
The ruleAnalyze tool accepts all valid Verilog structural netlists. Behavioral or RTL
descriptions are not supported.
For more information about the Verilog cell library modeling rules, refer to the Verilog
Modeling Guide (Composite Veritool Library: Cadence).
Signal Format
The ruleAnalyze tool supports both bit and bus formatted signals. Internally, ruleAnalyze
scalarizes all signals. You can use both positional and by-name port mapping for designs.
June 2014
Assign Statements
The ruleAnalyze tool supports simple assign statements, such as single bit-to-bit or bus-to-bus
assigns; for example:
wire net_low, net_high;
assign net_low = 1b0, net_high = 1b1;
Comments
The ruleAnalyze tool supports both block comments and line comments.
A line comment starts with the two characters // and ends with a new line; for example:
//(c) Mentor Graphics, Inc 1993-2006
//Technology Release: 5.0
A block comment starts with /* and ends with */, as shown below:
/*
(c) Texas Instruments 1993
*/
You cannot nest block comments.
Compiler Directives
The ruleAnalyze tool recognizes only the compiler directives that are listed in Table 3-5.
Table 3-6 lists the compiler directives that ruleAnalyze ignores.
Table 3-5. Compiler Directives Supported by ruleAnalyze
celldefine endcelldefine resetall
default_nettype endif timescale
define ifdef undef
else include
define and undef support the definition of a text
macro name and macro text substitution. They do not
support parameters.
Table 3-6. Compiler Directives Ignored by ruleAnalyze
accelerate remove_gatenames
autoexpand_vectornets remove_netnames
delay_mode_path signed
Language Binding Rules
June 2014
The ruleAnalyze tool generates warnings when parsing compiler directives other than those
listed in either Table 3-5 or Table 3-6. The ruleAnalyze tool does not support protected models.
These models are defined by the protected and endprotected compiler directives. When
ruleAnalyze encounters this syntax, it ignores the complete protected statement, from protected
to endprotected directive.
Specify Statements
The ruleAnalyze tool ignores the complete specify statement, from the specify keyword to the
endspecify keyword.
Language Binding Rules
The following sub-sections explain how to resolve names appearing in VHDL architectures and
Verilog modules. These sections specifically cover names which refer to Verilog modules and
gates, and VHDL design units.
These binding rules apply to the following tools:
ETAssemble
designExtract
ruleAnalyze
scanGenerate
For detailed information about ETAssemble, refer to the manual ET Assemble Reference.
For detailed information about designExtract, ruleAnalyze, and scanGenerate, refer to the
manual ETAnalysis Tools Reference.
Verilog Name Resolution
During instantiation, the tools resolve names appearing in Verilog modules using the following
search order:
1. Try to resolve the name to either a Verilog gate or LV primitive.
2. If the statement containing the name resides in a library directory file specified by the -y
runtime option, check the embedded modules within that file for a match.
enable_portfaults suppress_faults
nounconnected_drive unconnected_drive
protect
Table 3-6. Compiler Directives Ignored by ruleAnalyze (cont.)
Creating Mapping Files
June 2014
3. Search the source files specified on the command line.
4. Search the libraries specified in any search directives such as the -y, -v, and -yvhdl
runtime options. The last option can be used to bind Verilog names to VHDL
architectures.
VHDL Name Resolution
During instantiation, the tools resolve VHDL names (references to packages, configuration
declarations, and entity declarations) by searching the VHDL libraries specified in the
appropriate use clauses. A library can also be specified explicitly using a selected name.
Libraries are searched by expanding file compilation rules specified in an lvlib file and scanning
the associated files. A VHDL name can be bound to a Verilog module by adding a file
compilation rule that covers the associated file.
Top-Level Design Specification
You can specify the top-level design entity or top-level configuration declaration in any of the
following ways:
Using the -r runtime option that specifies a top-level design entity (Verilog module or
VHDL entity).
Using the -arch runtime option in combination with the -r runtime option that specifies
an entity/architecture pair.
Using the -config runtime option that specifies a top-level configuration declaration.
When you do not specify any of the above options for the top level, the tools assume that the
first entity or module declaration in the first source file or the first entity associated with the first
architecture body in the first source file, along with its default architecture, is the top design
entity.
The scanGenerate tool uses two mapping files to insert scan and testpoints into your design.You
provide the following two files as input to the scanGenerate tool that are described in detail in
the manual ETAnalysis Tools Reference:
Scan mapping file For details refer to scang.lib File
Testpoint mapping file For details refer to tpStyle(n).scangLib File
The following sections describe how to create these mapping files:
Creating the Scan Mapping File
June 2014
Generating Testpoint Files
Creating a Testpoint Library
Creating the Scan Mapping File
The scan mapping file scang.lib lists technology-dependent, non-scannable cells and their
scannable equivalents. The tools support multiplexed, edge-triggered scan flip-flops. Table 3-19
illustrates a scannable flip-flop.
Figure 3-19. Scannable Flip-Flops
You create the scang.lib file, or edit the template file that Mentor Graphics provides at the
location ...<tessent_software_tree>/lib/technology/tgc1000/lvision/scang.lib. The
scanGenerate tool uses this scang.lib file to perform these tasks:
Identifies non-scannable flip-flops and replaces them with their scan equivalents.
Routes the scannable flip-flops into scan chains, using their scan-in and scan-out pin
specifications.
Inserts retiming/pipelining flops in the design, using the pipeline flops specified.
By default, scanGenerate searches for a scan mapping filescang.lib File. To specify a
filename other than scang.lib, use the -scanChainsMapping runtime option with your own
filename. In the LV Flow, you can specify the technology specific scang.lib file in the
.LVICTech File using the ScangLib property. This will ensure that scanGenerate is
automatically invoked with the correct scang.lib file during the ETScan step.
The scang.lib File is composed of the following:
The Library wrapper
Module specifications containing type, scanequivalent, and pin fields
This sub-section also contains a complete example of the scan mapping file on page 77 to fully
illustrate the syntax that is specified in each section of the scang.lib file.
June 2014
Library Wrapper
The scan mapping file consists of a Library wrapper that contains a set of module
specifications. The value of the Library wrapper is a string identifying the name of the
technology that the scan mapping file is supporting.
The Module specifications within the Library wrapper define relevant types of modules for scan
and testpoint insertion. Each Module specification contains a Type statement and Pin
specifications.
Figure 3-20 illustrates a tgc1000 library with two modulesTDB21 and TDC20.
Figure 3-20. Sample Syntax of Library Wrapper and Module Specifications
Library (tgc1000) {
Module (TDB21) {
Type: scan;
Pin (SCAN){
Function: scanenable;
}
Pin (SD){
Function: scanin;
}
Pin (Q){
Function: scanout;
}
Pin (QZ){
Function: scanoutnot;
}
}
Module (TDC20) {
Type: scan;
Pin (SCAN){
}
Pin (SD){
Function: scanin;
}
Pin (Q){
Function: scanout;
}
Pin (QZ){
}
}
}
June 2014
Module Specifications and Type Fields
Each Module specification must have a Type property that identifies what the module is. You
must customize the Module specifications for your technology library.
Relevant scan module types are as shown in Table 3-7:
Figure 3-21 shows modules for scannable and non-scannable types.
Figure 3-21. Sample Module Types
Module (TDB21) {
Type: scan;
.
.
.
}
Module (TDB21_PD) {
Type: priorityData;
.
.
.
}
Module (DTB21) {
Type: nonscan;
ScanEquivalent: TDB21;
ScanEquivalent: TDB21_PD;
.
.
.
}
Module (TO010) {
Type : tieHigh;
.
.
.
}
Module (TO010) {
Type : tieLow;
.
.
.
Table 3-7. Scan Module Types
AND priorityData pipeline
buffer scan tieHigh
inverter XOR tieLow
nonscan MUX holdingScan
OR latch floptray
NAND NOR
June 2014
}
Module (MU111) {
Type : MUX;
.
.
.
}
Module (TDB21) {
Type : pipeline;
.
.
.
}
Normal Scan Types
Modules with Type scan identify the module as a normal scan flip-flop; for example, TBD21.
PriorityData Scan Types
Modules with Type priorityData are priority-data-holding scan flip-flops with a clock-enable
signal; for example, TDB21_PD. These holding scan flip-flops are used to support multi-cycle
paths during LogicBist mode and to implement the capture-by-domain feature. These flip-flops
are part of the supplied gate library from ASIC vendors. You can, however, construct them
easily using normal scannable flip-flops that are combined with 2:1 multiplexers. The
scanMake tool is the best solution for creating the priority-data-holding scan flip-flops. Refer to
Creating Priority Data Flip-Flops and Testpoint Cells.
Nonscan Types
Modules with Type nonscan identify the module as a non-scannable flip-flop; for example,
DTB10. Each non-scannable flip-flop must have at least one scan-equivalent value that
identifies the scannable flip-flop to which it is mapped. The ScanEquivalent property in the
module block supplies this value.
For example, the following syntax defines the TDB21 scan-equivalent.
Module (TDB10) {
Type: nonscan;
}
The scanGenerate tool replaces any occurrence of a non-scannable module with its scan
equivalent. By default, scanGenerate uses the scan-equivalent flip-flop with type scan as the
replacement flip-flop. However, if the instance name of the current flip-flop is listed in a .lvmcp
file, or the current flip-flop is labeled as a transmit flop during the capture-by-domain
implementation, scanGenerate uses the scan-equivalent flip-flop with type priorityData as the
replacement flip-flop.
June 2014
In order to support the designs that already contain flops (with tied-off scanEnable/scanDataIn)
the Module wrappers with Type nonscan should also be defined for simple scan flops as
follows:
Module (TDB21) {
Type: nonscan;
}
This provides scanGenerate with the proper scan mapping information for the flops in these
pre-scan designs.
Buffer and Inverter Types
Modules with Type buffer and inverter identify the technology-specific buffer and inverter
cells, respectively. You use these modules for buffering or inverting the scan-enable and scan
output signals.
When scanGenerate encounters a flip-flop with a scan-enable-not pin, it uses the inverter that
you define in the scang.lib file to provide correct circuit operation.
In certain cases, scanGenerate also uses an inverter when a scan-out signal from a scan chain is
inverted with respect to the other scan-out signals (scanOut from QZ or scanOutNot of a scan
flip-flop). In order to support designs that already contain scan flops (with tied-off scanEnable),
Module wrappers, or the property Type nonscan should also be defined for simple scan flops as
follows:
Module (TDB21) {
Type: nonscan;
}
This provides scanGenerate with proper mapping information file for the flops in these pre-
scan designs.
OR Types
Modules with Type OR are relevant to both scan insertion and testpoint insertion. The
scanGenerate tool uses this module type to perform the following:
Implement the capture-by-domain feature
Control flip-flops transmitting data into multi-cycle paths
This module is also a primitive required within some of the testpoint modules.
You must include a two-input OR gate in your scang.lib file.
June 2014
AND Types
Modules with Type AND are relevant to both scan insertion and testpoint insertion. The
scanGenerate tool uses this module type to implement the capture-by-domain feature using
scannable flip-flops with scan-enable-not pins. This module is also a primitive that is required
within some of the testpoint modules. You must include a two-input AND gate in your scang.lib
file.
XOR Types
Modules with Type XOR (exclusive OR) are relevant to testpoint insertion. You must include a
two-input XOR gate in your scang.lib file.
MUX Types
Modules with Type MUX are relevant to the ScanMake and the scanGenerate tools. The
scanMake tool uses this module type when it generates the priority-data-holding scan flip-flops,
and scanGeneratewhen it inserts bridge cells. You must include a 2:1 multiplexer module in
your scang.lib File.
Pipeline Types
Modules with Type pipeline identify the non-scan flip-flops (if available) to be used by
scanGenerate to insert pipelining and retiming flip-flops in the scan chains. Since retiming flops
are essentially pipeline flops running on an opposite clock edge, we recommend specifying both
positive and negative edge pipeline flops in scang.lib File. This will prevent scanGenerate from
inserting an inverter in the clock path.
The scanMake tool provides an easy way for automatically selecting pipeline flops. By default,
it will try to select non-scan flip-flops with no set or reset control. If scan flops and/or flops with
asynchronous control are specified as pipeline flops, then scanGenerate will automatically tie
off any unused flop pins for each specific instantiations.
TieHigh and TieLow Types
Modules with Type tieHigh and tieLow identify the technology-specific tieoff cell(s). You
include these specification if you want scanGenerate to use these modules whenever it needs a
tied port connection to logic high or logic low. If you do not specify a tieHigh or tieLow module
then scanGenerate will use a constant net (such as 1'b0 in Verilog) for the port connection.
HoldingScan Types
Modules with Type holdingScan are data-holding scan flip-flops, with no clock-enable signal,
used only for tpStyle3 control testpoints. These holding flip-flops are used to support multi-
cycle paths and control testpoints that fan out to more than one clock domain. The scanMake
tool automatically creates the holdingScan flip-flops.
June 2014
Latch Types
Modules with Type latch are used for implementing retiming cells under certain conditions or
discrete clock gating cells when none is readily available. Following is an example of an active-
high latch:
module (LAT02) {
type: latch;
pin (d) {
function: datain;
}
pin (o) {
function: dataout;
}
pin (ck) {
function: clockp;
}
}
Floptray Types
Modules with Type floptray describe cells containing a pre-connected scan segment of N flops
with typically N individual functional data in/out ports, one clock port, one scan enable port,
and one scan in/out port. Following is an example of a floptray entry:
module (FLOPTRAY4) {
type: floptray;
pin (SCAN) {
function: scanenable;
}
pin (SD) {
function: scanin;
}
pin (SO) {
function: scanout;
}
}
NAND and NOR Types
Modules with Type NAND and NOR are used for generation of scan control logic.
Recommended Modules
Mentor Graphics suggests that you also include the following modules in your scang.lib file:
three-input OR
four-input OR
three-input AND
four-input AND
June 2014
three-input XOR
two-one MUX
These modules are not used as primitives within scan or testpoint modules. However,
scanGenerate might, in certain situations, use these modules either to insert control logic or to
construct complex testpoints (instead of cascading 2-input gates) that have reduced impact on
the timing performance of circuits.
Pin Specifications
Pin specifications identify the name and function of each pin for every technology-specific
module. The function defines the type of signal that is associated with the pin. You must
customize the pin specifications for your technology library. Table 3-8 lists possible pin types
and their corresponding functions.
Table 3-8. Pin Types Within Modules
Type of Pin Function
scanenable Scan mode control (shift or capture)
scanenablenot Inverted version of scan enable
scanin Scan data input
scanout Scan data output
scanoutnot Inverted scan data output
clockn Negative-edge triggered clock
clockp Positive-edge triggered clock
datain Data input
dataout Data output
dataoutnot Inverted data output
testmode Test mode enable
observation Observation port for testpoints
control Control port for testpoints
input Input pin for AND, OR, XOR, buffer, and inverter
input0 Select 0 input pin of a 2:1 multiplexer
input1 Select 1 input pin of a 2:1 multiplexer
output Output pin for AND, OR, XOR, buffer, inverter,
mux, tiehigh and tielow
June 2014
The following sections describe pin specifications for scan, nonscan, priorityData, pipeline,
and holdingScan types.
Scan Pins
In modules of Type scan, you specify the pins of the scan flip-flops used in the scan chain
connection and their corresponding functions. Therefore, these pin specifications equate each
pin of the module with a function that pertains to scan. scanGenerate uses these pin
specifications during scan-chain routing.
In Figure 3-22 for the TDB21 module, SCAN is the scan-enable pin, SD is the scan-in pin, and
Q and QZ are the scan-out and scan-out-not pins, respectively.
Figure 3-22. Pin Specifications for Scan Types
Module (TDB21) {
Type: scan;
Pin (SCAN){
}
Pin (SD){
Function: scanin;
}
Pin (Q){
Function: scanout;
}
Pin (QZ){
}
}
At a minimum, each scan module must have at least one scan-in pin, one scan-out or scan-out-
not pin, and one scan-enable or scan-enable-not pin.
PriorityData Pins
In modules of Type priorityData, you specify the pins of the priority-data-holding scan flip-
flops that are used in the scan-chain connection and their corresponding functions. Therefore,
these pin specifications equate each pin of the module with a function that pertains to scan.
scanGenerate uses these pin specifications during scan-chain routing. As a minimum,
priorityData flip-flops must have the following pin specifications:
clockenable Pin controlling data-hold operation
select Select pin of a 2:1 multiplexer
user User-defined and arbitrary pin wired to the top level
reset Active-high reset for testpoints.
restnot Active-low reset for testpoints.
Table 3-8. Pin Types Within Modules (cont.)
June 2014
scan-in
scan-out or scan-out-not
scan-enable or scan-enable-not
clock-enable
In Figure 3-23, instance TDB21_PD has five pins: SCAN, SD, Q, QZ, and CE. Notice that
SCAN, SD, Q, and CE meet the minimum requirements for scan-in, scan-out, scan-enable, and
clock-enable pin specifications. The QZ pin with the scan-out-not function is optional.
Figure 3-23. Pin Specifications for PriorityData Types
Module (TDB21_PD) {
Type: prioritydata;
Pin (SCAN){
}
Pin (SD){
Function: scanin;
}
Pin (Q){
Function: scanout;
}
Pin (QZ){
}
Pin (CE){
Function: clockenable;
}
}
Non-Scan Pins
In nonscan modules, you specify each pin of the nonscannable module and the name of its
mapped pin from the scan and priorityData modules. Therefore, these pin specifications
identify a mapping from the nonscan flip-flop to the scan flip-flop that is identified as the
scanequivalent.
In Figure 3-24, the CLK pin of an instance of DTB10 is connected to CLK pin of the
replacement scan flip-flop TDB21.
Figure 3-24. Pin Specifications for Non-Scan Types
Module (DTB10) {
Type: nonscan;
Pin (CLK){
ScanEquivalent: CLK;
}
Pin (CLRZ){
June 2014
ScanEquivalent: CLRZ;
}
Pin (D){
ScanEquivalent: D;
}
Pin (PREZ){
ScanEquivalent: PREZ;
}
Pin (Q){
ScanEquivalent: Q;
}
Pin (QZ){
ScanEquivalent: QZ;
}
}
Note
Note that if the pin names and functions of the nonscan module have identical pin names
and functions within the scanequivalent module, the module specification for the
nonscan module does not need to include any pin statements. Figure 3-25 illustrates the
module specification for the same module as Figure 3-24. Because pin names and
functions for the nonscan module have identical names/functions in the ScanEquivalent
module, the pin statements are not required.
Figure 3-25. Module Specification for Identical Scan/Nonscan Pin Names and
Functions
Module (DTB10) {
Type: nonscan;
}
When the pin names and functions of the non-scannable module have identical pin names and
functions within both the scanequivalent scannable module and the ScanEquivalent
priorityData module, you can combine the references to both ScanEquivalent modules in the
same nonscan module specification. Figure 3-26 illustrates the format you can use in this case.
Figure 3-26. Module Specification for Nonscan Pin Names
Module (DTB10) {
Type: nonscan;
}
You can run the scanMake utility to automatically add the ScanEquivalent priorityData
modules to your design. Refer to Running the scanMake Utility.
June 2014
Pipeline Pins
In the pipeline modules, you specify the pins and functions of the flip-flops to be used for
pipelining and retiming in the scan chains. The scanGenerate tool uses these pin specifications
during scan-chain routing to connect the pipelining/retiming flip-flops in the scan data path.
Two pipeline modules should be declared in scang.lib Fileone with positive-edge clock
(using clockp) and one with negative-edge clock (using clockn). When this is done,
scanGenerate will never need to insert an inverter in the clock path to implement pipelining and
retiming flops.
In Figure 3-27, instance TDB21 has 3 pinsD, CK, and Q.
Figure 3-27. Pin Specifications for Pipeline Types
Module (TDB21) {
Type: pipeline;
Pin (D){
Function:datain;
}
Pin (CK){
Function: clockp;
}
Pin (Q){
Function: dataout;
}
}
Retiming and Pipelining Flop Support
The scanGenerate tool requires at least one module with Type pipeline to be defined in scang.lib
File. It uses this module information for inserting pipelining and retiming flops in the netlist.
The scanGenerate tool also uses the corresponding scanequivalent flop for inserting pipelining
flops in multi-cycle-path (MCP) chain segments.
Pipelining Flops
The scanGenerate tool implements a pipelining flop on a positive-edge clock chain segment by
inserting the flop specified in a module with Type pipeline and pin function clockp. If no such
module is defined in the scang.lib File, then the flop specified in a module with Type pipeline
and pin function clockn will be used, along with an inverter inserted on its clock pin.
Retiming Flops
Retiming flops are essentially pipelining flops running on a clock edge opposite to the other
flops from the same chain segment. Accordingly, scanGenerate implements a retiming flop on a
positive-edge clock chain segment by inserting the flop specified in a module with Type
pipeline and pin function clockn. If no such module is defined in the scang.lib File, then the flop
June 2014
specified in a module with Type pipeline and pin function clockp will be used, along with an
inverter inserted on its clock pin.
Note
In this context, exactly one positive-edge module and one negative-edge module with
Type pipeline should be specified in the scang.lib File. If only one module with Type
pipeline is specified instead, then scanGenerate will be forced to insert an inverter on the
flops clock pin in order to implement the required pipelining or retiming functionality.
Note that this might not be acceptable in some design environments.
Scan-Only Library
If the flop specified for a module with Type pipeline is a scan flop, then scanGenerate will
automatically tie off its scanEnable/scanData flop inputs when these are not required (i.e. for
implementing retiming or non-MCP pipelining flops). No special user specification is required
in the scang.lib file.
Asynchronous Control
Similarly, if the flop specified for a module with Type pipeline has set and/or reset pins, then
scanGenerate will internally identify these pins by analyzing its scan model and, during
retiming/pipelining flop insertion, will automatically tie such pins to their neutral value. No
extra user specification is required in the scang.lib file.
Testpoint Cell Definitions
The scang.lib File also contains module specifications for testpoint cells. Table 3-9 lists the
types of testpoint cells that appear in the scang.lib file and provides examples of testpoint
module names.
Testpoint module definitions appear in both the scang.lib File and tpStyle(n).scangLib File. The
scang.lib file describes solely the scan aspect for these modules, while the tpStyle<n>.scangLib
Table 3-9. Available Testpoint Cell Definitions
Type of Testpoint Cell Polarity Example
Observation point positive
negative
TP3_OBS_P
TP3_OBS_N
XOR control point positive
negative
TP3_XOR_P
TP3_XOR_N
OR control point positive
negative
TP3_OR_P
TP3_OR_N
AND control point positive
negative
TP3_AND_P
TP3_AND_N
June 2014
file provides the functionality and complete pin description of the testpoints modules. Refer to
Generating Testpoint Files for details.
Complete scang.lib File
Figure 3-28 illustrates the syntax of the scang.lib File. For detailed information on this file,
refer to the ETAnalysis Tools Reference manual.
Figure 3-28. scang.lib File Syntax
Library (technologyName) {
VhdlPackage: <packageName>;
Module (moduleName) {
Type: buffer | inverter | nonscan | scan | prioritydata | AND |
OR | MUX | tieHigh | tieLow | pipeline | holdingscan | XOR |
latch | floptray | NAND | NOR;
ScanEquivalent: <moduleEquivalent>;
Pin (<pinName>){
Function: input | output | scanenable |
scanenablenot | scanin | scanout |
scanoutnot | clockenable | input0 |
input1 | select| clockp| clockn|
dataout | dataoutnot |
open | datain | reset | resetnot;
}
Pin (<pinName>){
ScanEquivalent: <scanpinName>;
}
}
}
Generating Testpoint Files
To include testpoints in your ASIC design, you need the following three items:
Testpoint module definitions in the scang.lib file
tpStyle<n>.scangLib mapping file, where n represents a number
Technology-specific testpoints library
To generate these items, use the scanMake utility, which is described in Running the scanMake
Utility.
Generating your testpoints with scanMake provides you with all required items in one step.
The scanMake tool creates all testpoints that are properly described in the testpoint mapping file
which is in the directory .../lib/technology/icbist/lvision/example. You do not need to modify
this file. The scanGenerate tool automatically finds the file in the directory. You use the
recommended testpoint style3, which is illustrated in Figure 3-29.
June 2014
The scanMake tool adds the proper testpoint definition for scan insertion in the scang.lib File
that it modifies and, if needed, creates tpStyle(n).scangLib Filetestpoint mapping files with
different port names and functions than the default one provided in
...<tessent_software_tree>/lib/technology/icbist/lvision/example/. You only need to create your
own testpoint mapping file if you have your own testpoints that were not generated using
scanMake and that have different port and module names from the testpoints described in the
supplied testpoint mapping file. Copy the sample testpoint mapping file and modify the port and
module names accordingly.
The supplied testpoint mapping file tpStyle3.scangLib provides the testpoint module
descriptions that the scanGenerate tool uses when inserting asynchronous testpoints into your
design to improve fault coverage. The tools now solely use and support the style3 testpoints.
These testpoints combine the advantages of the deprecated style1 and style2 testpoints without
their limitations. The style3 testpoints use an asynchronous reset (or set) signal to reset the
testpoints during the functional mode. The asynchronous reset signals are held active during
functional mode so that no power is consumed by the testpoints in mission mode. The presence
of asynchronous reset also greatly simplifies the task of running Formal Verification between
the pre- and post-scan inserted netlist. The faults associated with asynchronous reset of the
testpoints are fully covered using the AsyncSetResetTest property of the ETVerify
configuration file.
The scanGenerate tool loads the testpoint mapping file only when you specify the -testPoints
runtime option to On.
By default, scanGenerate searches for a testpoint mapping file with the name tpStyle3.scangLib.
To specify a filename other than tpStyle3.scangLib, use the -testPointMapping runtime option
with your own filename.
Testpoint Styles
Mentor Graphics supplies the testpoint mapping filetpStyle3.scangLibThis testpoint
mapping file defines asynchronous testpoints. To reset these testpoints asynchronously, take
TRST to its active state (active tpStyle(n).scangLib File low).
June 2014
Figure 3-29. Testpoint Module SpecificationStyle3
Module (TP3_XOR_P) {
Type: tp_xor;
Pin (SDI){
Function: scanin;
}
Pin (RSTB){
Function: resetnot;
}
Pin (CNTRL){
Function: control;
}
Pin (CLK){
Function: clockp;
}
Pin (Q){
Function: scanout;
}
}
Testpoint Control and Observe Modules
This section lists the asynchronous testpoint modules for controllability and observability that
are available for use with the scanGenerate tool. The suffix _P represents positive edge-clocking
and the suffix _N represents negative edge-clocking.
File Requirements
Of the seven testpoint module types that are available (tp_xor_obs, tp_or_obs, tp_obs, tp_xor,
tp_or, tp_and, and tp_and_obs), the testpoint mapping file must contain modules with the
following types:
tp_and
tp_or
Table 3-10. Asynchronous Testpoint Control and Observation Modules
Testpoint Name Type Value Function
TP3_OBS_P
TP3_OBS_N
tp_obs Observation point
TP3_XOR_P
TP3_XOR_N
tp_xor XOR control point
TP3_OR_P
TP3_OR_N
tp_or OR control point
TP3_AND_P
TP3_AND_N
tp_and AND control point
Creating Priority Data Flip-Flops and Testpoint Cells
June 2014
tp_xor
tp_obs
For each testpoint module in the testpoint mapping file, you must ensure that the scan mapping
file (scang.lib) contains a scan model with the same module name. For example, you must
include a module with the name TP1_OR_P in the scan mapping file with the module type scan
if you included this testpoint in your testpoint mapping file. This requirement allows
scanGenerate to complete both testpoint and scan-chain insertion. This description is
automatically inserted into the scang.lib file if you use scanMake.
For more information on the scang.lib file, refer to Creating the Scan Mapping File.
The section tpStyle(n).scangLib File in the manual ETAnalysis Tools Reference provides a
complete example of the scan mapping file tpStyle<n>.scanglib.
Creating a Testpoint Library
To include testpoints in your ASIC design, you must also provide a technology-specific
testpoints library. You create this library by running the scanMake utility. For a description of
how to use this utility, refer to the next sectionCreating Priority Data Flip-Flops and
Testpoint Cells.
Creating Priority Data Flip-Flops and Testpoint
Cells
The scanMake utility lets you automatically create cell models for priority-data holding scan
flip-flops and testpoints. The scanGenerate and ruleAnalyze tools use the models that are
created by scanMake.
Using a scan model library and scan mapping file that you specify, scanMake automatically
generates the cells. scanMake writes these generated cells, a modified scan mapping file, and
potentially new testpoint mapping files to an output directory that you specify. The scanMake
tool also writes an output log file, scanmake.log, to the current working directory.
Running the scanMake Utility
Before you use scanMake, you must create the scan models for your library cell primitives that
the tool requires. Scan models are necessary because scanMake performs basic connectivity
checks to identify certain ports such as the D input of a flip-flop. For more information, refer to
Creating Models for Rules Checking.
1. Create a scan mapping file. Refer to Creating the Scan Mapping File.
2. Ensure that your scan mapping file has the following elements:
Creating Priority Data Flip-Flops and Testpoint Cells
June 2014
o Mapping for nonscan flip-flops to scan flip-flops
o A two-to-one (2:1) multiplexer cell specification
o A two-input AND or NAND gate (testpoints only)
o An inverter
3. Set the appropriate runtime options for using scanMake from the command line:
o Specify the executable name:
scanmake
o Specify one or more technology search paths for library cells using the -y option to
the scanMake utility. Sample syntax is as follows:
-y lvision
o Specify one or more extensions for the source files.
-extension v
o Specify the name of the scan mapping file that contains mappings between nonscan
and scan flip-flops. scanMake processes this information when generating priority-
data scan flip-flops.
-scanChainsMapping lvision/scang.lib
By default, scanMake searches for scang.lib in the directories specified with the -y
option.
o Specify the format string to use when naming priority-data cells. The default is
%s_PD, where %s is replaced with the nonscan cell name.
-format %s_PD
o Indicate the name of clock enable port created for the prioritydata holding scan
cells. The default is CE.
To specify a name other than CE, use the following syntax:
-clockEnableName <clockEnablePortName>
where clockEnablePortName is a valid Verilog identifier such as CE1 or myCE12.
o Specify which non-scan flip-flop to use as the pipeline
flip-flop. By default, scanMake uses the first simple non-scan flip-flop specified in
the scang.lib file.
To specify the name of the non-scan flip-flop, use the following syntax:
-pipelineFlop <nonScanFlopName>
This option can be repeated to specify a flip-flop of another clock polarity.
Creating Synchronizer Cell Support
June 2014
o Indicate the name of the output directory in which scanMake places the generated
cells and updated scan mapping file. The default output directory is outDir in the
current working directory.
To specify a directory other than the default, use the following syntax:
-outputdir <outputDirectoryName>
where outputDirectoryName is a valid operating system directory path.
o Indicate whether or not scanMake generates testpoints. The default value On enables
the generation of testpoint cells; Off disables the generation of testpoint cells.
-testpoints On
o Specify the format string to use when naming holdingScan cells. The default is
%s_HS, where %s is replaced with the nonscan cell name.
-holdingScanFormat %s_HS
o Indicate in which language to generate the cells. The two available languages are
Verilog and VHDL. The default language is Verilog.
-language VHDL
o Indicate the extension used for the generated cells. By default, -outputExtension is
vb when -language is verilog and vhd when -language is VHDL.
-outputExtension vb
4. Run the executable.
5. Check the output directory. It contains a library of cells.
6. Move the output directory to your technology area.
Some ASIC libraries contain Synchronizer cells that consist of two back-to-back flops. They are
distinguished from two flop shift register cells by the additional constraint that the first flop of
the synchronizer cell does not fan out (in functional mode) and only drives the input of the
second flop of the synchronizer cell.
An example of a synchronizer cell is shown in Figure 3-30. Scannable version of this cell is
shown in Figure 3-31.
June 2014
Figure 3-30. Synchronizer Cell
Figure 3-31. Scannable Version of Synchronizer Cell
This section provides instructions for creating synchronizer cell support for ASIC libraries
consisting such cells.
Note
Synchronizer cells are supported by the core ETLogic tools, but are not supported by the
scanMake utility mentioned in this document. All scan models, priority data models, and
edits to the scang.lib file will need to be performed by you AFTER the scanMake utility
has been run. The scanMake utility does not support multi-flop cells, so you will need to
make priority-data versions for the synchronizer cells manually as described in this
section
To create support for a synchronizer cell, you perform the following steps:
1. Create a priority data flip-flop version of the cell. (Usually, a scannable version of the
synchronizer cell already exists.)
2. Update the scang.lib scan mapping file with a reference to the priority data flip-flop.
June 2014
3. Add a wrapper to the UDPs (if not already present) of the Verilog simulation models of
the synchronizer cell and its scannable versions. This step is required for verilog
parallel-load simulation to work properly.
Instructions on how to accomplish the above steps are listed below.
Creating Priority Data Flip-Flops
This section provides examples of the syntax used to create a priority data flip-flop version of a
synchronizer cell. In Figure 3-32 and Figure 3-33, the Verilog simulation models are shown for
a synchronizer cell dfs1 and its scannable equivalent sdfs1.
Figure 3-32. Model of Synchronizer Cell dfs1.v
`celldefine
module dfs1 (D,CP,Q,QN);
input CP,D;
output Q,QN;
wire Q_INT;
udp_dfs inst1 (Q_INT, D, CP);
udp_dfs inst2 (Q, Q_INT, CP);
not inst3 (QN, Q);
endmodule
èndcelldefine
Figure 3-33. Model of Scannable Version of Synchronizer Cell sdfs1.v celldefine
module sdfs1 (CP,SE,SI,D,Q,QN);
input CP,D,SE,SI;
output Q,QN;
wire D_INT,Q_INT;
udp_dfs inst1 (Q_INT , D_INT , CP);
udp_mux inst2 (D_INT , D , SI , SE );
udp_dfs inst3 (Q, Q_INT, CP);
not inst4 (QN, Q);
endmodule
èndcelldefine
You can use flip-flop cells and multiplexer cells from the ASIC library to create the priority data
version of a synchronizer cell.
In Figure 3-34, the priority data version of the cell is built using two sdfp scan flip-flops and two
2:1 multiplexers. Figure 3-35 illustrates the resulting cell.
June 2014
Figure 3-34. Priority Data Version of Synchronizer Cell pd_sdfs1.v
`celldefine
module pd_sdfs1 (CP,CE,SE,SI,D,Q,QN);
input CP,D,CE,SE,SI;
output Q,QN;
wire D_INT,Q_INT;
sdfp inst1 (.Q(Q_INT),.QN(),.SE(SE),.D(D),.SI(SI_CE1), .CP(CP));
mx21 inst2 (.A(Q_INT),.B(SI),.S(CE));
sdfp inst3 (.Q(Q),.QN(QN),.SE(SE),.D(Q_INT),.SI(SI_CE2),.CP(CP));
mx21 inst4 (.A(Q),.B(Q_INT),.S(CE));
endmodule
èndcelldefine
Figure 3-35. Priority Data Synchronizer Cell
Updating the Scan Mapping File
The scan mapping file (scang.lib) entries for the synchronizer cells are the same as the entries
for regular cells. You update the scang.lib file by making a reference to the new priority data
flip-flop version.
Figure 3-36 provides an example of the entries in the scang.lib file for referencing the new
priority data flip-flop pd_sdfs1.
Figure 3-36. Scan Mapping File Entries for Synchronizer Cells
Module (dfs1) {
Type: nonscan;
ScanEquivalent: scpp1;
ScanEquivalent: pdscpp1;
}
June 2014
Module (sdfs1) {
Type: scan;
Pin (SE){
}
Pin (SI){
Function: scanin;
}
Pin (Q){
Function: scanout;
}
}
Module (pd_sdfs1) {
Type: prioritydata;
Pin (SE){
Function: scanenable; }
Pin (CE){
Function: clockenable;
}
Pin (SI){
Function: scanin;
}
Pin (Q){
Function: scanout;
}
}
Adding the UDP Wrapper to the Simulation Model
To support Verilog parallel-load simulation, force and compare events need to be performed on
the ports of the flip-flops. In synchronizer cells, this may not be possible if the flip-flops are
user-defined primitives (UDPs) directly instantiated in the synchronous cell. Apparently, a
limitation of the simulation engine exists: it cannot do a force event directly on the port of a
UDP. To overcome this limitation, you need to add a simple wrapper around the UDP
instantiation in the synchronous cell.
Figure 3-37 illustrates the Verilog simulation model with UDP wrappers of the scannable
version of the synchronizer cell sdfs1.v.
Figure 3-37. Model with UDP Wrappers of Synchronizer Cell sdfs1.v
`celldefine
module sdfs1 (CP,SE,SI,D,Q,QN);
input CP,D,SE,SI;
output Q,QN;
wire D_INT,Q_INT;
udp_dfs_wrap inst1 (Q_INT , D_INT , CP);
udp_mux_wrap inst2 (D_INT , D , SI , SE );
udp_dfs_wrap inst3 (Q, Q_INT, CP);
not inst4 (QN, Q);
endmodule
èndcelldefine
June 2014
`celldefine
module udp_dfs_wrap(Q, D, CP);
input D,CP;
output Q;
udp_dfs inst1 (Q, D,CP);
endmodule
èndcelldefine
`celldefine
module udp_mux_wrap(Z,A, B,S);
input A,B,S;
output Z;
udp_mux inst1 (Z,A,B,S);
endmodule
èndcelldefine
June 2014
June 2014
Chapter 4
Reviewing ETChecker Step
This chapter briefly describes Step 1: ETChecker of the LV Flow. For detailed information on
how to run ETChecker and complete reference on rules, runtime options, properties, and output
files of the ETChecker tool, refer to the ETChecker Users and Reference Manual.
Chapter topics follow this sequence
Step 1: ETChecker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Running ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Step 1: ETChecker
In the first step of the LV Flow, you run ETChecker on your design to make sure it meets the
embedded test requirements and to extract all pertinent design information. This step is
illustrated in Figure 4-1.
Step 1: ETChecker
June 2014
Figure 4-1. Running ETChecker on the Chip
Figure 4-2 shows what the ETChecker configuration file might look like for this example.
Step 1: ETChecker
June 2014
Figure 4-2. Top.etchecker Configuration File
Running ETChecker
This section briefly describes how to verify the compliance of your RTL chip against the
Mentor Graphics Embedded Test requirements. The ETChecker tool assists you with verifying
the compatibility of your chips RTL with respect to the requirements outlined in RTL
Description Requirements in the ETChecker Users and Reference Manual. This task is
performed using the following four steps:
Step 1: Generate Initial Configuration File run ETChecker to generate a
configuration file template. You edit this template to set specific attributes about the
circuits and your embedded test objectives.
Step 2: Extract Clock Domain Base Lists run ETChecker to analyze your RTL and to
extract clock domain bases. You confirm and/or modify these entries and update the
configuration file with the correct clock domain bases properties.
Step 3: Check Design Rules run ETChecker to verify that your design meets the rules
and requirements described in RTL Description Requirements in the ETChecker
Users and Reference Manual. Adjust your RTL and/or the properties in the
configuration file until no errors are encountered.
Step 4: Hand Off etCheckerInfo file(s) save the etCheckerInfo files generated by
ETChecker and hand off the files to the engineer preparing the lvWorkSpaces for your
chip.
In the same step, you perform the following task: Create the etCheckerInfo files for
ETChecker runs.
Step 1: ETChecker
June 2014
Figure 4-3 illustrates the steps and the different modes in which ETChecker is run. Each step
and mode is described in subsequent sections following the figure.
Figure 4-3. Flow for Verifying the Compliance of Your RTL
For detailed information on how to run ETChecker and complete reference on rules, runtime
options, properties, and output files of the ETChecker tool, refer to the manual ETChecker
Users and Reference Manual.
For detailed usage information on creating prerequisite input files for The LV Flow, refer to
section Completing the LV Flow Prerequisites.
For information on recommended clocking scenarios, refer to section Logic Test and Memory
BIST Clocking on Chip Examples.
June 2014
Chapter 5
Planning and Generating the LV Flow
Environment
This chapter describes in detail Step 2: ETPlanner of the LV Flow. This chapter explains how
to plan and generate the LV Flow environment for inserting embedded test structures into your
design using the ETPlanner tool.
Chapter topics follow this sequence:
Step 2: ETPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Generating the Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
.etCheckerInfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
.memLib Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
.physicalInfo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
.LVICTech File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
.ETDefaults File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
.CADSetup File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
DEF or PDEF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Running ETPlanner to Create Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Generated .etplan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Memory BIST Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Example .etplan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Editing the Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Using Regular Expression Syntax in .etplan File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Validating the Embedded Test Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
.ETSummary File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Fixing Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Verifying the Regular Expression Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Generating the LV Flow Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Running ETPlanner to Generate the LV Flow Environment . . . . . . . . . . . . . . . . . . . . . . . 115
Output from ETPlanner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Managing Updates of the RTL- or Gate-Level Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Planning and Generating the LV Flow Environment
Step 2: ETPlanner
June 2014
Step 2: ETPlanner
After verifying your design to ensure it meets the Tessent embedded test rules and
requirements, you perform the ETPlanner step to plan and specify your embedded test
configuration and generate the LV Flow environment in which you will execute the remaining
steps of the LV Flow. To ensure that this step is successful and accurate, your design must have
passed the rule checks applied by the ETChecker tool as described in the previous chapter
Reviewing ETChecker Step.
Once you obtain a clean run of ETChecker, the etCheckerInfo file generated by ETChecker
must be provided to the ETPlanner tool. You cannot run ETPlanner before you have a valid
etCheckerInfo file generated by ETChecker.
This section describes the tasks you perform to plan and generate your LV Flow environment
using ETPlanner. Figure 5-1 illustrates these ETPlanner tasks.
Figure 5-1. Sub-Steps for Running ETPlanner
These are the sub-steps you perform:
Task 1: Generating the Embedded Test Plan You run ETPlanner to create the .etplan
configuration file that describes all embedded tests needed for your chip and consistent
with your test requirements.
Generating the Embedded Test Plan
June 2014
Task 2: Editing the Embedded Test Plan (Optional) You perform minor edits to the
generated .etplan file to specify some paths to your design environment and, optionally,
adjust a few options to specify exceptions you might have.
Task 3: Validating the Embedded Test Plan You review the .ETSummary file
generated by ETPlanner and verify the embedded test plan you edited.
Task 4: Generating the LV Flow Environment You run ETPlanner to create the
complete LV Flow environment for generation, insertion, and verification of the
embedded structures into your design.
First, you create the embedded test specification plan by running the ETPlanner tool in GenPlan
mode.
This section describes the make target, input files, runtime options, and output files associated
with running the ETPlanner tool to generate the embedded test plan.
Figure 5-2 illustrates the summary of operations that include the make target, input and output
files for generation of the embedded test plan for your design.
Figure 5-2. Generating the Embedded Test Plan
.etplan
make <module>.genPlan
.etpPhysicalInfo *
.etcheckerInfo
Output Files from
.memLib**
.ETDefaults
.LVICTech
.CADSetup
Optional Files
DEF or PDEF
Step1: ETChecker
* If you have memories in your design, and you specified lv.EmbeddedTest -memory On.
** Optional but recommended if your design has memories. Most of the memory planning is
done using the information from memory library files.
.etplan.README
MakeFile
June 2014
Input Files to ETPlanner
These files serve as input to ETPlanner:
.etCheckerInfo File
and
Optional Files:
o .memLib Files Highly recommended for proper planning
o .physicalInfo File
o .LVICTech File
o .ETDefaults File
o .CADSetup File
o DEF or PDEF Files
.etCheckerInfo File
The etCheckerInfo file, generated by ETChecker, contains all relevant information extracted for
the RTL description of your design which affects its embedded test requirements. This file is
required to run ETPlanner. For more information on ETChecker, refer to Reviewing
ETChecker Step.
.memLib Files
The memLib files are optional for generating the embedded test plan but highly recommended
for any design that includes memories. These files include information about memories
embedded into your circuit.
Note
Mentor Graphics highly recommends that you define the MilliWattsPerMegaHertz
property in each memory library file. This will assure that accurate power estimate is
taken into account during memory BIST partitioning.
For detailed information on this file, refer to Memory Library File in the manual ETAssemble:
Reference.
June 2014
.physicalInfo File
The .physicalInfo file contains the memory clusterIDs you might have assigned to your
memories using an lv.MemoryInstance property when running ETChecker. This file is
generated by ETChecker and should not be hand modified. You do not have to specify the
cluster identification in ETChecker if you have DEF or PDEF files describing the physical
coordinates of your memories. It is important to have the cluster identification either extracted
from PDEF/DEF or manually specified in ETChecker to make sure that memories, that are not
physically close to each other, do not share a memory BIST controller. A manual clusterID
defined with ETChecker property has higher priority than those extracted from DEF/PDEF
files. You can use the manual clusterID definition to force a given memory to use its own
memory BIST controller even if it is close to other compatible memories. Note that memories
can be part of the same domain in order to share a memory BIST controller.
Note
The .physicalInfo file is mandatory if the current physical region includes memories and
if you specify lv.EmbeddedTest -memory On.
.LVICTech File
This file is generally set up by the central CAD group and is used to point to the location of the
following technology files:
Simulation models
Mentor Graphics models and library files
Synthesis models and library files.
The .LVICTech file is pointed to by the -ICTechFile runtime option. The default value of the
-ICTechFile runtime option is extracted from the LV_ICTECH_FILE environment variable.
By setting the LV_ICTECH_FILE environment variable in your .cshrc file, you will instruct
ETPlanner to automatically use this file for each ETPlanner run.
For detailed information on this file, refer to .LVICTech File in the manual ETPlanner:
Reference.
.ETDefaults File
This file defines all embedded test defaults for memory BIST and logic BIST, such as
diagnostic features, power limits, etc. A set of built-in defaults will be used to generate the
.etplan file if you do not specify this file with runtime option -etDefFile. It is recommended to
define this file and adjust a few design-specific limits such as MaxPowerPerStep.
Typically, this file is set up by the central CAD group or ASIC vendor and might vary based on
the application of the chip.
June 2014
The .ETDefaults file is pointed to by the -etDefFile runtime option. The default value for this
option is extracted from the LV_ETDEF_FILE environment variable. If the above environment
variable is not defined, ETPlanner will assume that the required properties are included in the
.etplan file. By setting the LV_ETDEF_FILE environment variable in your .cshrc file, you will
instruct ETPlanner to automatically use this file for each ETPlanner run.
Global Embedded Test Properties
These properties do not affect embedded test planning but will be forwarded to ETAssemble to
influence the embedded test process. You can define these properties in the .ETDefaults file if
you want to change their default values.
MergeFlow : (RTL) | Gate;
InjectTCKOnClockSourcesInBlocks : Never | (InternalSourceOnly) | Always;
GateBistClockInFuncMode : Yes | (No);
TestKompressScanChainNumber : <int>;
ClockCellInstancePrefix : LV_CLOCK_CELL_;
Properties for Logic BIST Planning
There are four main properties used in logic BIST planning. Their default values are also shown
in the example below.
MaxLogicBistTestTime : 500ms;
ShiftClockFrequency : 100.0;
MaxScanSegmentNumber : 250;
LogicBistVectorNumber : 100000;
MaxChainLength is computed as
(MaxLogicBistTestTime * ShiftClockFrequency) /LogicBistVectorNumber.
ChainNumber is then computed as FlopCount / MaxChainLength.
If ChainNumber is computed to be larger than MaxScanSegmentNumber, it is then set to
MaxScanSegmentNumber, and MaxChainLength is then recomputed to be FlopCount
/MaxScanSegmentNumber.
The .ETSummary file described in the next section computes these values.
Properties for Memory BIST Planning
There are four main properties used in memory BIST planning. Their default values are also
shown in the example below:
MaxTestTimePerController : 500ms;
MaxStepsPerController : 0;
MaxPowerPerStep : 50;
MaxMemoriesPerStep : 0;
June 2014
The memories are separated into different controllers and controller steps in order to meet these
requirements. The generated .etplan file described the resulting memory BIST partitioning. For
more details about the memory BIST partitioning procedure, refer to Memory BIST
Partitioning.
For detailed information on all available wrappers and properties in this file, refer to
.ETDefaults File in the manual ETPlanner Tool Reference.
.CADSetup File
This file contains a description of your CAD environment and describes the default simulator
and the simulation commands you want to use. It also describes what synthesis tool to be used
and the name of the command to create directories and soft links. Typically, this file is defined
by the central CAD group.
The .CADSetup file is pointed to by the -CADEnvFile runtime option. The default values for
this file are extracted from the LV_CADENV_FILE environment variable generated by the
ETChecker. By setting the LV_CADENV_FILE environment variable in your .cshrc file, you
will instruct ETPlanner to automatically use this file for each ETPlanner run.
For detailed information on this file, refer to .CADSetup File in the manual ETPlanner:
Reference.
DEF or PDEF Files
Typically, a DEF (Design Exchange Format) file or a PDEF (Physical Design Exchange
Format) files are generated by a Floor Planner/Physical Design tool. Specification of the DEF
file allows ETPlanner to partition the memories according to physical clusters. If a DEF file is
specified, the cluster information is derived from the physical memory coordinates in the file. If
a PDEF file is specified and the PDEF file already contains cluster information, it will be used.
Note that you can also specify manual overrides to the cluster information in the ETChecker
using the lv.MemoryInstance property with the -clusterID option.
A list of DEF (Design Exchange Format) files or PDEF (Physical Design Exchange Format)
files can be pointed to by the -defFile runtime option. Typically, one DEF or PDEF file is
generated per physical (layout) region by your Floor Planning tool or your Physical Design tool.
For each DEF or PDEF file specified, the cluster information for the memories will be
computed from the memory coordinates. If a PDEF file is specified that does not contain
coordinates (Output of your Floor Planning tool), then the cluster information contained in it
will be used.
June 2014
Running ETPlanner to Create Embedded Test Plan
You use the following commands to invoke ETPlanner in GenPlan mode for the first time:
etplanner <designName>
-etCheckerInfoFile <etCheckerInfo>\
-physicalInfoFile <physicalInfoFile>\
-etDefFile <etDEFfile>\
-CADEnvFile <CADEnvFile>\
-ICTechFile <ICTechFile>\
-defFile <defFileList> \
-lvdbDir <dirName> \
-preLayoutLVDBDir <dirName>
Note that you do not need to specify -etDefFile, -CADEnvFile, and -ICTechFile if you have
defined the associated LV_ETDEF_FILE, LV_CADENV_FILE, and LV_ICTECH_FILE
environment variables in your .cshrc file
You specify the -lvdbDir and, optionally, the -preLayoutLVDBDir runtime options to point to
the signed-off LVDB and the pre-layout LVDB of child physical regions when you are using
the Bottom-Up Methodology.
These files are created during this sub-step:
Makefile This file contains all necessary make targets to run the remaining sub-steps
of the ETPlanner step. It also includes the make target to rerun this sub-step:
o make genPlan
o make checkPlan
o make genLVWS
.etplan file The ETPlanner tool uses the information in the .etCheckerInfo file and the
other optional files to generate the .etplan configuration file that describes the embedded
test specification for your chip. The detailed description of this plan is provided in
Generated .etplan File below.
<designName>.etplan.README file This file contains the complete syntax of the
.etplan file for quick reference.
Once your .etplan file is generated, you make minimum edits to the generated .etPlan file as
described in Editing the Embedded Test Plan.
Generated .etplan File
The .etplan file is divided into two sectionsa section in which you perform minor edits and a
specification section that you MUST not modify. Figure 5-3 illustrates the syntax of the .etplan
file the values that need to be edited are marked in red. Note that Figure 5-3 does not show
all properties available in the complete syntax for the .etplan file. For detailed description of all
June 2014
wrappers and properties available in this file, refer to Reference for Embedded Test Plan Syntax
in the manual ETPlanner: Reference or to the generated <designName>.etplan.README file.
Figure 5-3. Syntax for the .etplan File
ETPlan (<designName>) {
CADEnvironment {
GlobalDefinitionFile : <fileName>;
}
ICTechnology (<ICTechnologyName>) {
SimModelDir (<link>): <dirName>;
SimModelFile (<link>): <fileName>;// Repeatable
}
DesignSpecification {
RTLExtension : vb;
GateBistClockInFuncMode : Yes | (No);
SimModelFile (<link>): <fileName>;// Repeatable
PrelayoutSimModelFile : (<link>): <fileName>;// Repeatable
ModulesRTL (<designName>) {
SimModelDir (<link>): <dirName>;// Repeatable
}
ModulesGate (<designName>) {
SimModelDir (<link>): <dirName>;// Repeatable
}
EmbeddedTest {
GlobalOptions {
}
ModuleOptions (.*) {
LVWSDirectoryName : %_LVWS; // % is replaced by Module Name
MaxTestPointNumber : <int>;
}
MemBistControllerOptions (<memBistCTRLE>) {
}
MemBistStepOptions (<memBistCTRLE>:<StepRE>) {
RAMAlgorithm : <algoName>;
}
MemBistCollarOptions (<memBistCTLRE>:<CollarRE>) {
ROMContentFile : <fileName>;
}
Module (<ModuleRE>){
//Includes the MemoryBist wrapper specification. Must not be
edited.
}// End of Module
} // End of EmbeddedTest
}// End of ETPlan
The .etplan file is generated according to your chips embedded test requirements and the
default values found in the .ETDefaults File.
It is highly recommended you perform only minimal edits to this file. As a general rule, you
should specify the default values in the global definition files the .LVICTech File, the
.ETDefaults File, and the .LVICTech File and specify only the exceptions in the .etplan file.
June 2014
This will allow for a robust repeatable process of adjusting your embedded test plan, as you get
newer versions of the netlist. You should also make sure you provide accurate cluster
information for your memories either by defining them in the .etchecker file using the
lv.MemoryModule property or by supplying up-to-date DEF or PDEF files.
Memory BIST Partitioning
The memory BIST partitioning in the .etplan file is performed in the following way:
1. Memories are first separated in groups such that the physical region, clock domain, and
clusterID are identical for all memories in a common group. When a multi-port memory
is driven by multiple clock domains, the memory is associated to one of the clock
domains with the fastest frequency.
Note
You can manually assign a specific clusterID to a memory instance by specifying the
-clusterID option of the ETChecker property lv.MemoryInstance. You also can specify a
cluster size with the ETPlanner command-line option -clusterSizeRatio.
2. The memories are further separated into compatibility groups such that all memories in a
group can be tested in parallel in a single memory controller step. Memories of different
sizes are forced into separate groups if testing them in parallel takes longer than testing
them in series. This happens when one memory has many row addresses and few
column addresses, and the other one has many columns addresses and few row
addresses.
Additional rules for compatibility grouping are as follows:
All memories must use the same algorithm. For information about the Algorithm
property of the memory library file, refer to the Algorithm property in the
ETAssemble Tool Reference.
All memories must use the same operation set. For information about the
OperationSet property of the memory library file, refer to the OperationSet property
in the ETAssemble Tool Reference.
All memories must be of the same type of SRAM, ROM, or DRAM.
All DRAMs must have the same number of row, column, and bank address bits. For
information about the address register segment sizes, refer to the
LogicalAddressMap wrapper description in the ETAssemble Tool Reference manual.
The column segments for all memories must have the same low value for
CountRange. Likewise, the row segments for all memories must have the same low
value for CountRange. The high value may be different. For information about the
CountRange property, refer to the CountRange property in the ETAssemble Tool
Reference.
June 2014
All memories with more than one test port must have the same number of ports.
However, single-port memories can be placed with any multi-port memory. Single
test port memories have no restrictions.
The bit groupings of all memories must be either all even or all odd. However,
memories with a bit grouping of 1 are only compatible with memories having odd bit
groupings if all of the memories have a bit slice of 1. For a description of bit
grouping, refer to BitGrouping in the manual ETAssemble Tool Reference.
All memories must have identical PipelineSerialDataOut option settings. For a
chained-memory configuration, this only applies to the last memory in the chain.
Refer to the PipelineSerialDataOut property in the manual ETPlanner Tool
Reference.
All memories must have identical DataOutStage option settings. Refer to the
DataOutStage property in the manual ETAssemble Tool Reference.
3. The memory groups are further separated such that MaxPowerPerStep and
MaxMemoriesPerStep are not exceeded. The power calculation is based only on the
estimated memory power according to the specified MilliWattsPerMegaHertz property
in the .memLib file multiplied by the frequency of the clock domain. It does not include
the power consumed by the controller itself or the rest of the surrounding functional
logic. The latter can be significant for a large clock domain, and it might be necessary to
disable the functional logic during memory BIST.
4. The resulting memory groups are then assigned to controller steps such that the
constraints, specified by the MaxTestTimePerController and MaxStepsPerController
properties, are not exceeded. Memories that are not part of the same physical region, are
not on the same clock domain, or do not share a common clusterID will never be tested
by the same controller. Likewise, non-identical DRAMs will never be tested by the same
controller.
Example .etplan File
Figure 5-4 illustrates an example of the.etplan file created for module TOP with user edits
shown in red.
June 2014
Figure 5-4. Example Top.etplan File
//-----------------------------------------------------------
// This file created by: etplanner
// Software version: 5.0Prod Build 20050309.001
// Created on: 03/10/05 14:14:12
//-----------------------------------------------------------
ETPlan (Top) {
CADEnvironment{
GlobalDefinitionFile: /home/golden/Centralities/HWLib.CADEnv;
}
ICTechnology (tgc4000) {
GlobalDefinitionFile:
/home/golden/CentralFiles/tgc4000.LVICTech;
SimModelDir (mems): ../../MemModels;
}
RTLExtension: vb;
GateExtension: v;
ModulesRTL (TOP) {
SimModelDir (RTL): ../TOP_DESIGN/RTL;
}
ModulesGate (TOP) {
SimModelDir (Gate): ../TOP_DESIGN/GATE;
}
}
EmbeddedTest {
GlobalOptions {
}
ModulesOptions (.*){
LVWSDirectoryName: %_LVWS; // % is replaced by Module Name
}
MemBistControllerOptions (.*) {
}
MemBistStepOptions (.*:.*) {
RAMAlgorithm: SMARCHCHKBCIL;
}
MemBistCollarOptions (.*:.*) {
}
MemBistCollarOptions (TOP_CK1_MBIST3:C2) {
ROMContentFile: ../TOP_DESIGN/MEM/ROM_1R_64X8.data;
}
// ------ Auto Generated Embedded Test Specifications --------------------
// Do not modify
Module (TOP){
MemoryBist (TOP_CK1_MBIST1){
ClockDomainLabel: CK1; // 200.0 MHz
Step (0){// 6 mW, 4 us
MemoryCollar (C1): TLB2/MEM; // SYNC_1RW_16x8
}
}
MemoryBist (TOP_CK1_MBIST2) {
Step(0){// 24 mW, 8 us
MemoryCollar (C1): TLB1/MEM; // SYNC_1RW_16x8
MemoryCollar (C2): TLB1/CORE2/MEM; // SYNC_2R1W_16x8
MemoryCollar (C3): TLB1/BLOCK1/MEM; // SYNC_1RW_16x8
June 2014
}
}
Step (0) {// 12 mW, 8 us
MemoryCollar (C1): TLB1/BLOCK1/CORE1_I2/MEM;
// SYNC_2R1W_16x8
}
Step (1) { // 20 mW, 1 us
MemoryCollar (C2):
TLB1/BLOCK1/CORE1_I2/CORE1_CLK2/ROM;
// ROM_1R_64X8
}
}
Step (0) { // 12 mW, 8 us
MemoryCollar (TOP_CK1_MBIST3.C1):
TLB1/BLOCK1/CORE1_I1/MEM;
// SYNC_2R1W_16x8, Repeated parent Module CORE1
}
Step(1) {// 20 mW, 1 us
MemoryCollar (TOP_CK1_MBIST3.C2):
TLB1/BLOCK1/CORE1_I1/CORE1_CLK2/ROM;
// ROM_1R_64X8, Repeated parent Module CORE1_CLK2
}
}
} // End of Module
} // End of EmbeddedTest
}// End of ETPlan
Editing the Embedded Test Plan
The ETPlanner tool uses the information in the .etCheckerInfo and the other optional files to
generate the .etplan configuration file that describes the embedded test requirement for your
chip. You have to do minimum edits to this file.
The .etplan file is structured to separate the information which is user-editable and the reference
section which must never be modified.
After the .etplan file is generated, you need to open this file and specify values for the following
properties. These properties are marked in red in Figure 5-3.
The SimModelDir property in the wrapper ICTechnology to locate your memory
simulation model. The simulation models are rarely stored in a central location as they
are created per design using the memory compiler.
The SimModelDir / SimModelFile property in the wrapper ModulesGate and/or
ModulesRTL to specify the directories and file locations of your RLT and gate-level
circuit representation.
June 2014
The SimModelFile and PrelayoutSimModelFile properties in the DesignSpecification
wrapper will only be present if you are using the Bottom-Up Methodology and your
current physical region includes child physical regions.
If you have a ROM memory in your design, you have to define the ROMContentFile
property inside the MemBistCollarOptions wrapperto point to ROMContents file of
your ROMs.
After you are done with your edits to the .etplan file, you can proceed to verifying your
embedded test plan and inspect any violations that might be reported in the ETSummary file as
described in Validating the Embedded Test Plan.
Changing the Fault Simulation Engine
In the LV Flow, currently, there are two fault simulators signatureAnalyze and FastScan.
Using Tessent FastScan as the fault simulation engine removes many restrictions that are
present with signatureAnalyze. For example, Tessent FastScan supports N-Capture mode, and
runtime can be reduced without affecting fault coverage or pattern count by using distributed
ATPG.
You can change your fault simulation engine from default FastScan to signatureAnalyze using
the properties in the ETPlanner input files, LogicTestFaultSimulator and
TestKompressPresent, that allow you to specify the fault simulator to use and whether an EDT
controller will be inserted. Figure 5-5 shows the syntax for the these properties (in red) in the
.ETDefaults and .etplan files.
Figure 5-5. Specifying the Fault Simulator in ETPlanner Input Files
.ETDefaults file:
EmbeddedTestDefaults {
LogicTest {
LogicTestFaultSimulator: Signaturea | (FastScan);
TestKompressPresent: Yes | (No);
LogicBistPresent : (Yes) | No;
AtpgCompression : (Yes) | No;
ThirdPartyAtpg : None | FastScan | TestKompress;
}
AtpgRulesOnlyLogicTest {
TestKompressPresent : Yes | (No);
ThirdPartyAtpg : (FastScan) | TestKompress;
}
}
.etplan file:
ETPlan (xxx) {
EmbeddedTest {
ModuleOptions (.*) {
June 2014
LogicTestFaultSimulator: Signaturea | (FastScan);
TestKompressPresent: Yes | (No);
LogicBistPresent: (Yes) | No;
ThirdPartyAtpg: None | FastScan | TestKompress;
}
}
}
You use the LogicTestFaultSimulator property to specify whether Tessent FastScan or
signatureAnalyze will be used as the fault simulation engine. This property defaults to
SignatureA.
You use the TestKompressPresent property to specify whether an Embedded
Deterministic Test (EDT) controller will be inserted. This property defaults to No.
TestKompressPresent and ThirdPartyAtpg cannot be specified at the same time.
Setting TestKompressPresent to Yes is equivalent to specifying ThirdPartyAtpg to
TestKompress.
The default value of the ThirdPartyATPG property depends on the
LogicTestFaultSimulator property:
o If LogicTestFaultSimulator is set to Signaturea ThirdPartyAtpg defaults to None.
o If LogicTestFaultSimulator is set to FastScan then ThirdPartyAtpg defaults to
FastScan
Using Regular Expression Syntax in .etplan File
ETPlanner provides a powerful feature based on the UNIX Regular Expression syntax to
specify exceptions to the global defaults in the .etplan file. Using the Regular Expression
syntax, you can modify the global embedded test defaults for one or more modules, memory
BIST controllers, memory BIST controller steps, and memory BIST collars. The following
wrappers inside the EmbeddedTest wrapper of the .etplan file support Regular Expression
syntax:
ModuleOptions
MemBistControllerOptions
MemBistStepOptions
MemoryCollar
The reference section of the .etplan file allows you to identify the modules and memory BIST
options in your design. Using this reference information, you can construct regular expressions.
You can also use the ETPlanner runtime option -echoMatch On to verify that the regular
expression does match the wrappers you intended. The following are examples of regular
expression specification:
June 2014
The following example specifies that all memory BIST controllers belonging to the
clock domain CLK3 have the compstat diagnostics. The list of all memory BIST
controller module names can be obtained from the reference section of the .etplan file.
MemBistControllerOptions (.*_CLK3_.*) {
CompStat: On;
}
The example illustrated in Figure 5-6 specifies that the memory BIST steps 0, 1, 2, and 3
that belong to the memory BIST controllers on the clock domain CLK2 use the memory
BIST algorithm SMARCHCHKBcil. Note that since the memory BIST test steps are
defined under the memory BIST controller wrappers, you need to use the : colon
character to delimit the wrapper and the sub-wrapper.
Figure 5-6. Example on Using Regular Expressions in .etplan
The following example specifies that memory BIST collar C6 that belongs to the
memory BIST controller TOP_CLK1_MBIST1 should use the specified ROM Content
file. A : (colon character) is specified as a delimiter between the memory BIST
controller name and the collar identifier.
MemBistCollarOptions (TOP_CLK1_MBIST1:C6) {
ROMContentFile:../MEM/ROM_1R_64X8.data;
}
For detailed information on constructing regular expressions, refer to Constructing a Regular
Expression in the manual ETPlanner: Reference.
Validating the Embedded Test Plan
June 2014
To generate a new .etplan file and generate the .ETSummary file, you run the make target
checkPlan.
files for reviewing the embedded test plan of your design.
Figure 5-7. Validating the Embedded Test Plan
.ETSummary File
During this sub-step, ETPlanner generates the .ETSummary file a report that summarizes the
logic and memory test inside each of your physical regions including the computed test time and
power estimates. The .ETSummary file also contains violation warnings if the target maximum
test time or power limits are exceeded, or if the memory partitioning violates the floor planning.
Figure 5-8 illustrates the example of the .ETSummary file. The explanations of the report fields
follow the figure.
.etSummary
make <module>.checkPlan
.etpPhysicalInfo *
.etcheckerInfo
Output Files from
.memLib**
.ETDefaults
.LVICTech
.CADSetup
Optional Files
DEF or PDEF
Step1: ETChecker
.etplan.README
MakeFile
Edited
.etplan
June 2014
Figure 5-8. Example .ETSummary File
Module CTLType CTLName TestTime Power Warnings
-----------------------------------------------------------------------------
A LBIST (1 chains of 143 FFs) 503 us
B LBIST (2 chains of 143 FFs) 503 us
MBIST B_CK33_MBIST1 7 ms TTime1
Step: 0 107 us 50 mW
Step: 1 7 ms 83 mW Power1
C LBIST (1 chains of 143 FFs) 503 us
MBIST C_CK100_MBIST1 56 us FPlan1
Step: 0 38 us 60 mW
Step: 1 19 us 60 mW
MBIST C_CK100_MBIST 35 us
Step: 0 120 mW Power2
TestTime Warnings
-----------------------------------------------------------------------------
TTime1 :The B_CK33_MBIST1 memBist controller TestTime is larger than
the specified MaxTestTimePerController value of 100 us.
Regenerate the plan to split the multi-step controller into separate
single step controllers.
Power Warnings
------------------------------------------------------------------------------
Power1 :The B_CK33_MBIST1 memBist controller Step 1 Power is larger
than the specified MaxPowerPerStep value of 60 mW.
Power2 :The C_CK100_MBIST2 memBist controller Step 0 Power is larger than
the specified MaxPowerPerStep value of 60 mW.
Floor Plan Warnings
-----------------------------------------------------------------------------
FPlan1 :The C_CK1_MBIST1 memBist controller tests memories from those
different clusters:
-
CORE_I2
CORE_I1
The .ETSummary file comprises the following information in these columns:
ModuleName the name of modules in your design associated to physical regions.
Those are the root module and the sub-modules you declared as lv.ELTCoreModule or
lv.BlockModule in the .etchecker file.
CTRLType the controller typeLBIST or MBIST.
CTRLName the name of the memory BIST or logic BIST controller.
TestTime test time to run the given embedded test controller.
For logic BIST, this is computed as follows:
LogicBISTVectors * (ChainLength+24)/ShiftClockFrequency.
For memory BIST, this depends on the chosen algorithm and size of the memory.
PeakPower power consumption for memories tested only in parallel. This is
computed based on the MilliWattsPerMegaHertz specification for the memories and the
test clock frequency.
June 2014
Warningan indication of a violation in your embedded test plan. The explanation of
each warning is placed at the bottom of the summary. The warnings types are as follow:
o Power Warning (Power <n>)
o Test Time Warning (TTime <n>)
o Floor Plan Warning (FPlan <n>)
Fixing Violations
After reviewing the .ETSummary file you can fix the violations that are encountered during ET
Plan generation for your design.
After reviewing the .ETSummary file, you can choose to fix the violations that were detected or
to waive them. If you get a violation when running make checkPlan right after having run make
genPlan, typically, you have to change default limits in the .ETDefaults File. If, on the other
hand, you get violation when running make checkPlan after having received an updated
.etCheckerInfo file, then re-running make genPlan will typically fix them.
The following sections will explain how to deal with power, test time, and floor plan warnings.
Power Warnings
Power Warnings are generated if the computed peak power consumptions of a memory BIST
test step exceeds the value of the MaxPowerPerStep property specified in the .ETDefaults file.
To fix these warnings, perform one or several of the following steps:
Verify that the MaxPowerPerStep constraint and the MilliWattsPerMegaHertz value
specification in the memory library files are valid for the memories you are using in the
design. Once a controller step is only testing one memory, the only thing that can be
done to reduce the power of the given step, is to slow down the test frequency. However,
this typically points to a bad constraint as the memory would also exceed power limits
during the functional mode.
If you get the violation after receiving an updated .etCheckerInfo file, re-run the make
genPlan target, and ETPlanner will automatically repartition the memories to comply
with the specified constraints.
Test Time Warnings
Test Time Warnings are generated if the computed test time of a memory BIST test step exceeds
the value of the MaxTestTimePerController property, or if the computed test time of a logic
BIST controller exceeds the value of the MaxLogicBistTestTime property specified in the
.ETDefaults (or .etplan) file.
June 2014
Memory BIST Warnings
To fix the warnings associated with the memory BIST controller, perform one of the following
steps:
For memory BIST, if the controller that causes the violation only has one step, reduce
the bit slice size to decrease test time. However, if the bit slice width is already set to
minimum of 1 then the only alternative is to select a less complex algorithm or change
the test time constraint. The other parameters affecting the test time are memory size and
test clock frequency.
If you received an .etCheckerInfo file, and you now get test time violation for multi-step
controller, re-run make genPlan, and ETPlanner will automatically partition the
controller steps into different controllers to comply with the specified constraints.
Logic BIST Warnings
To fix the warnings associated with the logic BIST controller, you can adjust the value of the
following properties in the .ETDefaults File:
ShiftClockFrequency a higher available shift clock will reduce the test time. Do not
increase this value much higher than 100MHz. Otherwise, you will have timing closure
difficulties and consume too much power during the logic BIST test. Note that the flop
toggle rate is 50% during logic BIST. Your power rails need to be able to tolerate a
toggle rate of 50% * ShiftClockFrequency.
MaxScanSegmentNumber a higher number will reduce the number of scan shift
cycles and, hence, the test time. Note that a number larger than 250 might result in
routing congestion around the logicBIST controller. Make sure the logicBIST controller
can be placed in a central location.
LogicBistVectorNumber a lower number will reduce test time. Note that this can
significantly affect the number of testpoints required to achieve a high fault coverage.
Unless your circuit is highly random-pattern testable, it is not recommended to lower
LogicBistVectorNumber below 100k.
Floor Plan Warnings
Floor Plan Warning are generated if memories belonging to different clusters are tested by a
common memory BIST controller. This can only happen if you get an updated .physicalInfo file
or updated DEF/PDEF files. You simply re-run make genPlan, and ETPlanner will
automatically partition the memories to comply with the current clustering information.
June 2014
Verifying the Regular Expression Specification
When running make checkPlan, you can verify that the regular expression you have used
actually matched what you intended by using the runtime option -echoMatch On as shown
below:
make checkPlan cmdOptions= -echoMatch On
This causes ETPlanner to generate verbose output as shown in the following example of
ETPlanner output:
ModuleOptions(.*) matched Module 'car'.
Updating LVWSDirectoryName to car_LVWS
Updating LogicBistVectorNumber to 900
ModuleOptions(.*) matched Module 'dashboard'.
Updating LVWSDirectoryName to dashboard_LVWS
Updating LogicBistVectorNumber to 900
MemBistStepOptions(.*_CK33_.*:[0:1])
matched MemoryBist:Step 'dashboard_CK33_MBIST1:0'.
Updating RAMAlgorithm to 'SMARCHCHKB'
Updating LocalComparators to OFF
Generating the LV Flow Environment
June 2014
Now you are ready to generate the LV Flow environment in which you will run the remaining
steps of the LV Flow ETAssemble, ETScan, ETSignOff.
files for generating the complete LV Flow environment that you will use to implement your
embedded test for your design.
Figure 5-9. Generating the LV Flow Environment
make <module>.genLVWS
.etpPhysicalInfo *
.etcheckerInfo
Output Files from
.memLib**
.ETDefaults
.LVICTech
.CADSetup
Optional Files
DEF or PDEF
Step1: ETChecker
Validated
.etplan
lvWorkSpaces
LV Flow Environment
.etSummary
.fastscan_load
_design
Managing Updates of the RTL- or Gate-Level Netlist
June 2014
Input Files to ETPlanner
The same files that served as input to ETPlanner for the make checkPlan target are reused to
generate the LV Flow Environment:
.etplan file created by ETPlanner and edited and verified in the previous steps
.etCheckerinfo file generated by ETChecker
Running ETPlanner to Generate the LV Flow
Environment
To generate the LV Flow environment, you run the make genLVWS target.
Output from ETPlanner
The ETPlanner tool creates the LV Flow environment that comprises a collection of files and
directories.
When running the make genLVWS target, the following files are generated:
An up-to-date .ETSummary file.
A dofile in the ETScan and ETSignOff directories,
<designName>.fastscan_load_design. This file is used by the dofiles to load the design
into Tessent Shell.
The content and usage of the LV Flow environment is described in detail in Understanding the
LV Flow Environment of the next chapter.
Managing Updates of the RTL- or Gate-Level
Netlist
At first, you will generate your .etplan file using an .etCheckerInfo file and optional files
.etcPhysicalInfo and DEF/PDEFwhich were generated from a version of the RTL- or gate-
level netlist that was not the final version of your chip.
When a newer version of the RTL or netlist is available, you need to make sure to re-run
ETChecker on it to obtain up-to-date version of .etCheckerInfo and .etcPhysicalInfo files which
match your most recent RTL- or gate-level netlist. If you did use DEF/PDEF files to drive the
memory BIST partitioning, make sure you have up-to-date version of DEF/PDEF files as well.
With the up-to-date input files, start by running the make checkPlan target to see whether or not
the plan needs to be regenerated.
Managing Updates of the RTL- or Gate-Level Netlist
June 2014
If memory instances were removed or added to your design, you will get errors/warnings that
will need to be corrected by re-running the make genPlan target.
If the new input file generates new violations in the .ETSummary file, you need to re-run make
genPlan to correct them.
When rerunning make genPlan, the updated .etplan file will automatically be patched with the
previous edits you had done in the previous version of the .etplan file.
Whether or not you needed to rerun make genPlan, you must always rerun make genLVWS or
run make updateETCheckerInfo whenever you receive an updated .etCheckerInfo file.
Rerunning one of these targets will not destroy anything you have previously done inside the ET
Environment but will ensure you have up-to-date information files inside the lvWorkSpaces.
Detailed information, such as the inter-domain communication around blocks and ELT cores, is
stored in the lvWorkSpaces. It is very important that they are up-to-date and consistent with
your current version of your RTL- or gate-level netlist.
Run make updateETCheckerInfo if no changes have been made to the .etplan file, and you just
want ETPlanner to regenerate some information files inside the lvWorkSpaces, such as the
.rulea override file and ETAssemble input files.
Run make genLVWS if you have made changes to the .etplan file or specified new memory
library files on the command line. Running this target will result in ETPlanner regenerating soft
links, backing up and creating new files in the lvWorkSpaces, such as Makefiles, README
files, scripts, and so on.
June 2014
Chapter 6
Inserting and Verifying Embedded Test
This chapter explains how to create and verify Mentor Graphics embedded test for your design
using steps of the LV Flow. Using the LV Flow environment created by ETPlanner in Step 2:
ETPlanner, you transform your design netlist to include Mentor Graphics embedded test
structures.
The chapter topics follow this sequence:
Understanding the LV Flow Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Makefile and Make Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
lvWorkSpace Linking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Chip Example to Illustrate the Steps of the Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Step 3: ETAssemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Generating and Inserting the Embedded Test Structures . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Performing Verification in ETAssemble Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Step 4: ETScan and Pre-Layout ETSignOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Make Targets for ETScan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Make Targets for Pre-Layout ETSignOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Using Tessent FastScan as LogicBIST Fault Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Step 5: Final ETSignOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Additional Make Targets for Final ETSignOff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Constraining ET Logic for Synthesis and Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Performing Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Managing the ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Selecting the Implementation Style of Testpoints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Preventing Corruption of the Logic Test Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Controlling ETSignOff Test Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Archiving Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Understanding the LV Flow Environment
June 2014
In Step 2: ETPlanner, the ETPlanner tool creates a complete environment for the insertion of
embedded test into your design that includes the following:
Directories for running the steps of the LV Flow,
Makefile and Make Targets that are used for execution of Mentor Graphics tools,
README file that explains what targets to accomplish the desired operation,
Necessary configuration files.
Each step of the LV Flow requires the execution of one or more LV Flow tools. You can use a
set of targets to execute a sub-step, a set of sub-steps, or an entire step of the LV Flow. The steps
of the LV Flow run the LV Flow tools to transform your netlist into a netlist containing
embedded test design objects.
Directories
Figure 6-1 on page 119 groups the directories that ETPlanner outputs according to their role in
the design flow. The ETPlanner tool generates these directories based on your specifications in
the .etplan configuration file. Figure 6-1 considers all embedded test design objects.
Note that all directory and file names in Figure 6-1 are literal except for the <ICTech Name>
directory. You specify this directory name using the ICTechnology wrapper of the .etplan input
configuration file.
The directory structure consists of the following:
<ICTech Name> Directory that includes IC Technology pointers.
lvWorkspaces for each physical region in your design which include the ET
Environment Directory and File Structure and Step Directories of the LV Flow.
The directories modulesRTL, modulesGate, modulesLV, and <IC Tech Name> do not
have Makefiles that are used to execute the steps of the LV Flow. They only contain
softlinks to your RTL and gate-level netlist files, and softlinks to your library models.
June 2014
Figure 6-1. ET Environment Directory and File Structure
<ICTech Name> Directory
As Figure 6-1 illustrates, ETPlanner creates the <ICTechName> directory to contain links to the
directories where all Verilog IC technology cell models are described. Mentor Graphics scan
models for some of the cell mainly, all sequential cells, such as flip-flops and latches and
complex cells or macros that are modeled as user-defined primitivesare also linked in this
directory. Note that the <ICTechName> directory is created only once for all WorkSpaces.
Design Environment Directories
As Figure 6-1 illustrates, ETPlanner creates the following directories related to your design
environment based on your input to the .etplan configuration file.
Note that ETPlanner also generates outDir and LV_WORKDIR subdirectories in many of the
directories described in this section in order to hold the output files and other intermediate files
created by running the automation tools.
modulesLV Directory
ETPlanner creates the modulesLV directory to provide local copies of Mentor Graphics
TestPoint and Priority Data Scan flip-flops. These flip-flops are generated using the Mentor
WorkSpace per each physical region
LV Flow Environment
README
MakeFile
<ICTech Name> directory
Design Environment
modulesLV directory
modulesRTL directory
modulesGates directory
LV Flow
File
/ETAssemble directory
Directories
/ETScan directory *
/ETSignOff directory
(including configuration files)
* Not present if Logic test is not used.
Directories
June 2014
Graphics scanMake tool when creating scan libraries for specific IC technology. Local copies
are created to uniquify their module names so as not to have module name conflicts between
physical regions.
modulesRTL Directory
ETPlanner creates the modulesRTL directory to provide links to all directories and files that
comprise the complete RTL description of your chip. The directory is organized into links to
directories and files.
modulesGate Directory
ETPlanner creates the modulesGate directory in each lvWorkSpace to provide links to all
directories that comprise the complete gate-level description of the corresponding physical
region. If the ETEnvironment is created before the gate-level netlist files exist, it will still
provides links to the directories where the netlist files will eventually be stored.
Step Directories of the LV Flow
As Figure 6-1 illustrates, ETPlanner generates the following directories related to the steps of
the LV Flow in the WorkSpace associated with each of your physical regions.
ETAssemble Directory
ETPlanner creates the ETAssemble directory where you run ETAssemble to generate and insert
all embedded test hardware into your physical region.
If you run ETChecker with lv.EmbeddedTest -logic set to On, you perform Early Verification in
this directory by running designExtract and ETVerify to generate simulation test benches. The
Early Verification allows you to verify all embedded test modes, except for ATPG and
logicBIST which requires the scan-inserted netlist to work.
If you run ETChecker with lv.EmbeddedTest -logic set to Off, you perform Pre-Layout
ETSignOff in this directory:
The Pre-Layout ETSignOff is done on the RLT view if you use
EmbeddedTestMergeFlow RLT in the .etplan file.
The Pre-Layout ETSignOff is done on the gate-level netlist if you use
EmbeddedTestMergeFlow Gate in the .etplan file.
ETScan Directory
The ETScan directory is generated when you run the Analyze tools to insert the scan chains and
testpoints into your design. The presence of the ETScan directory is only present if you run
ETChecker with lv.EmbeddedTest -logic set to On.
June 2014
You also perform the Pre-Layout ETSignOff in this directory. The Pre-Layout ETSignOff step
involves the following sub-steps:
Create a concatenated pre-layout netlist for your physical region.
Create a minimal set of test vectors to verify logic test operation.
Create a pre-layout LVDB (Mentor Graphics database) that allows you to perform the
Post-Layout ETSignOff in the ETSignOff directory.
Create timing analysis scripts and perform timing analysis of the embedded test design
objects for the physical region using pre-layout timing information.
Create test benches and perform ETSignOff simulations of all the embedded test objects
in your physical region using worst case pre layout timing information.
ETSignOff Directory
ETPlanner creates the ETSignOff directory to enable you to verify and sign off the embedded
test structures in the final post layout view of your physical region. From this directory, you run
Mentor Graphics tools and use the ETPlanner-created make targets to perform these steps:
Create the final and complete set of test vectors for logic test.
Create the final post layout LVDB for the physical region.
Generate test patterns for all the embedded test objects in your chip in the selected
format of WGL or STIL.
Create final post-layout timing analysis scripts and perform timing analysis of all
embedded test mode in your physical region.
Create test benches and perform sign-off simulations of all the embedded test objects in
your physical region using worst case post-layout timing data.
Makefile and Make Targets
ETPlanner creates makefiles that include all necessary make targets to run all sub-steps of the
remaining steps of the LV Flow. Each step of the flow requires the execution of one or more
Mentor Graphics tools. Make targets are available to execute one sub-step, a series of sub-steps,
or an entire step.
Generally, you use the targets defined in the generated LV Flow environment as follows:
1. Go into the appropriate directory for the given step of the LV Flow.
2. View available targets within a generated directory by typing make with no arguments.
A list of available targets, each with a brief description, will appear on the screen.
June 2014
3. To run a sub-step or set of sub-steps, type make <targetName>, where targetName is a
target name displayed when you typed make with no argument.
The make all target is always available to allow you to run the entire step with a single
command.
4. You can pass extra options to the tool invoked by a given target by using the following
syntax:
make <targetName> cmdOptions=-<optionName> value
This is particularly useful when you want to simulate a single test bench.
make sim cmdOptions=-list
will list the available patterns and
make sim cmdOptions=-select <pattern>
will simulate these patterns.
Editing Make Targets
You should never edit the Makefiles. All command line options have been automatically set
correctly from the analysis of your design by ETChecker and the options you have selected in
the .etplan configuration file. If you need to change anything, you are required to go back to the
ETChecker and/or the ETPlanner steps to change choices you made there.
Using the LVWSTargets_preCmd and LVWSTargets_postCmd
Variables
The Makefile targets generated by ETPlanner are able to execute a command before (preCmd)
and/or after (postCmd) a target has completed. For example, the designe target will look
something like this:
designe:
$(preCmd)
designe...
$(postCmd)
By default, preCmd/postCmd scripts located in <Tessent SoCRelease>/lib/tools/etplanner will
be executed when a target is run, and they will attempt to execute, if they exist, the user-created
shell scripts <target>.PRECMD and <target>.POSTCMD, respectively. For example, to run a
script before the target just create the file designe.PRECMD that contains the commands you
wish to run.
If you do not want to use the default preCmd/postCmd scripts provided in the Mentor Graphics
release, you can create your own scripts and point to them using the
LVWSTargets_preCmd/LVWSTargets_postCmd environment variables. To use the
LVWSTargets_preCmd/LVWSTargets_postCmd variables, follow these steps:
June 2014
1. Create a shell script that will perform the command(s) you want run when the target is
called. You can use the same script for both preCmd and postCmd or create one for each.
2. Set the LVWSTargets_preCmd and/or LVWSTargets_postCmd environment variable(s)
that will invoke your script, for example:
setenv LVWSTarget_preCmd '/home/foo/PRECMD.cshrc $@'
3. Now when a target is invoked, your preCmd/postCmd scripts will be run.
Note
When your script is executed, the Makefile variable $@ will be passed as an argument so
your script will know the name of the target the preCmd/postCmd was called from.
lvWorkSpace Linking
Depending on the methodology usedTop-Down Methodology or Bottom-Up Methodology,
the information transfer from one child physical region to its parent is changed as described in
the following sub-sections.
Information Transfer in Top-Down Methodology
In the Top-Down Methodology, you invoke the make embedded_test target inside the parent
physical region lvWorkSpace as soon as make embedded_test has been run for each child
physical regions. As illustrated in Figure 6-2, you can see that the ETAssemble directory of the
parent physical region has links directly into the child ETAssemble directory. The ETScan
directory of the parent physical region can be started as soon as the child lvdb_prelayout
directories are created. Finally, the Post-Layout SignOff of the parent physical region is done
once the post-layout LVDB of the children are generated.
June 2014
Figure 6-2. Information Transfer Between lvWorkSpaces in Top-Down
Methodology
Information Transfer in Bottom-Up Methodology
Figure 6-3 illustrates the transfer of information when the Bottom-Up Methodology is used.
Unlike with the top-down methodology, make embedded_test inside the parent physical region
can only be performed when at least the pre-layout LVDBs of all child physical regions are
ready. The preLayout LVDB pointer is optional and only exists if you specified the
-preLayoutLVDBDir during the GenPlan run. If your child physical region is already laid out
and signed off, then you only need to point to the signed-off LVDB directory. Both Pre-Layout
and Post-Layout SignOff of the parent physical region will be done using the final LVDB of the
child. Never point to a pre-layout LVDB with the -lvdbDir option as it would be treated as a
final LVDB, and the parent Post-Layout SignOff would be done using the child pre-layout
LVDBs. Effects of scan chain reordering would not be taken into account in the parent logic test
vector generation, and simulation miscompares would be obtained.
Chip Example to Illustrate the Steps of the Flow
June 2014
Figure 6-3. Information Transfer Between lvWorkSpaces in Bottom-up
Methodology
Chip Example to Illustrate the Steps of the
Flow
To illustrate the steps of the LV Flow, the chip example, shown in Figure 6-4 on page 126, will
be used throughout this document.
The example chip contains the following elements:
Three layout regions Top, Block, and Core.
Memories are scattered throughout the design.
A PLL in Top provides synchronous clocks in all three layout regions.
Chip Example to Illustrate the Steps of the Flow
June 2014
Note
Note that if you are using logic test and you have a PLL, you must make sure it can use a
local feedback during test mode. Many PLLs are using a leaf of the clock tree as a
feedback. Because logic test gates the clock source during the shiftPhase, the feedback is
not kept in sync with the reference and, thus, make the PLL get out of lock. For a detailed
description on how you can provide a local feedback during logic test without affecting
the functional mode, refer to Re-Using PLL and Functional Clock Dividers During
Embedded Test.
The Core module uses the clocks generated by the PLL in Top but it also contains an
additional clock. Within the core region, a local clock divider is present that divides the
clock by 2.
Note that the example only shows the physical layout regions. The modules shown in the
example can still be declared within other modules, such as TopLogicBlock. With Tessent SoC,
the TopLogicBlock boundaries are no more relevant. Only the physical block boundaries are
relevant and you are advised to match the embedded test partitioning to your physical region
partitioning by declaring your lower-level layout regions as lv.ELTCoreModule or
lv.BlockModule during the ETChecker step. Failing to do so will greatly complicate the flow
and make the physical flow much more difficult.
Figure 6-4. Merge Flow Example Chip
Step 3: ETAssemble
June 2014
Step 3: ETAssemble
In this step, you perform the following sub-steps:
Generate and assemble the embedded test structures:
a. On a layout region declared as an lv.ELTCoreModule:
i. Generate and insert all the embedded test controllers including the WTAP, the
memory BIST controllers, the logicTest controller with its associated clock
controllers, Dedicated Isolation cells, and auto scan violation and testability
correction cells.
ii. Create all external scan ports on the layout region boundary.
b. On a layout region declared as an lv.BlockModule:
i. Generate and insert all the embedded test controllers including the WTAP, the
memory BIST controllers, the auto scan violation and testability correction cells,
and clock multiplexers for locally generated clocks.
ii. Create all scan ports on the layout region boundary.
c. On the chip layout region:
i. Generate and insert all the embedded test controllers including the TAP and
boundary scan, the memory BIST controllers, the logicTest controller with its
associated clock controllers, and auto scan violation and testability correction
cells.
You use the ETAssemble input file.etassemblethat has been auto-generated by
ETPlanner. You only edit this file if you require some special customization, such as the
specification of CustomObject wrappers.
Detailed instructions for this sub-step is provided in Generating and Inserting the
Embedded Test Structures.
Perform early verification of the inserted embedded test structures in your design.
If you ran ETChecker with lv.EmbeddedTest -logic Off, the verification performed
inside the ETAssemble directory is the Pre-Layout SignOff either on the RTL view or on
gate-level netlist of your chip depending on how the EmbeddedTestMergeFlow
property of the .etplan file was specifiedRLT or Gate.
Detailed instructions for this sub-step is provided in Performing Verification in
ETAssemble Directory.
Step 3: ETAssemble
June 2014
Generating and Inserting the Embedded Test
Structures
This sub-step is performed using the make embedded_test target in each ETAssemble Directory
associated to each layout block. The results of the ETAssemble run on the example chip are
illustrated in Figure 6-5. All embedded test structures are created and merged into the blocks,
cores, and top. The external scan ports are created on the blocks and cores even if the scan
chains and testpoints are not yet present, freezing the foot print of the blocks and cores at the
RTL level.
You need to have run the make embedded_test target on all child (or lower-level) physical
regions before you can run make embedded_test on a parent physical region. The
make embedded_test targets run very quickly on the child regions so you can easily get a fully
embedded test inserted view of your entire chip in a matter of a few hours.
If you are using the RTL value in the EmbeddedTestMergeFlow property of the .etplan file, and
your RTL contains unsupported constructs, you can surround it with LV_pragma statements as
described in LV_Pragma for Unsupported Verilog Constructs of the manual ETAnalysis Tools
Reference.
Figure 6-5. Results After Running ETAssemble on Your ChipETAssemble
Step 3: ETAssemble
June 2014
If you want to insert the shared Tessent EDT/LogicBIST hardware (Classic IP, Hybrid/Merged
IP, or Low-Power Shift), you need to run some additional make targets such as
make gen_EDTController. This scenario is not demonstrated in the example used in this
chapter. For detailed information on how to enable Tessent Shared EDT/LogicBIST hardware
and benefits of it, refer to Shared EDT and LogicBIST Hardware in the manual ETHardware
Reference.
Performing Verification in ETAssemble Directory
This sub-step involves generating test benches for verification and performing simulation. It is
recommended that you perform the make designe target right away. Once designExtract
verified your design and reported no errors, the likelihood that you find something incorrect
with the rest of the verification is very low.
The test benches generated by ETVerify at this stage verify all types and instances of embedded
test controllers in the given physical region. If logic test is used, and, because the scan chains
are not yet inserted, only a simple setup register flush test is performed for the logicTest
controller.
The ETVerify tool creates test benches for verifying the following:
IEEE 1149.1 test access port (TAP) and boundary scan
WTAP distributed test access controller
Memory BIST with reduced address space
Logic test setup chain flush test
For details on the tools run in this step, refer to these reference manuals:
ETAnalysis Tools Reference (for designExtract)
ETVerify Tool Reference
A .sta file is created by ETAssemble for reuse within your functional Static Timing Analysis
(STA) run. This constraints file will disable the logic test hardware (when present) and properly
constrain the TAP, boundary scan, and memory BIST controllers as part of your functional STA
run. For more details, refer to Constraining ET Logic for Synthesis and Layout.
Make Targets for Verification
You run the following make targets in Step 3: ETAssemble of the LV Flow to perform either
early verification or pre-layout sign-off of the inserted embedded structures within your
physical regions.
Step 3: ETAssemble
June 2014
Note
You choose to run some make target described below according to the specification of the
ETChecker lv.Embedded Test property.
These make targets are run in the ETAssemble Directory:
make designe
This make target runs the designExtract tool on your physical region to verify the proper
connections of all embedded test controllers and extract the connection information for
ETVerify to generate the appropriate test benches. You must have run designExtract on
all child physical regions before you can run designExtract on a parent physical region.
Only when lv.EmbeddedTest -logic On
make config_etEarlyVer
This make target runs ETVerify to create the .etEarlyVer configuration file for the case
where an lv.EmbeddedTest -logic On was used.
The make all target normally does not rerun this target once the .etEarlyVer file exists.
You must manually rerun it if your layout regions were modified, and embedded test
structures were added or removed.
Only when lv.EmbeddedTest -logic Off
make config_etSignoff
This make target runs ETVerify to create the .etSignoff configuration file for the case
where an lv.EmbeddedTest -logic Off was used.
The make all target normally does not rerun this target once the .etEarlyVer file exists.
You must manually rerun it if your layout regions were modified, as embedded test
structures were added or removed.
make lvdb_preLayout
This make target generates the pre-layout Mentor Graphics database. The pre-layout
LVDB is stored in the ETSignOff Directory. This ensures that within only the ETSignoff
directory, you will be able to sign off the final post-layout version of your chip.
make <moduleName>_testbench
This make target runs ETVerify to create test benches for the verification of all
embedded structures. These test benches are as follows:
o Early Verification test benches in the case of lv.EmbeddedTest -logic On
Step 3: ETAssemble
June 2014
o Pre-Layout ETSignOff test benches in the case of lv.EmbeddedTest -logic Off
Even if the current physical region has child physical regions, only the controller within
the current region is simulated. The presence of the WTAP controller and the fact that
no timing critical test signals are left on the boundary of a layout region with Tessent
embedded test, the simulation performed on the child layout region is enough to verify
it. However, a test bench is generated to make sure all clocks, which are supposed to
reach the child layout region input pins, do actually reach them with the specified
frequency.
If clocks are generated from an internal PLLs or dividers, you likely need to describe a
reset procedure using a UserDefinedSequence wrapper and reference it in all xxxVerify
wrappers that need the given clock to be active. This is true also for the clock monitoring
test bench.
Note that any such reset sequence you define here will be automatically forwarded to the
.etManufacturing file during the Final ETSignOff step such that the reset sequences are
also applied during silicon testing.
make <moduleName>_sim
This make target simulates the verification test benches using the view of your design
which was modified by ETAssemble. This is either your RTL- or gate-level netlist
representation depending on the value of EmbeddedTestMergeFlow in the .etplan file.
Customizing Simulation Step
ETPlanner creates a script called simScript to facilitate the launching of the Verilog simulator to
simulate your ET-inserted design. The simScript accepts a set of command-line options that
allows you to customize your simulator runtime environment. Additionally, some of these
options can also be specified by using shell environment variables that allow your custom
options to be stored in a shell startup file (such as .cshrc). In the following description, the
command-line options and environment variables are listed. Some of the command-line options
are followed by the corresponding environment variable in parentheses, where applicable. If
both the command-line option and the environment variable are specified, then the command-
line option takes precedence.
-simulator (LV_DEFAULT_SIM)
This option can be set to point to your default Verilog simulator. The legal values for
this variable are VERILOG-XL, NC-VERILOG, MODELSIM, VCS. Default is the
value you specified for the Simulator option of the CADEnvironment wrapper in the
.etplan File .etplan or .CADSetup File. Note that the legal values are case-insensitive.
LVISIONPATH
This environment variable can be set to point to the top-level directory where the Mentor
Graphics toolset has been installed. By default, ETPlanner derives this value by tracing
the path from which ETPlanner is invoked. Typically, you need to set this environment
Step 3: ETAssemble
June 2014
variable if the Mentor Graphics toolset that has been used to generate the LV Flow
Environment is no longer available. For example, if you ran the ETPlanner using
LV2005 Version 5.0a to generate your ET Environment. If you have migrated to
LV2005 Version 5.0b, and the LV2005 5.0a version is no longer available at your site,
then you will need to reset this environment variable.
LSF_cmd
This environment variable is useful if you use the Load Sharing Facility from Platform
Computing. Set this variable to any prefix command (such as bsub) that must be
attached to the simulator launch command.
-noModuleWarning
This command-line option specifies that the simulator should suppress warning
messages.
+nc64bit
This command-line option is applicable only if the simulator is NC-Verilog and
specifies that 64-bit simulator be used.
-full64
This command-line option is applicable only if the simulator is VCS and specifies that
64-bit simulator be used.
make synth
This optional make target synthesizes all embedded test controllers which were
generated by ETAssemble. You can synthesize the embedded test controllers using this
target in a stand-alone manner. This is useful if you specify the
EmbeddedTestMergeFlow property to Gate.
Instead, if you have used EmbeddedTestMergeFlow used set to RTL, then you should
use the SDC file created by ETAssemblemerge it with your functional SDC file and
synthesize the embedded test controller along with the rest of your RTL in a single top-
down synthesis step.
make sta
This make target is used to invoke the static timing analysis tool PrimeTime using the
automatically generated STA script to verify the timing correctness of the embedded test
functions within the pre-layout netlist. When lv.EmbeddedTest -logic is On, this target
is found in the ETAssemble Directory.
Step 4: ETScan and Pre-Layout ETSignOff
June 2014
make fv_postETAvsGolden
This make target invokes Formality to verify that the functional mode has not been
affected by the embedded insertion process. The constraints to disable the embedded test
circuit is automatically generated when you run ETAssemble. This target is only present
if you define the FormalityLibFile in the .LVICTech File.
For more information, refer to section Formal Verification with Embedded Test.
make display_sim_results
This make target shows the summary results of all simulated test benches.
make all
This target can be used to run all mandatory sub-steps of the ETAssemble step with a
single command.
This step is applicable only if you have used lv.EmbeddedTest -logic On.
In this step, you perform the following sub-steps:
Insert the scan chains and testpoints, as described in ETScan
Perform pre-layout sign-off using rule checkers, Static timing analysis, and simulations,
as described in Pre-Layout ETSignOff
If you use Tessent FastScan as LogicBIST fault simulation engine instead of default
simulator, signatureAnalyze, run LogicBIST fault simulation and merge faults using the
the make targets described in the following sections:
o Running the LogicBIST Fault Simulation
o Merging Faults
ETScan
Figure 6-6 illustrates the scan insertion operation. In a design, you have the option to
immediately perform the scan chain insertion on the block before you run
make embedded_test on the higher level. Even though the flow shows you how to perform the
insertion on the entire chip in one step, you can choose to fully complete a core while others are
still being defined.
This sub-step is performed on the gate-level netlist view of the layout region. The circuit is
analyzed, and testpoints are computed and inserted. The flip-flops are then connected into scan
chains starting and ending at the logicTest controller. No new ports are created on the layout
region in this sub-step.
June 2014
A new SDC file is created in this sub-step to concatenate to your functional SDC so that you can
perform optimization and layout of your netlist with accurate timing specifications.
Figure 6-6. Perform Scan Chain and Testpoint InsertionETScan
For details on the tools run in this step, refer to these reference manuals:
ETAnalysis Tools Reference (for ruleAnalyze, signatureAnalyze, and scanGenerate)
ETVerify Tool Reference
Detailed information on each of the available make targets is provided in Make Targets for
ETScan.
Make Targets for ETScan
You run the make targets generated by ETPlanner for Step 4: ETScan of the LV Flow to insert
the scan chains and testpoints. You can simply invoke the make all target. You can run optional
make targets to analyze redundant faults or explicitly measure the impact of testpoints on fault
coverage with fault simulation. The following make targets are found in the ETScan Directory:
June 2014
make rulea_prescan
This make target runs the ruleAnalyze tool to perform rule checking on the layout region
in the non-scan mode. This target should never generate any error when the gate-level
netlist truly corresponds to the RTL which was verified by ETChecker.
make redundancy_analysis
This optional make target performs deterministic pattern generation to determine how
many redundant faults your circuit contains. A redundant fault cannot be detected with a
test vector. The percentage of redundant faults found in your circuit will limit the
maximum coverage achievable with embedded test.
make fault_sim_pre_tp
This optional make target performs fault simulation with random patterns on a circuit to
measure fault coverage before testpoint insertion. This target runs signatureAnalyze
before testpointAnalyze to check the exact logic BIST fault coverage without any
testpoints.
make testpointa
This make target runs a statistical analysis on the design and shows resulting fault
coverage improvement as a function of each added testpoint. It also shows you which
areas of the design are least randomly testable and generates a list of testpoints for
scanGenerate to insert while building scan chains.
make fault_sim_post_tp
This optional make target performs fault simulation with random patterns on a circuit to
measure fault coverage after testpoint insertion. This target runs signatureAnalyze after
testpoint analysis to confirm that the logic BIST fault coverage approximated by
testpointAnalyze is accurate.
make scang
This make target performs a replacement of regular flip-flops with scan flops, adds
capture-by-domain logic and testpoints, stitches together scan chains, and writes out the
modified files with a _scan extension. It also connects the scan chains to the logicTest
controller.
This target also creates a post-scan SDC script for physical optimization and timing
driven layout. For more information about this file, refer to Constraining ET Logic for
Synthesis and Layout.
Group Make Target for InsertScan
You can use the following make target in this step of the LV Flow that allows consecutive
execution of several sub-steps:
June 2014
make scanInsert
This make target executes the following targets consecutively: rulea_prescan,
testpointa, scang.
Pre-Layout ETSignOff
The ETScan Directory contains targets to perform Step 4: Pre-Layout ETSignOff of Tessent
SoC.
Once all scan chain insertion is completed, you can sign off any or all pre-layout physical
regions. The Pre-Layout ETSignOff sub-step is automatic and only requires your intervention if
you want to change the default sign-off options.
You must have created the child pre-layout LVDBs before you can start the ETScan sub-step of
the parent layout region. However, you do not need to have finished all simulation in the child
lvWorkSpaces before starting the ETScan step in the parent lvWorkSpace.
The Mentor Graphics ETVerify tool creates test benches for verifying the following objects in
the design prior to sending the netlist to layout:
IEEE 1149.1 test access port (TAP) and boundary scan
WTAP distributed test access controller
Memory BIST with reduced address space
Logic BIST
Single- and multi-chain ATPG modes
Once designExtract and ruleAnalyze have run without errors, you can continue to perform
Pre-Layout ETSignoff in parallel with the layout stage. The likelihood of finding a problem in
simulation with the new logic test timing architecture is extremely low.
Make Targets for Pre-Layout ETSignOff
You run the following make targets generated by ETPlanner for Step 4: Pre-Layout
ETSignOff of the LV Flow to perform pre-layout embedded test sign-off using rule checkers,
Static timing analysis, and simulations:
make rulea
This make target runs the ruleAnalyze tool on the pre-layout physical regions. The
ruleAnalyze tool runs with -mode set to All on the concatenated gate-level netlist. This
mode instructs ruleAnalyze to check both the Single and Multi scan rules, and the
LogicBIST rules, then generates any output files needed for ETVerify. Note that
ruleAnalyze defaults to using the 64-bit executable.
June 2014
STA scripts for logic BIST and scan test are generated during this ruleAnalyze run. For
information on how to use the generated timing analysis scripts, refer to Constraining
ET Logic for Synthesis and Layout.
make rulea_ext
This make target runs the ruleAnalyze tool on the pre-layout physical regions. The
ruleAnalyze tool runs with -mode set to ExtScan on the concatenated gate-level netlist.
This mode instructs ruleAnalyze to check the external logic of the ELTCore and
generates output files needed by ETVerify. Note that ruleAnalyze defaults to using the
64-bit executable.
STA scripts, the dofile <designName>.fastscan_GenSimPatterns_ext, and the test
procedure file <designName>.fastscan_proc_ext, to be used with the
make fastscan_ext_sim_vectors target, are generated for Tessent FastScan external test
mode during this ruleAnalyze run.
make config_etSignOff
This make target runs the ETVerify tool to generate the <moduleName>.etSignOff file.
You do not need to edit this file except for defining reset sequences for your PLLs or for
your functional clock divider using UserDefinedSequence wrappers.
Note that the content of the <moduleName>.etSignOff depends on the value on the
ETVerify -testLowerLevelControllers runtime option:
o When this option is set to Off (the default), ETVerify creates the
<moduleName>.etSignOff file that instructs to only test current level controllers.
o When this option is set to On, ETVerify creates the <moduleName>.etSignOff file
that instructs to test all controllers.
In both cases, the last test in the file consists of verifying the clock period on blocks and
cores right below the current level to insure that their clock signals are correctly routed
and divided. For details on ETVerify, refer to the manual ETVerify Tool Reference.
For detailed usage information, refer to Controlling ETSignOff Test Simulation.
make logictest_vectors
This make target generates the scan vector and logic BIST signature files.
If you used masking mechanism to shield identified issues with a chip in order to
facilitate additional testing, you need to rerun this make target. For detailed information
on how to use masking mechanism, refer to Preventing Corruption of the Logic Test
Signature.
This target is only present when the ETPlanner LogicTestFaultSimulator property is set
to SignatureA.
June 2014
make lvdb_preLayout
This make target generates the pre-layout databaseLVDBwhich collects all vector
and signature information plus any Mentor Graphics internal files into a directory stored
in the ETSignOff Directory so as to enable post layout sign-off with everything self-
contained within the ETSignOff directory.
make rulea_ext_lvdb
This make target runs ruleAnalyze in external mode on the ELT cores LVDB to
validate that there are no issues with the .scan_shell file.
make testbench
This make target generates all test benches necessary to fully verify each type and
instance of embedded test controllers merged into your design.
Even if the current physical region has child physical regions, only the controller within
the current region is simulated. The presence of the WTAP and the fact that no timing
critical test signals are left on the boundary of a layout region with Tessent embedded
test, the simulation performed on the child layout region is enough to verify it. However,
a test bench is generated to make sure all clocks which are supposed to reach the child
layout region input pins do actually reach them with the specified frequency.
If clocks are generated from internal PLLs or dividers, you need to describe a reset
procedure using a UserDefinedSequence wrapper and reference it in all xxxVerify
wrappers that need the given clock to be active. This is true also for the clock monitoring
test bench.
make <moduleName>_sim
This make target simulates the test bench associated with all embedded test within the
current physical region.
ETPlanner creates a script called simScript to facilitate the launching of the Verilog
simulator to simulate your ET-inserted design. For details, refer to Customizing
Simulation Step.
For more details on this step, refer to Constraining ET Logic for Synthesis and Layout.
make fv_preLayoutVsGolden
This make target invokes Formality to verify that the functional mode has not been
affected by the embedded insertion process. The constraints to disable the embedded test
circuit are automatically generated when you run ETAssemble. This target is only
present if you define the FormalityLibFile property in the .LVICTech File.
June 2014
make fv_preLayoutVsPostETA
This make target invokes Formality to verify that the post-ETAssemble functionality has
not been affected by the scan insertion process. The constraints to disable the scan
chains and testpoint circuit are automatically generated when you run ETAssemble. This
target is present only if you define the FormalityLibFile property in the .LVICTech File.
make fastscan_ext_sim_vectors
This make target invokes Tessent FastScan to do a full pattern count fault analysis and
generate 8 serial load and 64 parallel load simulation vectors for the external test mode
of the ELT core. This target is available when you specify the ExternalTestMode
property to ThirdPartyATPG and the ThirdPartyATPG property to FastScan or
TestKompress in ETPlanner.
During verification process, the FastScanVerify wrapper will appear in the .etSignOff
file.
make display_sim_results
This make target shows the summary results of all simulated test benches.
Group Make Targets for Pre-Layout ETSignOff
You can use the following make targets in this step of the LV Flow that allow simultaneous
execution of several tasks:
make preLayoutSignOff
This make target executes all targets to fully sign off the pre-layout netlist.
make preLayoutSignOff_noVerify
This make target executes all targets to generate the pre-layout LVDB without doing the
follow-up on simulations, PrimeTime and Formality checks. This is useful to allow
starting the layout process in parallel with the verification sub-steps.
June 2014
Using Tessent FastScan as LogicBIST Fault
Simulator
If you use Tessent FastScan as the LogicBIST fault simulation engine as described in Changing
the Fault Simulation Engine, you will run different set of make targets to perform the following
tasks:
Running the LogicBIST Fault Simulation
Merging Faults
This section provides as well information on the following:
Detected by Implication Faults Subclasses
Setting Tcl Variables on the Make Command Line
Running the LogicBIST Fault Simulation
When using signatureAnalyze as the fault simulation engine in the LV Flow, the targets make
fastscan_full_vectors and make testkompress_full_vectors generate full TDF vectors followed
by top-off with single stuck-at fault (SSF) vectors. When using Tessent FastScan as the fault
simulation engine, these targets by default generate LogicBIST top-off SSF vectors only. By
using Tcl variables TransitionFault and AtpgFaultList, discussed later in this chapter, you can
also generate LogicBIST top-off TDF vectors or revert to the default signatureAnalyze
simulation behavior.
The following make targets are generated in the ETScan and ETSignOff Makefiles to run
Tessent FastScan in the LogicBIST and external test modes:
make merge_sdc (only in ETScan)
This optional ETScan make target invokes PrimeTime to generate a merged SDC file
that can be read in by Tessent FastScan/TestKompress so multi-cycle and false paths can
be given credit in the fault analysis. The PrimeTime script, <designName>_merge.sdc,
will read in your SDC file and the SDC files created by ETAssemble and ruleAnalyze
and then will write out a merged SDC file, <designName>.sdc. PrimeTime is used to
merge the SDC because Tessent FastScan and Tessent TestKompress do not support all
of the Tcl introspection commands used in the ETAssemble and ruleAnalyze SDC files.
When running the Tessent FastScan and Tessent TestKompress targets in the ETSignOff
directory you can provide the SDC that was written out when the post-layout netlist was
created. To specify the SDC file, do one of the following:
o Copy or create a soft link to your SDC file, <designName>.sdc, that is in the
../modulesGate directory.
June 2014
o Point to your SDC file using the Tcl variable SDCFile. This variable can be set in the
.fastscan_setup_commands or .fastscan_atpg_commands files.
make fastscan_lbist_sim_vectors
This target generates the LogicBIST vectors needed for simulation as well as a flat
model that will be used by the make_fastscan_lbist_full_vectors target. The dofile used
by this target is named designName.fastscan_GenSimPatterns_lbist.
make fastscan_GenCrossDomainFaults
This target generates a list of inter-clock domain transition faults that will be used in
make fastscan_full_vectors and/or make fastscan_lbist_full_vectors targets when the
TransitionFault Tcl variable is set to On. Tessent FastScan is run in a way that all clock
domains are declared independently. This target is optional during pre-layout process.
make fastscan_lbist_full_vectors
This make target uses the flat model generated by the make_fastscan_lbist_sim_vectors
target to create the LogicBIST signature files and calculate the complete LogicBIST
stuck-at fault coverage. The dofile used by this target is named
designName.fastscan_GenFullPatterns_lbist.
Note
The make fastscan_lbist_full_vectors target is optional during pre-layout process (in the
ETScan step of the LV Flow).
make fastscan_ccm_full_vectors
This make target generates the complete stuck-at-fault coverage for the controller chain
mode (CCM). The dofile used by this target is named
designName.fastscan_GenFullPatterns_ccm. For information about the CCM
configuration in the scan chain router, see the Logic BIST Controller Chain Mode
section in the Embedded Test Hardware Reference manual.
Tcl Equivalents to signatureAnalyze Options
When using signatureAnalyze as the fault simulation engine, the LogicTestVectors wrapper in
the .etSignOff file is used to specify fault coverage and pattern options. The following ETVerify
properties have Tcl variables that will run equivalent commands in Tessent FastScan:
The StoredDiagnosticVectors property inside the LogicTestVectors: LogicBIST
wrapper allows you to specify the number of vectors that would be stored for diagnostic
purposes. The equivalent Tcl variable, StoredDiagnosticPatterns, is a list containing
one or more sub-lists where each sub-list is an integer pair representing the range of
diagnostic vectors to store. By default, only the first 1024 patterns, that is patterns from
0 to 1023, are stored. This Tcl variable is used by the -range switch of the set pattern
filtering command in Tessent FastScan.
June 2014
The following example shows how to store the diagnostics vectors 0:1023, 2048, and
3000:3256:
o Specify the variable in the designName.fastscan_atpg_commands_lbist file
set StoredDiagnosticPatterns { {0 1023} {2048 2048} {3000 3256} }
The following usage limitation applies to StoredDiagnosticPatterns and will be resolved
in future releases:
o If StoredDiagnosticPatterns is specified with a non-contiguous range of numbers
then ETVerify is unable to extract a pattern outside of the first range of numbers. For
example, if you specify:
set StoredDiagnosticVectors { {0 1023} {2048 3000} }
then ETVerify cannot extract the patterns after 1023.
The NDetect property in the .etSignOff file enables you to specify multiple detect fault
coverage reporting when generating vectors. The equivalent Tcl variable has the same
name, NDetect, and must be specified as an integer. NDetect defaults to 1. This variable
will be used by the set multiple detection command in Tessent FastScan to specify the
-simulation_drop_limit switch, if running in LogicBIST mode, or
-guaranteed_atpg_detections switch, when running in ATPG (edt, single, or multi)
mode.
The following example shows how to set NDetect to a value of 4.
o Specify the variable in the designName.fastscan_atpg_commands_lbist file:
set NDetect 4
The FaultList property in the .etSignOff file allows you to specify which type of faults
to be targeted by signatureAnalyze. You can target all faults or only the faults missed by
LogicBIST. The equivalent Tcl variable, AtpgFaultList, is specified as a string and
defaults to LogicBistTopUp, and specifying any value other than LogicBistTopUp will
target all faults. This variable is used in the
designName.fastscan_GenFullPatterns_<mode> dofile, where <mode> is edt, multi, or
single. When set to LogicBistTopUp, Tessent FastScan will only target the faults that are
missed by LogicBIST when make fastscan_lbist_full_vectors is run.
The following example shows how to specify the AtpgFaultList so LogicBIST top-up is
not performed:
o Specify the variable in the designName.fastscan_atpg_commands_lbist file:
set AtpgFaultList "FullSet"
The TransitionFault property in the .etSignOff file allows you to specify whether
signatureAnalyze simulates the transition fault model in addition to the stuck-at fault
model. The equivalent Tcl variable, TransitionFault, is specified as a string and
June 2014
defaults to Off. When this variable is set to On then the dofiles will perform fault
simulation of the transition fault model in addition to the stuck-at fault mode.
The following example shows how to fault simulate the transition fault mode:
o Specify the variable in the designName.fastscan_atpg_commands_<mode> file:
set TransitionFault "On"
The ChainMaskingFile property in the .etSignOff file allows you instruct
signatureAnalyze which LogicBIST scan chains containing failing flops should be
masked. In the LogicBIST dofiles, this property is replaced by two Tcl variables,
MaskChainList and MaskType:
o MaskChainList is a Tcl list that declares which LogicBIST scan chains should be
masked. The specified value must match the chain ID of one of the chain names
specified with the
add scan chains command.
o MaskType is a string that will declare what type of masking will be used. Valid
values are as follows:
o None No chain masking is performed.
o Output All LogicBIST chain inputs are normally fed by the PRPG but the
output of the masked chains are forced to zero (0) before going into the MISR.
As a result, the output of these masked chains does not contribute to the
signature computation.
o InputOutput The input and output of the masked chains are forced to zero (0)
so that they do not contribute to the signature computation, but also, they are
filled with zeros.
The following example shows how to perform Output chain masking for the LogicBIST
chains lbist3 and lbist14:
set MaskType Output
set MaskChainList {3 14}
Merging Faults
When using Tessent FastScan as the fault simulation engine the target, make merge_faults, is
generated in the ETScan and ETSignOff makefiles that will create a combined fault list for the
physical region, one for the transition fault model and one for the stuck-at fault model. This
target will also report the overall fault coverage for the internal test mode and the external test
modes.
If the current design uses signed-off scan inserted blocks (ELT cores), another make target will
be automatically run before make merge_faults. The target, make updateFaultReports, will
verify that the lower level LVDBs contain the right fault files for Tessent FastScan. If
June 2014
signatureAnalyze was used for fault simulation during the signoff of those ELT cores,
ruleAnalyze will be launched in a special mode to create new fault reports that will be used in
Tessent FastScan.
Note
The make merge_faults target is optional during pre-layout process (the ETScan step of
the LV Flow).
The dofile used by the make merge_faults target, designName.fastscan_merge_faults, accepts
the following Tcl variables:
AtpgFaultList
TransitionFault
ExtraTdfFaultListFiles
ExtraStuckFaultListFiles
AtpgFaultList
The AtpgFaultList Tcl variable specifies whether LogicBIST top-up is performed in the make
fastscan_full_vectors target. When set to LogicBistTopUp, the dofile will load the fault list file
created by make fastscan_lbist_full_vectors, otherwise, it will target the full fault set.
The following example shows how to specify that LogicBIST top-up is not performed:
Specify the variable in the designName.fastscan_atpg_commands_<mode> file:
set AtpgFaultList "FullSet"
TransitionFault
The TransitionFault Tcl variable specifies whether the fault merging should create a merged
fault list file for the transition fault model in addition to the fault list file for the stuck-at fault
model. This variable defaults to Off. You cannot set this variable to On if it was Off when the
pattern generation targets were run.
The following example shows how to perform fault merging of the transition and stuck-at-fault
models:
1. Edit the designName.fastscan_atpg_commands_<mode> file and set the
TransitionFault variable to On.
set TransitionFault On
2. Run the Makefile targets to generate the patterns and fault list files.
June 2014
make fastscan_sim_vectors ; # When TestKompressPresent is Yes the
# target is testkompress_sim_vectors
make fastscan_GenCrossDomainFaults
make fastscan_full_vectors ; # When TestKompressPresent is Yes the
# target is testkompress_full_vectors
3. Merge the faults.
make merge_faults
The ExtraTdfFaultListFiles Tcl variable allows you to supply additional transition fault list
files that you might have created that should be taken into account when generating the
combined fault list file for the physical region.
The following example shows how to specify extra tdf files that might have been created when
running Tessent FastScan for different masking configurations.
1. Edit the designName.fastscan_atpg_commands_lbist dofile to declare the different
masking configurations:
if {[string toupper $RunMode] == "LBIST"} {
if {$PatternSetSize == "Full"} {
if {$PatternSetID == "_M1"} {
set MaskChainList {1}
set MaskType InputOutput ;# None | Output | InputOutput
} elseif {$PatternSetID == "_M2"} {
set MaskChainList {2 10 13}
set MaskType Output ;# None | Output | InputOutput
}
}
}
2. Run Tessent FastScan for all the masking configurations:
make fastscan_lbist_full_vectors PatternSetID=M1
After running these targets, a fault list file will exist for each masking configuration:
LV_WORKDIR/dcm.fastscan_faults_tdf_lbist
LV_WORKDIR/dcm.fastscan_faults_tdf_lbist_M1
3. Define the ExtraTdfFaultListFiles variable in the designName.fastscan_atpg_commands
dofile:
if {[string toupper $RunMode] == "MERGE_FAULTS"} {
June 2014
set ExtraTdfFaultListFiles {}
lappend ExtraTdfFaultListFiles
lappend ExtraTdfFaultListFiles
}
4. Now when merging the faults, the fault list files for all the masking configurations will
be taken into account.
make merge_faults
The ExtraStuckFaultListFiles Tcl variable allows you to supply additional stuck-at fault list
files that you might have created that should be taken into account when generating the
combined fault list file for the physical region.
The following example shows how to specify extra stuck-at files that might have been created
when running Tessent FastScan for different masking configurations.
1. Edit the designName.fastscan_atpg_commands_lbist dofile to declare the different
masking configurations:
if {[string toupper $RunMode] == "LBIST"} {
if {$PatternSetID == "_M1"} {
set MaskChainList {1}
} elseif {$PatternSetID == "_M2"} {
}
}
}
2. Run Tessent FastScan for all the masking configurations:
After running these targets a fault list file will exist for each masking configuration:
LV_WORKDIR/dcm.fastscan_faults_stuck_lbist
LV_WORKDIR/dcm.fastscan_faults_stuck_lbist_M1
3. Define the ExtraStuckFaultListFiles variable in the
designName.fastscan_setup_commands dofile:
if {[string toupper $RunMode] == "MERGE_FAULTS"} {
set ExtraStuckFaultListFiles {}
June 2014
lappend ExtraStuckFaultListFiles
lappend ExtraStuckFaultListFiles
}
4. Now when merging the faults the fault list files for all the masking configurations will
be taken into account.
make merge_faults
Detected by Implication Faults Subclasses
New Detected by Implication (DI) fault subclasses exist for Memory BIST (MBIST),
TAP/WTAP (TAP), LogicBIST (LBIST), asynchronous set/reset (SetRst), and boundary scan
(BScan). When the report statistics command is run these fault subclasses will be reported in the
DI Faults section. Figure 6-7 illustrates how these DI faults will appear in the log file. The
assumption is that the MBIST, TAP, BScan, and AsyncSetReset patterns are also run during
manufacturing test to cover the faults listed in those categories.
Figure 6-7. DI Faults in the Log File Snippet
// command: report statistics
Statistics Report
Stuck-at Faults
-------------------------------------------------------------------------
Fault Classes #faults
(total)
...
DI Faults
--------------------------------------------------------
DI (det_imp)
MBIST 1673 ( 0.87%)
TAP 2640 ( 1.37%)
LBIST 14024 ( 7.28%)
SetRst 7406 ( 3.84%)
Unclassified 22238 (11.54%)
Setting Tcl Variables on the Make Command Line
A few of the Tcl variables can be set via the Make command line allowing you to quickly run a
target to see how the Tcl variable will impact the run. The following shows which Tcl variables,
along with an example of its usage, can be specified on the make command line:
StoredDiagnosticPatterns
make fastscan_lbist_full_vectors StoredDiagnosticPatterns="{0 1023}
{2048 2048} {3000 3002}"
NDetect
June 2014
make fastscan_full_vectors NDetect=4
AtpgFaultList
make fastscan_full_vectors AtpgFaultList="FullSet"
TransitionFault
make fastscan_full_vectors TransitionFault="On"
make merge_faults ExtraTdfFaultListFiles="dcm.faults_tdf_extra1
dcm.faults_tdf_extra2"
make merge_faults ExtraStuckFaultListFiles="dcm.faults_stuck_extra1
dcm.faults_stuck_extra2"
SDCFile
SDCFile="/projects/graphics/design/postlayout.sdc
Note
It is recommended that all the new Tcl variables previously mentioned be set once in the
designName.fastscan_atpg_commands or
designName.fastscan_atpg_<mode>_commands file so that it is used consistently
between the pattern generation targets and the fault merging target.
Overriding the create_patterns and simulate_patterns
Commands in the Dofiles
Note
This override capability is available only for IP generated with Tessent v2013.3 or later.
You have the ability to override the create_patterns and simulate_patterns commands in the
dofiles with your own TCL procedure so that you can run additional commands without having
to edit the dofiles. If you do not define your own command, a default command is created. You
can specify the user-defined command in the
<designName>.fastscan_atpg_commands[_<mode>] dofile. The following shows how the new
commands are defined and used in the dofile:
if {[file exists <designName>.fastscan_atpg_commands]} {
DOFile <designName>.fastscan_atpg_commands
}
if {[file exists <designName>.fastscan_atpg_commands_<mode>]} {
DOFile <designName>.fastscan_atpg_commands_<mode>
}
June 2014
...
if {[info commands simulate_patterns_local] != ""} {
display_message -note "Using user-defined version of simulate_patterns_local."
} else {
display_message -note "Using default version of simulate_patterns_local."
proc simulate_patterns_local {args} {
simulate_patterns {*}$args
}
}
if {[info commands create_patterns_local] != ""} {
display_message -note "Using user-defined version of create_patterns_local."
} else {
display_message -note "Using default version of create_patterns_local."
proc create_patterns_local {args} {
create_patterns {*}$args
}
}
...
create_patterns_local
...
simulate_patterns_local -store_patterns all
When writing a customized simulate_patterns_local or create_patterns_local command, TCL
variables defined in the dofile and Tessent Shell commands can be used to determine the current
context of the tool. For example, the following shows two variables and a Tessent Shell
command that can be used to customize the user-defined commands:
RunMode A TCL variable defined in the dofile that identifies in which mode the
design is configured. The current run modes are ccm, edt, iddq, iddq_multi, iddq_single,
lbist, multi, ncapture_edt, ncapture_multi, ncapture_single, single, and ext.
PatternSetSize A TCL variable defined in the dofile that identifies whether a
simulation pattern set (<designName>.fastscan_GenSimPatterns_<mode>) or a full
pattern set (<designName>.fastscan_GenFullPatterns_<mode>) is being created. The
variable can be set to drc, sim, or full.
get_fault_type A Tessent Shell command that returns the current fault model. For
example:
// command: set_fault_type transition -no_shift_launch
// command: puts "fault_type = [get_fault_type]"
fault_type = transition
// command: set_fault_type stuck
// command: puts "fault_type = [get_fault_type]"
fault_type = stuck
The following example defines a simulate_patterns_local command, illustrating how you can
run extra commands before and after simulate_patterns, for both TDF and SSF, when
generating a full LogicBIST pattern set:
> cat JOE.fastscan_atpg_commands
proc simulate_patterns_local {args} {
set fault_type [string tolower [get_fault_type]]
if {( [string tolower $::RunMode] == "lbist" ) &&
( [string tolower $::PatternSetSize] == "full" )} {
if {$fault_type == "transition"} {
<pre_tdf_commands>
<post_tdf_commands>
} else {
Step 5: Final ETSignOff
June 2014
<pre_ssf_commands>
<post_ssf_commands>
}
} else {
}
}
The ETSignOff Directory contains targets to perform the final step of the LV Flow Step 5:
Final ETSignOff on the final post-layout netlist.
Once you have your final post-layout netlist, the final step is to sign off the physical regions.
The Final ETSignOff step is automatic and only requires your intervention if you want to
change the default sign-off options.
In this step, you use make targets to rule check your final netlist, generate the final test vectors,
store them in a final Handoff Database format (LVDB), verify these test vectors using
simulation, and generate the test vectors for manufacturing test.
Final ETSignOff verification is similar to the verification performed during Pre-Layout
ETSignOff. For the descriptions of the make targets used to perform verification for final
sign-off, refer to:
Make Targets for Pre-Layout ETSignOff (The same make targets are used for both
Pre-layout ETSignOff and Final ETSignOff)
and
Additional Make Targets for Final ETSignOff
Step 5: Final ETSignOff of the LV Flow is also used to generate the final static timing analysis
you use to sign off the embedded test timing of your chip. For details, refer to Performing Static
Timing Analysis.
Additional Make Targets for Final ETSignOff
In addition to the targets described in Make Targets for Pre-Layout ETSignOff, you invoke the
following targets to generate your manufacturing patterns, create your final LVDB, and execute
the ECO flow.
make config_etManufacturing
This make target runs the ETVerify tool to generate the
<moduleName>.etManufacturing file. It uses the information you might have entered
into the .etSignOff file, such as PinSetting, UserBit settings, and
June 2014
UserDefinedSequences, and forwards them automatically into the .etManufacturing
file.
make lvdb_final
This make target generates the final post-layout databaseLVDBwhich collects all
vector and signature information plus any Mentor Graphics internal files into a directory
structure so as to enable manufacturing and system reuse of the embedded test
capabilities. It can also be used to facilitate handoff of cores with embedded test to third
parties.
make patterns
This target runs ETVerify with the -configFile option set to the .etManufacturing file to
create test patterns in the WGL or STIL format. The .etManufacturing file contains
information about what vectors to include and how to format the patterns.
make rulea_eco / make lveco
These two targets are used if you have performed a functional ECO on your netlist and
want to automatically adjust the logic test circuitry for the modified netlist. Refer to
Managing the ECO Process for more information.
Group Make Targets for Final ETSignOff
You can use the following make target in this step of the LV Flow that allows simultaneous
execution of several tasks:
make all
This make target executes the following targets consecutively: rulea, logictest_vectors,
lvdb_final, testbench, and sim.
Constraining ET Logic for Synthesis and Layout
June 2014
Constraining ET Logic for Synthesis and
Layout
During Step 3: ETAssemble you obtain SDC scripts that you use to constrain the Mentor
Graphics IP hardware during synthesis and/or timing-driven layout of your design.
For designs with a logicTest controller, a second SDC constraints file is generated during the
ETScan step to be appended to the SDC file during the RTL synthesis for the physical synthesis
and layout steps.
Before starting your design synthesis, refer to the
ETAssemble/outDir/SynthesisAndLayout.README file. This file explains how to use these
SDC files and guides you through steps that you must follow to handle the Tessent hardware
during your synthesis and layout process. All Mentor Graphics SDC script files names, location,
and usage are described in that file. A README file is automatically generated by ETAssemble
and provides you with the step-by-step instructions specific to your chip.
Also refer to the Application Note Timing Constraints and Clock Tree Synthesis for a detailed
description of how SDC is used to constrain the Embedded Test hardware during synthesis and
layout. You will also find a description on how the embedded test hardware is handled during
the clock tree synthesis step.
Performing Static Timing Analysis
During Step 3: ETAssemble of the LV Flow, you create an STA script file that you can use to
perform static timing analysis of the TAP, boundary scan, and memory BIST modes. This file
also contains a Tcl procedure that disables all Tessent test circuits in your design, allowing you
to analyze your functional mode timing without any interference from these structures.
If your design has a logicTest controller, more STA scripts are generated by the make rulea
targets during the ETScan step, in order to cover the timing of the logic test modes of your pre-
layout netlist.
During Step 5: Final ETSignOff of the LV Flow, you create a post-layout version of the
LogicTest mode STA scripts similarly to what was created for the pre-layout netlist in the
ETScan step.
Before running any of the Mentor Graphics STA scripts, refer to the
ETAssemble/outDir/SynthesisAndLayout.README file. This file details a step-by-step
procedure that you must follow in order to validate the timing of all Tessent embedded test
structures inside your design. All Mentor Graphics script files names, locations, and usage are
described in that file. A README file is automatically generated by ETAssemble and provides
you with the step-by-step instructions specific to your chip.
Managing the ECO Process
June 2014
Managing the ECO Process
In order to fix violations of the Mentor Graphics design rules following a functional ECO (that
is, a change required during the layout of the circuit), use these make targets: rulea_eco and
lveco. These two make targets are only used if the functional ECO applied to the netlist is
significant enough to cause Mentor Graphics design rule violations.
make rulea_eco
This target invokes ruleAnalyze with -mode set to ECO. The ruleAnalyze tool analyzes the
post-functional ECO netlist to determine what edits are required to re-make the netlist Mentor
Graphics compliant. The ruleAnalyze generates the .lveco file. This file outlines the actions
required to fix a post-functional ECO netlist and restore the proper behavior of the Scan and
LogicBist modes. You edit this file only to customize the following:
Change the location of flip-flop insertion in the pre-existing scan chains.
If you do not plan to perform scan chain reordering on the post-LV ECO netlist then it is
better to specify the insertion point between two flip-flops that are close to the one being
added. You select alternate scan insertion points in an information file .ecoinfo that is
generated in the LV_WORKDIR directory. This file lists the valid scan insertion points
for the pre-existing scan chains in the design. The scan insertion points are grouped
together into separate wrappers to identify compatibility.
Specify existing spare gates to use for controlling logic instead of instantiating new
gates
You need to specify the use of spare gates when you want the layout of the post-LV
ECO netlist to only affect the top metal layers.
Reuse gate ID
Specifying a different ECO gate instance prefix using the following property:
ECOGateInstancePrefix: LVECO_;
All cells instantiated in your netlist to perform the ECO will use the specified instance
name prefix. If you run the ECO process more than once on the same netlist, specify a
different prefix each time to ensure that instance name conflict is not created.
Note
ECO changes cannot cause any Basic or Synchronous rule violations. This run of
ruleAnalyze validates such rules and flags errors. If such errors are flagged then you must
fix these violations manually.
Selecting the Implementation Style of Testpoints
June 2014
Once you are satisfied with the edits detailed in the .lveco file, the changes must be applied to
the post-ECO netlist using the target make lveco.
make lveco
This target invokes ecoGenerate. The ecoGenerate tool uses the edited .lveco file and creates a
corresponding designAssemble script, then it invokes the designAssemble tool to modify the
post-ECO netlist according to the commands described in the designAssemble script.
A new post-LV ECO view of the netlist is created. The modified netlist file has the
_postLVECO file extension appended to it. The softlink
../../concatenatedNetlist/<designName>.netlist is automatically updated to point to this netlist
view.
The post-LV ECO netlist must be re-verified. The standard post-optimization Sign-Off Flow
needs to be completed on the post-LV ECO netlist.
For detailed usage and reference information on managing the ECO process, refer to Managing
Your ECO Process.
Selecting the Implementation Style of
Testpoints
When control testpoints are implemented using dedicated flip-flops, the routing is minimized
because the flip-flop is right next to the test point location. The timing is not critical because the
flip-flop controlling the test point holds during the entire capture burst.
The testpoint area varies and can be high. The area depends on circuit characteristics, the
number of logic BIST patterns allowed, and the required fault coverage. On average the area is
about 1% (for 99% SA with 100K patterns). For some circuits the area can be up to 3%. (These
metrics assume that 1% area is about 1 test point per thousand gates).
Dedicated flip-flops represent a large percentage of the test point area cost: the flip-flop
constitutes over 80% of a control point. Typically, the majority of testpoints are control points.
Functional flip-flops offer the potential to significantly reduce this cost. Potentially the area
reduction can be up to 75% for control points. The testpointAnalyze tool will use a dedicated
flip-flop if it is unable to find a functional flip-flop that does not introduce negative side effects
(as explained below).
The implementation of control points that use functional flip-flops has been carefully crafted to
avoid negative side effects. The implementation intends to avoid the introduction of untestable
faults. The use of functional flip-flops may incur some coverage loss in logic BIST due to
reconvergence. This effect is still being analyzed. No new redundant faults are expected to be
introduced by the control point implementation.
Selecting the Implementation Style of Testpoints
June 2014
The control point implementation also avoids the introduction of new timing constraints. The
testpointAnalyze tool selects a functional flip-flop from the functional flip-flops within the
fanin cone of the control point location. In this way, no new timing constraints are introduced
between unrelated registers. Consequently, timing closure is not affected when using functional
flip-flops in control points.
The testpointAnalyze selects a functional flip-flop that is close to the testpoint location. This
avoids additional constraints on placement as the required signals are close by.
Finally, the path from the functional flip-flop to the test point is disabled during functional
mode.
When testpointAnalyze is enabled to use functional flip-flops to drive control testpoints, the
tool selects a functional flip-flop close to the desired testpoint location. If testpointAnalyze is
unable to locate a functional flip-flop that does not introduce new timing constraints, the tool
implements a dedicated flip-flop instead. In either case, the design remains fully testable and no
redundant faults are introduced.
When testpointAnalyze selects a functional flip-flop to drive a control testpoint, it adds the
following information about the flip-flop to the existing testpoint information in the .tpinfo file:
Functional_FF_namespecifies a name of the functional flip-flop selected to drive the
control point.
Inversion_flagindicates whether the output of the functional flip-flop is inverted
before it is applied to the control testpoint.
The format of the .tpinfo file is as follows:
Macro Signal Origin Testpoint Instance Functional Inversion
Name Name Desig Type Name FF Name Flag
mto_capnet 120032 U5415 AND-CONTROL Inst1 func_ff_name1 YES;
mto_device n1489 U877 AND-CONTROL Inst2 - s-;
mto_cap n13732 U5401 OR-CONTROL Inst1 func_ff_name3 NO;
mto_mcint n132 U4 OR-CONTROL Inst3 func_ff_name4 YES;
mto_tcio n1375 U529 OBSERVATION Inst1 - -;
Preventing Corruption of the Logic Test Signature
June 2014
Preventing Corruption of the Logic Test
Signature
It is possible that systematic and unexpected chip fabrication errors prevent the logicTest
controllers from calculating a test signature for a portion of the circuit. You can use masking to
shield identified issues with a chip in order to facilitate additional testing. You can use masking
to hide the following:
Flip-flops that captured unknown values
Hold-time problems that prevent loading correct values in certain scan chains and cause
other scan chains to capture unknown values
There are two types of masking:
Output
All logicBIST chains inputs are normally fed by the PRPG but the output of the masked
chains is forced to zero (0) or one (1) before going into the MISR. As a result, the output
of these masked chains does not contribute to the signature computation.
InputOutput
The input and output of the masked chains are forced to zero (0) or one (1) so that they
do not contribute to the signature computation, and also, they are filled with the masking
value. Other scan chains that receive data from the masked chains will capture known
values although there will be some fault coverage reduction.
The following sections describe how to perform masking in the LV Flow when using one of the
following tools as the LogicTestFaultSimulator:
signatureAnalyze
FastScan
signatureAnalyze
You can use masking both for logicBist and ATPG Compression modes by specifying one of
the following files:
ChainMaskingFile
A user-created manual masking configuration file
FlogMaskingFile
A failure log file (flog) generated by diagnostic tool
June 2014
To specify these two files, use the syntax in the ETVerify configuration file
<moduleName>.etSignOff illustrated in Figure 6-8.
Figure 6-8. ETVerify Configuration File Syntax for Masking Files
etv (<designName>) {
LogicTestVectors {
DeterministicATPG {
}
LogicBist {
ChainMaskingFile:
<manualMaskingConfigFile>.etChainMasks.tpl;
FlogMaskingFile: <flogFile>.flog;
}
CompressedATPG {
ChainMaskingFile:
<manualMaskingConfigFile>.etChainMasks.tpl;
FlogMaskingFile: <flogFile>.flog;
}
}
}
Note
Note that masking with ones (1) is not supported with signatureAnalyze as
LogicTestFaultSimulator.
These properties are used when running the make logictest_vectors target that invokes
signatureAnalyze:
If ChainMaskingFile is specified, signatureAnalyze evaluates the failing flip-flops
specified in this file and masks the scan chains that contain those flip-flops. It also
masks the scan chains specified in this file. For information about the syntax of the
ChainMaskingFile, refer to Masking Input Files in the manual ETAnalysis Tools:
Reference.
If FlogMaskingFile is specified, signatureAnalyze evaluates the failing flip-flops
specified in the failure log file and masks the scan chains that contain those flip-flops.
For an example of this file, refer to Masking Input Files in the manual ETAnalysis Tools:
Reference.
If both ChainMaskingFile and FlogMaskingFile are specified, signatureAnalyze merges the
two resulting lists of chains to mask.
If any of the scan chains specified in the masking configuration file is InputOutput masked, then
signatureAnalyze InputOutput masks all requested chains and modifies the masking scheme
accordingly. Otherwise, Output masking is performed.
The signatureAnalyze tool generates a merged list of failing flops and masked chains in the
following files:
June 2014
LV_WORKDIR/<designName>.siga_mask_lbist file for logicBIST mode
LV_WORKDIR/<designName>.siga_mask_reseed file for ATPF Compression
These files have the exact same format as the ChainMaskingFile. Thus, you can reuse the files
to specify all masking schemes in a single file for make logictest_vectors runs.
The signatureAnalyze tool takes the masking information into account during a logicBIST
mode and ATPG Compression mode runs. The fault coverage calculation takes into account
that no faults can be detected on the masked chains. The reduction in fault coverage is
dependent on various parameters, such as the percentage of masked chains and the circuit
structure. The vectors stored in the output vector file reflect the impact of masking.
FastScan
When using Tessent FastScan as Logic Test fault simulation engine, the masking is performed
by means of declaring Tcl variables in your Tessent FastScan dofile. You must set two Tcl
variables, MaskType and MaskChainList, to declare whether Output or InputOutput masking is
to be performed, and what chains will be masked. If you wish to create signatures for multiple
masking configurations then the Tcl variable PatternSetID can be used to append a suffix to all
generated files so that a single LVDB can contain multiple masking configurations.
The following example illustrates the tasks needed to perform masking with Tessent FastScan.
1. Before you can perform masking, first, you must determine which chains need to be
masked. When you know which flop needs to be masked you need to look at the file
LV_WORKDIR/<designName>.fastscan_scan_chains_lbist, search for the flop(s) that
need to be masked, then identify the chain number(s). For example, if the flop you want
to mask is D_oxygen_reg[12], then looking at the .fastscan_scan_chains_lbist file, you
can see that this flop is on chain number 18 (Marked in Red).
14 lbist18 MASTER (FF-TE) FFFF 47517 /LV_WRCK T TDC161
D_oxygen_reg[13] LV_SDFF_P_RB/mlc_dff_1 (SD,Q)
D_oxygen_reg[12] LV_SDFF_P_RB/mlc_dff_1 (SD,Q) <-- flop that needs
to be masked
D_oxygen_reg[11] LV_SDFF_P_RB/mlc_dff_1 (SD,Q)
2. Once all the chains that need to be masked have been identified, create the dofile
<designName>.fastscan_atpg_commands_lbist to declare the different masking
configurations:
if {$PatternSetID == "_CM1"} {
} elseif {$PatternSetID == "_CM2"} {
set MaskChainList {2 10 13 18}
June 2014
}
}
Note
Tessent FastScan supports chain masking with zeros (0) by default, or ones (1). For
information on masking chains with one (1), refer to ETPlanner
ChainMaskingLoadUnloadValue property.
3. Invoke Tessent FastScan to generate all masking configurations shown in Task 2. To
enable a specific masking configuration, specify the PatternSetID option to the desired
masking ID on the Makefile command line.
make fastscan_lbist_full_vectors PatternSetID=CM1
make fastscan_lbist_full_vectors PatternSetID=CM2
Once these targets have been run the LV_WORKDIR will contain vector, MISR and
PRPG files for all configurations, for example:
After declaring all of the masking configurations Tessent FastScan needs to be run as
shown in the following example:
LV_WORKDIR/<designName>.fastscan_vectors_lbist
LV_WORKDIR/<designName>.fastscan_vectors_lbist_CM1
LV_WORKDIR/<designName>.fastscan_vectors_lbist_CM2
LV_WORKDIR/<designName>.misr_data_lbist
LV_WORKDIR/<designName>.misr_data_lbist_CM1
LV_WORKDIR/<designName>.misr_data_lbist_CM2
LV_WORKDIR/<designName>.prpg_data_lbist
LV_WORKDIR/<designName>.prpg_data_lbist_CM1
LV_WORKDIR/<designName>.prpg_data_lbist_CM2
4. To use one of the generated chain masking configurations in ETVerify, you must
specify the PatternSetID property in the LogicbistVerify: TestStep: Controller
wrapper. In the following example TestStep (ParallelLoad) will use the masking
configuration CM1, while the TestStep (SerialLoad) will use configuration CM2
(Marked in Red):
LogicbistVerify (glchsmpar3) {
PatternName: logicbistv_engine;
SimulationScript: engine_sim.script;
UseAsyncClocks: On;
TckPeriod: 10.0ns;
BurstCyclesWithShiftClock: Off;
SlowedDownBurstCycles: 0;
//EffectiveSlowedDownFrequency: 1/2 | 1/4 | 1/8;
ClockPeriods {
engine_clk: 2.5ns;
}
TestStep (ParallelLoad) {
Controller (DP1.WBP0) { // engine_LVISION_LOGICTEST
// ParallelLoad: On;
PatternSetID: CM1;
Controlling ETSignOff Test Simulation
June 2014
ShiftClkSelect: TCK;
StartVector: 1;
EndVector: 256;
}
}
TestStep (SerialLoad) {
Controller (DP1.WBP0) { // engine_LVISION_LOGICTEST
PatternSetID: CM2;
ShiftClkSelect: SHIFTCLKSRC1/4;
StartVector: 1;
EndVector: 2;
}
}
}
Controlling ETSignOff Test Simulation
When signing off a core, a block, or a chip that contains blocks or cores, by default, simulation
tests are run only on top-level controllers assuming controllers in blocks and cores right below
the current level are already simulated in their respective ETSignOff lvWorkSpaces. Only a
simple clock period test is performed on blocks and cores right below the current level to insure
that their clock signals are correctly routed and divided.
You might choose instead to simulate controllers in lower-level blocks and cores:
You can set this up front in the embedded test insertion process by specifying the
TestKompressScanChainNumber property in the ETPlanner configuration file to On.
You can also set this at the time of generating Pre-Layout ETSignOff files using the
ETVerify -testLowerLevelControllers runtime option.
In both cases, the contents of the <moduleName>.etSignOff file will contain additional
xxxVerify wrappers for controllers in the lower level of your design.
Archiving Your Design
In order to be able to re-create the original runs, you can archive all relevant make targets,
configuration files, etc., using the following targets:
make archive_config
This target creates a LVWS.archive file that contains a list of all files and directories that
are to be archived. When running this target, you can use the following command-line
options:
o -output [file]
Specifies the name of the archive file list. Defaults to LVWS.archive.
o -addLogFiles
June 2014
Adds log files to the archive file list.
o -includePatterns
Adds WGL pattern files to the archive file list.
To use the above options, you must use the cmdOptions variable. For example,
make archive_config cmdOptions=-addLogFiles \
-includePatterns
The generated LVWS.archive file contains the following:
o Most of the elements created by ETPlanner, such as make targets, README files,
bin, vendorLib, html, etc.
o No files from LV_WORKDIR, except XXX_colar.simTargets that are needed when
using ccsMake.
o The concatenated netlist _postLV.
o All configuration files: .designe, .rulea, etc.
o STA files.
o Log files when the -addLogFiles option is used.
o WGL patterns when the -includePatterns option is used.
o .etplan configuration files.
make archive
By default, this target archives the workspace with the command tar cvf. You can
expand symbolic links by running the following target:
make archive TARCMD=tar cvhf
June 2014
June 2014
Appendix A
Using Gated Clocks with Scan and Logic
BIST
This appendix describes designs with gated clocks and explains how to implement scan and
logic BIST in a design containing gated clocks using the LV Flow.
This appendix covers the following topics:
Overview of Designs with Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Inserting Scan Chain and Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Synthesizing With Gated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Describing Your Clock Gating Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Using Capture-By-Domain Through Clock-Gating Cells . . . . . . . . . . . . . . . . . . . . . . . . . 166
Overview of Designs with Gated Clocks
In a digital CMOS circuit, the quiescent current is approximately zero. When signals are applied
to the inputs of the circuit, the current typically increases by several orders-of-magnitude. This
large increase in current during circuit operation is due to the charging and discharging of the
parasitic capacitances of the CMOS transistors and interconnect capacitance. An additional
component of the current exists in the n-channel and p-channel transistors of a gate when the
gates input voltage passes through the mid-rail range during switching.
On a design that does not contain gated clocks, the clock inputs of all flip-flops and much of the
combinational logic within the circuit toggles when the input clocks are active. For portable
applications in which battery operation is required, the product must be designed to provide an
operating time between battery charges that meets consumer expectations.
Clock gating is a commonly used approach to reduce power consumption to an acceptable level
for portable devices such as cellular phones. Typically, gated clocks are implemented either
manually or using a synthesis tool such as Synopsys Power Compiler.
Figure A-1 shows a circuit that implements clock gating. Usually, the clock gating logic is
contained within a clock gating module. Such modules are becoming increasingly available in
technology libraries. They can also be automatically generated by synthesis tools that support
clock gating.
Using Gated Clocks with Scan and Logic BIST
Overview of Designs with Gated Clocks
June 2014
Figure A-1. Synopsys Power Compiler Clock-Gating Module
The logic illustrated in Figure A-1 has these characteristics:
Signal ENL determines if the clock signal CLK passes through the AND gate to the
clocking network. After the negative edge of CLK, the latch opens and passes the logic
value present on the D input to ENL.
In test mode, during scan shift, ENL is forced to a value of 1 by the active-high scan-
enable signal, TE. The TE signal is driven low during the capture cycle.
During capture, the value of ENL depends upon the value of EN. The signal EN is a
functional signal that gates off the clock when it is controlled to a value of 0.
For scan test and logic BIST, EN is treated by the signatureAnalyze tool as a normal
signal. Therefore, the value of EN during logic BIST is driven by a pseudo-random
pattern stream.
Inserting Scan Chain and Gated Clocks
June 2014
This section explains how to implement scan and logic BIST in a design that includes gated
clocks.
Synthesizing With Gated Clocks
When synthesizing your design with the clock gating feature enabled, instruct your synthesis
tool not to connect the TE pin of the clock gating cell to a common root level input pin. Instead
instruct it to leave the TE pin tied off. For example, if you are using Synopsys power compiler,
do not use the hookup_testports command as this command connects all TE terminals to a
single input port with no distinction of the clock domain using them. The scan insertion tool will
take care of connecting them correctly based on their clock domains and their shared isolation
and capture by domain requirements.
Describing Your Clock Gating Cells
To describe your clock gating cells to the tools, you use the following syntax inside the
ICTechnology wrapper of the ETPlanner input files:
ICTechnology (<ICTechnologyName>) {
ClockGatingCell (<moduleName>) {
ClockGatingDisable (<inputPortName>){
Polarity : (ActiveHigh) | ActiveLow;
}
}
}
Note that you can use wildcards with * to specify moduleName in the ClockGatingCell
wrapper. This will instruct the tools to define any module starting with a given prefix as clock
gating cells.
The following example shows a standard definition for a clocking gate if you are using
Synopsys Power Compiler. This example specifies the input port TE of any module instantiated
anywhere in the design and with a module name beginning with SNPS_CLOCK_GATE_HIGH_
as a clock gating disable input.
ClockGatingCell (SNPS_CLOCK_GATE_HIGH_*) {
ClockGatingDisable (TE) {
Polarity: ActiveHigh;
}
}
Once you have described your clock gating cells in the ICTechnology wrapper, either in the
.LVICTech File or in the .etplan File, the lvWorkSpace that you create using ETPlanner will
completely automate the scan insertion process. You do need to do anything else special due to
the presence of the clock gating cells in your circuit. The functional clock enable path will be
tested at-speed in logic BIST and/or ATPG mode.
June 2014
Using Capture-By-Domain Through Clock-Gating
Cells
For your reference, designs with clock-gating cells are also tested using a capture-by-domain
technique when cross-domain paths go through the clock gating cells. In such cases,
captureDisable of the receiving flop is implemented by gating the clockEnable signal of the
clock-gating cell, as shown in Figure A-2. This turns off the clock on the receiving flops when
their corresponding captureDisable signal is high, making them hold their previous value. The
flops can then operate properly as Receive flops, Transmit flops, or both without any additional
changes.
Figure A-2. Capture-By-Domain for Cross-Domain Paths Through Clock-Gating
Cell
June 2014
Appendix B
Re-Using PLL and Functional Clock Dividers
During Embedded Test
This appendix describes when and how PLL and functional clock dividers must be used during
operation modes of embedded test. Special focus is given to at-speed logic testATPG and
logic BIST.
Enabling a PLL During Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Enabling Clock Dividers During Embedded Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Re-Using Functional Divider When Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Local Feedback for PLL Needed During Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Manually Inserting Local Feedback in RTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Inserting Local Feedback with ETAssemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Enabling a PLL During Embedded Test
You should always re-use functional PLLs during embedded test as it allows generating internal
test clocks identically as in functional mode, minimizing the timing requirements of your testers
and providing at-speed in-field test operations.
The first thing you must do when re-using a PLL during embedded test is to have its inputs
controllable from either primary inputs or more likely from the TAP or WTAP controller.
Often, PLLs will have several input pins to configure it, such as pins to select their
multiplication factors or pins to disable them during IDDQ testing. All those signals need to be
precisely controlled during embedded testso that the PLLs behave as required and are not
affected by the random state of the functional logic that exists during test. If this cannot be
guaranteed by simple static asserts on primary inputs, you must intercept all signals with the
ETClockEnable user bit of the TAP or WTAP controller.
You do this during the ETChecker step by declaring each pin to be intercepted as an
lv.ETClockEnable pin. A signal which must be controlled high during embedded test is declared
with polarity 1, and a signal which needs to be controlled low is declared with polarity 0.
Figure B-1 shows the ETChecker properties that are used to control the mult[2:0] pins of the
PLL to value 101 and the PwrDwn pin to value 1. Note that an OR gate is used to control a
signal high, and an AND gate is used to control a signal low.
Re-Using PLL and Functional Clock Dividers During Embedded Test
Enabling a PLL During Embedded Test
June 2014
Figure B-1. Controlling PLL inputs During Embedded Test
Enabling Clock Dividers During Embedded Test
June 2014
Enabling Clock Dividers During Embedded
Test
Caution
Avoid re-using functional clock dividers during test when possible.
Re-using functional clock dividers during embedded test can cause problems and should be
avoided whenever possible.
The only time it is desirable to re-use them is when the functional clock dividers divide the
clock by something other that 2, 4, 8, or 16, or when the functional high-speed clocks and the
divided clocks are skew-balanced and treated as synchronous clocks during functional mode. In
such cases, you need to re-use the functional divider during test to maintain the skew balancing
during test and test them as synchronous clocks.
If the functional clock divider resides on a functional clock tree along with other scan-testable
flip-flops, you cannot re-use the functional divider during test because its clock will not be free
running during logic testingas a Burst Clock controller will be injected at the base of the
functional clock domain to switch between the shift clock and functional clock. Instead, you
will let the functional divider be scan-tested like the rest of the functional flip-flops driven by
the VCO clock, and you will define an lv.InternalClockSource property on the output of the
divider and specify the correct -testClockSource to use with the appropriate value of
-freqRatioRelToSource. This will result in ETAssemble creating a test-only clock divider on a
small dedicated clock domain to generate the divided clock during logic test. It allows you to
avoid any control or reset issues which must be addressed when re-using the functional divider.
Figure B-2 illustrates this case.
Enabling Clock Dividers During Embedded Test
June 2014
Figure B-2. Bypassing a Functional Clock Divider During Test
Re-Using Functional Divider When Required
Just like with PLLs, any configuration inputs on functional clock dividers such as ones used to
control the division ratio must be made controllable during embedded test to avoid the divider
from being affected by the random state of the functional logic which exists during test. Refer to
the previous section for the description on how to use the lv.ETClockEnable property in the
ETChecker step to make them controllable during embedded test.
The more common problem with functional dividers is that they must be reset at the beginning
of the test pattern. Often, this is only a simulation artifact as the divider will properly divide
after power up in real silicon. The simulation artifact still needs to be addressed in order to
complete the simulation part of the embedded test sign-off process.
The resetting of the functional divider is often controlled by a primary input. When it is the case,
you need to specify UserDefinedSequence in the ETVerify configuration file that will toggle the
Local Feedback for PLL Needed During Test
June 2014
appropriate pins. This UserDefinedSequence is then referenced by any test patterns that rely on
the functional clock divider to be operational during test.
If the reset signal is not easily controllable by simple toggling of primary inputs it is best to
make it controllable by a TAP userBit. To do that, you must have a multiplexer inserted into
your RTL that allows taking control of the Reset signal during test. You point to the Select input
pins with lv.ETClockEnable and to the B input of the multiplexer with lv.InjectControl -type
userBitLow. This will insure the Reset signal is directly controlled by a TAP user bit during
embedded test. Your UserDefinedSequence will then simply consist of toggling the user bit on
then back to off.
When a functional clock domain is sourced by a PLL, you will be using its output during at-
speed logic testATPG and logic BIST. The Burst Clock controller gates off the clock during
the shift phase and only allows a burst of clock cycles during the burst phase. If your PLL uses a
leaf of the clock distribution tree as its feedback, you need to provide a local feedback to the
PLL such that it will remain frequency-locked even when the clock is gated at the base of the
clock distribution tree. Make sure your PLL simulation model is precise enough to not generate
a clock if the feedback pin does not correspond to its VCO output. This will allow you to detect
that you have no local feedback and make sure the PLL is usable during manufacturing test.
You provide a local feedback to your PLL using a multiplexer controlled by the ETClockEnable
user bit on the TAP/WTAP controller. This user bit allows enabling of the functional clock
during embedded test. When ETClockEnable is high, the multiplexer must select the local
feedback. If you insert a multiplexer on the reference as well, the presence of the multiplexer on
the feedback is completely removed in terms of phase alignment between the input clock and
the leaf of the clock tree.
For illustration of this case, refer to Figure B-3. Note that the phase alignment is lost between
the leaf of the clock tree and the input clock while ETClockEnable is high. This is not a problem
as there is no interaction between the outside of the chip and the internal clock domains during
the embedded test operations.
Note
The only requirement for the PLL is to remain frequency-locked.
June 2014
Figure B-3. Providing Local Feedback for PLLs
You can insert the local feedback multiplexers in one of the following ways:
Manually Inserting Local Feedback in RTL
Inserting Local Feedback with ETAssemble
Manually Inserting Local Feedback in RTL
You have to be careful with your RTL structure if you choose to insert the local feedback in the
RTL. The connection between the local feedback and the pin on which you define the
lv.InternalClockSource property in ETChecker must not be exactly the same pin. If it is the
same pin, the local feedback connection will end up after the Burst Clock controller once
ETAssemble has inserted it. (The net connected to the defined lv.InternalClockSource pin is
moved by ETAssemble to the output of the Burst Clock controller so the local feedback ends up
being moved with it too.)
To make sure the local feedback remains directly connected to the output of the PLL, you wrap
the PLL in a module that contains only the PLL and the feedback multiplexers. Then you can
safely define lv.InternalClockSource on the wrapper module output port making sure the local
feedback remains before the Burst Clock controller, as illustrated in Figure B-4. To automate
the connection of the Select signal, you use the lv.ETClockEnable property in your .etchecker
file.
In case you failed to specify the lv.ETClockEnable property while running ETChecker, you can
also connect the Select signal during the ETAssemble step using the ET_CLOCK_ENABLE
property in the WTAP/TAP Connections wrapper of the .etassemble file.
June 2014
Figure B-4. Wrapping PLL and Multiplexer in a Module When Implemented in
RTL
Inserting Local Feedback with ETAssemble
To insert the multiplexer with ETAssemble, you define two CustomObject wrappers as shown
in Figure B-5. Make sure you adjust the properties values to properly reflect the multiplexer
module, pin names, and the instance paths to your PLL pins. The multiplexer will be inserted
after the Burst Clock controller is inserted so the local feedback will truly be the VCO output of
the PLL.
June 2014
Figure B-5. Custom Object Syntax to Insert Local Feedback with ETAssemble
CustomObject(Mux2InterceptDestination) {
Var(ModuleName): MU111;
Var(InstanceName): TLB1/PLLFBMux;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(SelectPin): S;
Var(InterceptPort): TLB1/PLL/FB;
Var(Input1Connection): TLB1/PLL/VCO;
Var(SelectConnection): LVISION_JTAP_INST/userBit[#];
// userBit[#] corresponds to the user bit used for ETClockEnable signal.
// Its position is always equal to the specified NumberUserBits value.
}
CustomObject(Mux2InterceptDestination) {
Var(ModuleName): MU111;
Var(InstanceName): TLB1/PLLRefMux;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(SelectPin): S;
Var(InterceptPort): TLB1/PLL/REF;
Var(Input1Connection): TLB1/PLL/REF;
Var(SelectConnection): LVISION_JTAP_INST/userBit[#];
}
June 2014
Appendix C
Logic Test and Memory BIST Clocking on
Chip Examples
This appendix provides five examples of chips to illustrate how the functional clocking is
described to ETChecker and show what clocking circuitry is inserted into the chips to perform
memory BIST and internal and external logic test modes.
The topics of this appendix are as follows:
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Chip Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Chip Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Clocking During External Logic Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Chip Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Clocking During Internal Logic Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Clocking During External Logic Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Physical Regions Without LogicTest Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Clocking When Using Memory BIST Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chip Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Chip Example 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Introduction
This appendix provides the following examples to guide you through the process of describing
clocks for embedded memory BIST (EMT) and embedded logic test (EMT) to ETChecker:
Chip Example 1This example is a chip made of a single physical region. This chip
has 3 clock domains, a PLL, and functional clock divider.
Chip Example 2This example is a chip made of two lower physical regions. This chip
has 3 clock domains, a PLL, and a functional clock divider. The two lower physical
regions are tested as ELT core modules.
Chip Example 3This example is a chip made of top level with two lower physical
regions. The first physical region sources a clock to the second physical region. The
Logic Test and Memory BIST Clocking on Chip Examples
Chip Example 1
June 2014
clock specification is shown for both the top-down and bottom-up design
methodologies. The clocking is also shown when the lower physical regions are tested
as ELT core modules and as block modules. Finally, the same chip is shown when only
memory BIST is used without logic test.
Chip Example 4This example is a chip with a lower physical region that contains
Tessent
SerDes Test macros.

Chip Example 5This example is the same chip as in the previous example, except that
the Tessent SerdesTest macros are in the top-level physical regions instead of within the
ELT core. It shows the clock specification for both the top-down and bottom-up design
methodologies.
Chip Example 1
This first example is a simple chip with three clock domains and is illustrated in Figure C-1. It is
laid out as a single physical region. Two of the clock domains are sourced by a common clock
source:
The CLKA pin is a 10MHz reference to a PLL which multiplies the frequency by a factor
20. The PLL directly drives the clka 200MHz clock domain. A clock divider,
functionally residing on the clka clock domain, divides the clka clock by two and drives
the clkc 100MHz clock domain.
The CLKB pin directly drives the clkb 125MHZ clock domain.
In Figure C-1, you can see how the 3 clock domains are described to ETChecker. The
lv.ClockDomainBase property is used to describe the base of each of them. In the case of CLKB,
even though the clock domain base is defined directly on the primary input of the chip,
ETAssemble will detect the presence of the input pad buffer and will know to intercept the
clock after the input pad buffer. For the internal clock divider, to make sure that the clock can be
defined on a pin of the module, it was described at the RTL level inside a module. This
restriction exists because of SDC. You cannot define clkc on a net or on an RTL register during
synthesis so you must make sure clkc is driven by an output pin of a module containing the
divider.
Notice the two lv.InternalClockSource properties:
The first one is on the PLL output and describes to ETChecker that the internal clock
source is a PLL output multiplying the reference clock pin CLKA by a factor of 20.
The second lv.InternalClockSource is on the internal clock divider. Notice how this one
has the -testClockSource option specified. This is because the clock divider resides on a
scan-testable clock domain, and the divider will be scan-tested with the rest of the logic
on the clka domain. A test-only clock divider will be inserted to divide the clock during
test.
Chip Example 1
June 2014
For complete details on how to deal with PLLs and clock dividers during test, refer to Re-
Using Functional Divider When Required.
Figure C-1. Example 1Functional Clock Domains Described to ETChecker
Figure C-2 shows the clock controllers that are inserted into the chip by ETAssemble. One
Burst Clock controller, labelled BCC in the figure, is inserted per clock source. Two standard
BCCs are inserted to control both clka and clkb while a DIV2 BCC is added to control clkc.
During logic test, the functional clock divider is not used as the clock source but instead is scan-
tested like the rest of the flip-flops on clka. A dedicated divider is included into the DIV2 BCC
to perform the clock division during test. Notice how the clock source to the DIV2 BCC could
not connect before the standard BCC. This is to make sure that it has a free running clock input
during logic test. It could not connect after BCC because the output of BCCs are not free
running clocks.
All clock interceptions are performed at the base of the clock trees. Clock tree synthesis must be
performed on the output of the BCCs. The balance clock networks are identified in bold in
Figure C-2.
Chip Example 2
June 2014
Figure C-2. Example 1Clocking During LogicTest Mode
Chip Example 2
The second example chip, illustrated in Figure C-3, has the same clocks as in Chip Example 1,
except for the two portions of the chip that are laid out as separate physical regions. Note that
the clocks are described exactly in the same way to ETChecker. The clock domain clka spans
two physical regionsthe top-level one and Core1. The clock domain clkb spans all three
physical regions. Flip-flops on clka in the top physical regions are capable of interacting with
flip-flops on clka inside Core1 in a synchronous manner. The clock trees which will be created
by the clock tree synthesis process are illustrated in Figure C-4.
Chip Example 2
June 2014
Figure C-3. Example 2Clocks Described to ETChecker
This chip example shows how the clocks are controlled during the internal test of the two cores,
and how the synchronous behaviors of the entire clka and clkb networks are respected during
the external test of the cores within the top level.
Chip Example 2
June 2014
Figure C-4. Example 2Functional Clock Domains After Clock Tree Synthesis
Clocking During Internal Logic Test Mode
Figure C-5 shows the BCCs inserted into the circuit by ETAssemble. The two separate physical
regions are referred to as ELTCoreModules in ETChecker. A set of BCCs is inserted in each
ELT core module, and they are only used during their internal test modes. Again, the BCCs
intercept the clock at the base of the clock domains within each physical region. The greyed out
BCCs in the top physical regions are not involved with the internal test modes of the ELT core
modules. They are left inactive, and the clocks are simply let to go through just like they do
during the functional mode. Notice how the DIV2 BCC in Core1 has a bypass multiplexer
controlled by extTM. This is because it controls a domain with an internal clock source. An
external clock source will be injected on the test clock input to supply the clkc domain with a
clock during external test mode. Refer to Chip Example 4 to see how a local clock domain
inside an ELT core module with no interaction with the outside is simply ignored during
external test modes.
Chip Example 2
June 2014
Figure C-5. Example 2Clocking During Internal Logic Test Mode
Clocking During External Logic Test Mode
Figure C-6 shows the clocking during the external logic test modes. The BCCs on clka and clkb
inside the ELT core modules are disabled, and the clocks simply go through them just like
during the functional mode. A single BCC is inserted at the base of clkb in the top physical
region to drive it during logic test mode. The clock tree for clkb in external mode is restored to
its functional configuration. The paths between B, B, and B remain balanced in test mode just
like they are in functional mode and are tested as synchronous paths.
In this example, a DIV2 BCC is instantiated in the top level to drive the clkc domain during the
top-level logic test modes. It might seem redundant with the one inside Core1 but there are
many control signals between the logicTest controller and the BCCs. To avoid having to route
signals through the physical region boundaries, dedicated BCCs are added at each level.
Typically in a real chip, there is more than one ELT core module with a test clock input so the
top-level DIV2 BCC would most likely end up being shared by many ELT core modules.
Chip Example 3
June 2014
Figure C-6. Example 2Clocking During External Logic Test Mode
Chip Example 3
This example illustrates a special clocking scenario where one ELT core module sources the
clock to another ELT core module. The same example is used in the later part of this section to
outline the clock specification process when the bottom-up design method is used.
Figure C-7 illustrates a circuit with two physical regions. A clock generated within Core1 is
used as the clock input to Core2. The clkb is used to drive flip-flops in both Core1 and Core2.
The data communication between B and B is one-way and only goes from B to B.
When Core1 is being tested with its internal test mode, the clkb output clock port no longer
sources a free running clock. It will switch between the shift clock and a burst of functional
clock pulses. This makes the clkb input port for Core2 unusable during internal test. Special
restrictions would need to be imposed and rule-checked to prevent Core2 to be run in parallel
with Core1. These restrictions are hard to manage and can have huge impact on test time when
many of such cores are present within a chip. To avoid this problem, the clkb clock domain is
driven by an alternate clock source during the internal test. This is simply specified using the
lv.ELTCoreClockInput property, and specifying an alternate clock source for it is to be used
during internal logic test mode.
Chip Example 3
June 2014
Figure C-7. Example 3Functional Clock Domains Described to ETChecker
Clocking During Internal Logic Test
Figure C-8 shows the BCCs and clock multiplexers added in the circuit. Notice how a test clock
input is created on Core2 and used during both internal and external logic test mode. The test
clock input drives both a DIV2 and a DIV4 BCC. The test clock pin is directly driven by the PLL
Chip Example 3
June 2014
output, and, thus, is a free-running 200Mhz clock. The DIV2 BCC generates the 100MHz clock
for clkb, and the DIV4 BCC generates the 50MHz clock for clkc. The functional clock input pin
clkb on Core2 is not used during internal logic test mode so there is no restriction for running
Core1 and Core2 in parallel.
Figure C-8. Example 3Clocking During Internal Logic Test
Clocking During External Logic Test
Figure C-9 shows the clocking during external logic test mode. Notice how the real functional
source for clkb in Core2 is used during external test mode, thus, restoring the functional clock
alignment between B and B. This functional clock alignment is important as it allows testing of
the paths between B and B under the true functional synchronous behavior. Again, just like in
Chip Example 2, BCCs inside an ELT core are never reused during external test. Dedicated
BCCs at the top level are added to generate the burst clocks during the top-level logic test
modes. In a real circuit, you would have more than one test clock input with the same
frequency, so the top-level BCCs would be shared between them.
Chip Example 3
June 2014
Figure C-9. Example 3Clocking During External Logic Test
Using the Bottom-Up Test Insertion Method
It is very common to have lower physical regions ready for test insertion before the top level is
actually ready. For this reason, many designers choose to perform the embedded test insertion
using the bottom-up design methodology. In this method, the designers run ETChecker on each
ELT core separately. Figure C-10 illustrates how the clocks would be specified to ETChecker
when running on the two cores separately.
You can see that when running ETChecker on Core2, it is missing the context information that
lets it know that the clkb input pin is actually driven by Core1 in the top level. You must know
this information up front and specify the lv.ELTCoreClockInput property on the clkb input pin.
If you do not do that then you will need to inject a multiplexer on the clock net between Core1
and Core2 and control it with ETClockEnable. This will have the negative impact that paths
between Core 1 and Core2 on the clkb clock domain will not be able to be tested as synchronous
paths. This is why you should use the top-down design method when ever possible, and when
you cannot, you must make sure to find out the source of the clocks at the next level up before
choosing to use it during the internal test of the cores.
Notice that the TestClockSource for the ELTCoreClockInput pin is specified as pin ckbt which
might or might not already exist on the Core2. If it does not exist, it will be created by
Chip Example 3
June 2014
ETAssemble. You will later on, during the top rules checking, specify how to connect ckbt in
the top level. In this example, because we know there will only be a 200MHz clock available at
the top, and we need a 100MHz clock to drive clkb, we specified -freqRatioRelToSource of 0.5
to have a DIV2 BCC inserted.
Figure C-10. Example 3Clocks at the Core Level Described to ETChecker
You can see the inserted BCCs inside the two ELT cores in Figure C-11. On the other hand,
Figure C-12 shows you what is seen by ETChecker when running on the top level in the
presence of the ET-inserted cores, and how the clocks are specified. Notice how the
lv.InternalClockSource properties that used to be specified inside the ELT core modules are
gone and are replaced by two lv.TestClockInput properties. Because ETChecker now runs on
the ET-inserted views of the ELT core module, ETChecker now recognizes the already inserted
clock bypass multiplexer and detects that they are driven by primary inputs of the cores. The
clockInfo mode automatically infers the lv.TestClockInput property for you to edit.
You then simply specify the proper source to be used by each of them in order that the correct
frequencies are injected on them during external test. When the clocks are specified as shown in
Figure C-12, the external clocking mode will be identical to what was shown in Figure C-9.
Chip Example 3
June 2014
Figure C-11. Example 3Clocking During Internal Logic Test at the ELT Core
Level
Chip Example 3
June 2014
Figure C-12. Example 3Clocks at Top Level with ET-Inserted ELT Cores in
ETChecker
Chip Example 3
June 2014
Physical Regions Without LogicTest Controller
Figure C-13 shows Chip Example 3 when the lower physical regions are not to be equipped
with a dedicated logicTest controller but instead tested by the top-level logicTest controller. We
refer to such physical regions as block modules instead of ELT core modules. Inside a block, we
never insert BCCs. Instead, we only insert clock multiplexers to make sure all clock sources are
controllable by primary inputs of the block modules. The test is not in a block module. All logic
inside the block is visible to the top-level logicTest controller. The disadvantage of it is that the
number of scan chains which must come in and out of the physical regions is much larger as
compared to an ELT core. However, it is very applicable to small physical regions. Notice that a
block module will have a WTAP controller only if it has memory BIST controllers in it. In
Figure C-13, Block1 has a WTAP and Core2 does not. The control signals in Core2 are
connected to the top-level TAP controller.
Figure C-13. Example 3Clocking When Physical Regions are Blocks
Clocking When Using Memory BIST Only
Figure C-14 shows Chip Example 3 when only memory BIST is usedwithout logic test. This
would be specified in ETChecker as follows:
lv.EmbeddedTest -logic Off -memory On
Chip Example 3
June 2014
You can see in Figure C-14 that no BCCs are inserted. Instead, only a 2-to-1 multiplexer is
inserted on each clock source to allow injecting TCK at the base of the clock domain. TCK
clock source is mandatory to perform CompStat diagnostic and serves as a backup clock in case
a functional clock is not available during test to run memory BIST. Notice that the
lv.InternalClockSource properties do not use the -testClockSource option as this is only
relevant for logic test modes. The example assumes that there are memories on all clock
domains. Clock domains with no memories do not need to be declared nor multiplexed with
TCK. Refer to Figure C-15 to see the TCK multiplexer injected.
Figure C-14. Example 3Clocks Described to ETChecker Using Memory BIST
Only
Chip Example 4
June 2014
Figure C-15. Example 3Clock Muxing When Using Memory BIST Only
Chip Example 4
This example is used to illustrate a common scenario in telecommunication chips. The interface
to many small clock domains is through Tessent SerdesTest macros where high-speed serial
data bits are serialized or deserialized inside the core. The Tessent SerdesTest macros are
generally not scan-testable and are tested using other means.
You declare the Tessent SerdesTest macros as a blackbox module in ETChecker. Figure C-16
shows how the clocks are described to ETChecker. The clocks coming out of the Deserializer
are generally not reliable during logic test because they are recovered clocks from the data
stream which is not available during logic test. This is why the lv.InternalClockSource
properties specified on the DES macros have the -testClockSource option to inject a reliable
clock on them during logic test.
Figure C-17 shows the BCCs that are inserted inside Core1. Notice how the RX clocks are only
intercepted during internal test mode. This is because the RX domains do not interact with the
outside logic. They are isolated by the DES macros. To complement the logic test, a BIST for
the DES macro should overlap the scan-testable logic to cover the paths between the DES
macro and the scan-testable logic on the RX clock domains. Figure C-18 shows the clocking
during external logic test mode. Both RX clock domains are fully hidden during this mode.
Chip Example 4
June 2014
Figure C-16. Example 4Clocks with SerdesTest Macros Described to
ETChecker
Chip Example 4
June 2014
Figure C-17. Example 4Clocking During Internal Test Modes
Figure C-18. Example 4Clocking During External Logic Test Mode
Chip Example 5
June 2014
Chip Example 5
This example chip is identical to the previous oneChip Example 4except that the Tessent
SerdesTest macros are in the top-level physical regions instead of within the ELT core. This
example illustrates the fact that the RX domain can also be forced to only be tested during
internal test and hidden during the external test. There is no point in including the periphery
flip-flops on the RX domains in the external test when there is no scan-testable flip-flops to
interact with at the top level. When running ETChecker using the top-down design method,
ETChecker will detect that the input pins feeding the RX clock domains are not scan-testable
and will not sample them during the external test. Figure C-19 shows how the clocks are
described to ETChecker. Notice the lv.ELTCoreClockInput properties on the two RX clocks.
This is because we do not want to rely on these clocks during logic test so an alternate clock
source is specified for them.
Chip Example 5
June 2014
Figure C-19. Example 5Clocks with SerdesTest Macros Described to
ETChecker
Using the Bottom-Up Test Insertion Method
When running ETChecker on Core1 by itself, ETChecker cannot obtain information that the
input pins of the RX clock domains will not be scan-testable at the next level up. By default, the
periphery flip-flops on the RX clock domains will be stitched into periphery scan chains and
used during the external test of Core1. You would get scan rule violations at the top because the
periphery flip-flops in Core1 would be capturing the unknown values from the DES macros,
and those violations would need to be fixed with the lv.InjectControl properties.
Chip Example 5
June 2014
If you know that the inputs are not scan-controllable at the next level up, you simply declare the
pins as non-scan-testable using the lv.NonScanTestablePin property. Also, if you know the
clock input is not a reliable clock source, such as when you know it is coming from a DES
macro, then you specify an alternate clock source using the
-testClockSource option of the lv.ELTCoreClockInput property. This way, the ETChecker will
be notified that the RX clock domains are not needed during the external test modes and will
optimize the test logic for the internal test modes only.
Figure C-20. Example 5Clocks/NS Pins Described to ETChecker
June 2014
Appendix D
Fault Coverage
This appendix explains fault coverage considerations when using logic BIST and ATPG
patterns. It provides detailed information on fault coverage achieved using Mentor Graphics
Logic BIST, as well as runtime options for customizing your fault coverage reports and
examples of the ETVerify ouput files that include fault coverage information.
Measuring Fault Coverage With Ndetect Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Using Ndetect Fault Coverage As a Quality Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Reviewing Fault Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Fault Classification Report in the rulea.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Stuck-At Fault Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Stuck-At Fault in Unused Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Stuck-At in Faults External Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Fault Classification Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Title Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Vector Set Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Scan-Testable Fault Classification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Non Scan-Testable Fault Classification Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Total Number of Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
At-Speed Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Example of Chip-Level Fault Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Runtime Options for Creating Fault Coverage Reports . . . . . . . . . . . . . . . . . . . . . . 227
Special ETVerify Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Undetected Fault List .ufl_all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Aborted Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Redundant Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Unpruned Fault List .scanTestableFaultList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Fault Classification Differences between Tessent FastScan and signatureAnalyze 234
Stuck-at Fault Classification Difference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Transition Fault Classification Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Fault Coverage
Measuring Fault Coverage With Ndetect Values
June 2014
Measuring Fault Coverage With Ndetect
Values
The ndetect metric is the number of times a fault is detected by a test set. The quality of a test
that targets stuck-at faults is measured by calculating the fault coverage, which is the ratio of
detected faults to the total number of faults. Typically, the fault coverage metric does not
distinguish whether a fault is detected a few times or a large number of times by the test set
applied. In this case, it is a metric that uses an NDetect value of 1a fault is considered covered
as long as it is detected at least once.
You can instruct the ETVerify tool to compute fault coverage matrix for NDetect values greater
than 1. For example, ETVerify can calculate the fault coverage for an NDetect value of 10 as the
ratio of the number of faults detected at least 10 times to the total number of faults.
Using Ndetect Fault Coverage As a Quality Metric
Research has shown that NDetect fault coverage is a very good metric to determine the ability of
a test to detect defects that do not behave as stuck-at faults. Often, these faults are referred to as
unmodeled defects. Research data shows that for two sets that have the same stuck-at fault
coverage, the test set with the higher NDetect fault coverage covers a larger number of
unmodeled defects and results in a lower defects per million (DPM) rate.
To instruct ETVerify to measure fault coverage using the NDetect feature, specify the NDetect
value in the LogicTestVectors wrapper of the ETVerify configuration file. Figure D-1 illustrates
an example of this wrapper.
When you set NDetect to a value greater than 1, ETVerify stores a histogram with fault
coverage for all values of NDetect between 1 and the value you specified in the ETVerify
configuration file in the <designName>.log_signature_<mode> file in the LV_WORKDIR
directory. The NDetect data is also made available to the lvFaultCoverageReport tool. Examples
of histograms for deterministic ATPG and BIST patterns follow Figure D-1.
Fault Coverage
Reviewing Fault Coverage
June 2014
Figure D-1. Example of LogicTestVectors Wrapper in ETVerify Configuration
File
LogicTestVectors {//Internal scan of fifo_ic_COLLAR
DeterministicATPG {
TargetFaultCoverage: 100;
FaultList: FullSet;
NumberVectors: All;
CompactionLevel: 1 | 2 | 3 | (4);
NDetect: 1;
}
LogicBist {
NumberVectors: HWDefault;
StoredDiagnosticVectors: 1024;
TransitionFault: Off;
NDetect: 15;
}
PrepareFlow {//External scan of fifo_ic_COLLAR
NumberRandomVectors: Auto;
NDetect: 1;
TransitionFault: Off;
}
}
Reviewing Fault Coverage
Once you have run ETVerify to create the logic BIST signatures and scan test vectors, you
should review the final fault coverage achieved.
Both the ruleAnalyze tool run in the previous step and the ETVerify run (which runs
signatureAnalyze as a sub-process) in the current step, generate a list of faults in the circuit to be
analyzed and then proceed to classify their status for each of the test modes analyzed.
The information to be reviewed is found in the .log file for the ruleAnalyze run in Step 4:
ETScan and Pre-Layout ETSignOff. For details on make targets you can use in this step to
obtain fault coverage information, refer to Make Targets for ETScan and Make Targets for Pre-
Layout ETSignOff.
Fault Classification Report in the rulea.log File
The ruleAnalyze tool reports fault classification in these sections of the log file:
Stuck-At Fault Coverage Data
Stuck-At Fault in Unused Logic
Stuck-At in Faults External Logic
Figure D-2 illustrates the sections of the fault coverage report in the rulea.log file. Descriptions
of the report follow the figure.
Fault Coverage
June 2014
For an example of the report, refer to Special ETVerify Output Files.
Figure D-2. Fault Coverage Report in the rulea.log File
Stuck-At Fault Coverage Data (LogicBist mode):
Total number of stuck-at faults : 11080
COVERED FAULTS)
Pruned redundant tied faults : 37/11080 ( 0.33%)
Pruned potentially detected tied faults : 36/11080 ( 0.32%)
Pruned potentially detected testmode faults : 0/11080 ( 0.00%)
Pruned implicitly detected faults : 4449/11080 (40.15%)
Pruned implicitly detected clock faults : 570/11080 ( 5.14%)
Pruned implicitly detected set/reset faults : 0/11080 ( 0.00%)
----------------------------------------------------------------------
--
(UNCOVERED FAULTS)
Pruned undetected faults : 164/11080 ( 1.48%)
----------------------------------------------------------------------
--
Faults signatureAnalyze will classify : 5824/11080 (52.56%)
Stuck-At Faults in unused logic (LogicBist mode) :
Number of unused faults : 833
Number of blocked faults : 134
Stuck-At Faults in external logic (LogicBist mode) :
Number of external faults : 1788
Note
Similar sections exist in the .rulea.log file for single-chain and multi-chain modes.
Fault Coverage
June 2014
Stuck-At Fault Coverage Data
The Stuck-At Fault Coverage Data section of the report contains four sections:
Total Fault Coverage
Covered Faults
Uncovered Faults
Remaining Faults Classified by signatureAnalyze
These fault types are explained in this sub-section.
A list of the pruned faults as well as a list of the unpruned faults can be obtained from
ruleAnalyze by using the -writeFaultListFiles runtime option. The pruned faults are classified
by ruleAnalyze and printed in file
LV_WORKDIR/<designName>.nonscanTestableFaultlist
All pruned faults are pruned from the view of the circuit that is forwarded to ETVerify to be
analyzed. The faults are pruned from the circuit to reduce the fault set and circuit size
signatureAnalyze needs to handle.
The unpruned faults, that is, the faults that will be classified by signatureAnalyze, are printed in
the following file:
LV_WORKDIR/<designName>.scanTestableFaultlist
The ruleAnalyze tool gives the unpruned faults an initial classification undetected (UD), but
these classifications will be updated by signatureAnalyze when ETVerify is run.
Besides these two optional fault list files, ruleAnalyze always generates a list of the uncovered
faults:
LV_WORKDIR/<designName>.nonscanTestableUntestedFaultlist
The fault list files have the same format. Figure D-3 provides an example of a fault list file. The
file has a header of 30 lines. The header shows which faults are listed in the file (For example,
pruned, unpruned, or untested). The header contains a legend of the fault classification codes.
These include all classification codes that ruleAnalyze and/or signatureAnalyze might use.
Listed below are the descriptions of the four sections in which faults are reported in the
.rulea.log file. Each type of fault has a unique classification code which is used when the fault is
listed in a fault list file.
Fault Coverage
June 2014
Figure D-3. Example of a Fault List File
Fault Coverage
June 2014
Total Fault Coverage
The Total Fault Coverage section reported in the .rulea.log file is as follows:
Total number of stuck-at faults
This is the total number of faults analyzed.
Covered Faults
The Covered Faults section includes the following:
Pruned redundant tied faults
Classification code: TI
These are faults on nets that have a constant value due to the propagation of circuit or
gate inputs tied to a circuit power supply (such as Vdd or Vss) either directly or through
an appropriate tie-off cell of your cell library. For example, if a net has a constant value
of logic 1, then a stuck-at-one fault on the net is redundant. These faults are truly
redundant since the value on this net cannot be changed in any test or functional modes
of operation of the circuit. These faults do not affect the function of the circuit.
Figure D-4 illustrates some pruned redundant tied faults.
Figure D-4. Pruned Redundant Tied Faults Example
Pruned potentially detected tied faults
Classification code: PT
These faults are also related to nets that have a constant value due to the propagation of
inputs tied to a supply. In this case, however, the fault of interest is the one where the net
is stuck at the opposite value than the constant value propagated in a non-faulty circuit.
For example, if a net has a constant value of logic 1 and this net is the input of an AND
gate, the stuck-at-zero fault is detected by detecting the stuck-at-zero fault of the AND
gate output. The ETVerify tool detects these faults in the single-chain and multi-chain
Fault Coverage
June 2014
configurations when the -deterministic option is set to On. However, ETVerify does not
detect these faults if they are redundant. The probability of detecting the fault in the
logic BIST configuration is the same as the fault coverage for that configuration.
Figure D-5 illustrates some pruned potentially detected tied faults.
Figure D-5. Pruned Potentially Detected Tied Faults
Pruned potentially detected testmode faults
Classification code: PM
These faults are similar to the pruned potentially detected-tied faultsexcept that the
constant values are due to the propagation of inputs connected to a test mode signal
(such as LV_TM) or other asserts specified in your .rulea file.
Figure D-6 illustrates a pruned potentially detected testmode fault.
Figure D-6. Pruned Potentially Detected Testmode Faults Example
Pruned assumed tested faults
Classification code: IT
These are faults that are covered by complementary tests such as memory BIST tests or
TAP and boundary-scan tests.
Fault Coverage
June 2014
Several faults at the boundary of the scannable portion of the circuit are assumed tested
by other Mentor Graphics tests. For example, custom memory outputs tested using
memory BIST are pruned from the circuit due to the action of a test mode signal, but
they are assumed tested when memory BIST is applied. Another important example are
faults on input and output pads that are pruned from the circuit due to the action of
boundary-scan control signals of the TAP set to constant values. These faults are
detected in a separate test.
In addition, faults inside the logic BIST controllers are also classified as assumed tested.
These faults are tested functionally during the application of the logic BIST test. The
vectors generated in controllerChain mode ensure that even the last fault inside the logic
BIST controllers is explicitly tested.
Pruned implicitly detected clock faults
Note
Exception: gated clocks branches are explicitly tested.
Classification code: IC
These are faults on the clock tree including branches connected to clock input ports of
flip-flops. These faults are also easily detected during the execution of the three test
modes (single-chain, multi-chain, and logic BIST). Therefore, they are implicitly
detected and pruned from the circuit.
Pruned implicitly detected set/reset faults
Classification code: IR
These are faults on nets connected to the asynchronous set/reset inputs of flip-flops. The
stuck-at-active (e.g. stuck-at-0 for an active low asynchronous set/reset input) faults are
always implicitly detected as they have a catastrophic effect on any of the scan tests. The
stuck-at inactive (E.g., stuck-at-1 for an active low input) faults are also implicitly
detected by the scan chain integrity test if the asynchronous set/reset test is not
constrained to a constant value. If constrained, the faults are put in the Pruned redundant
tied and in the Pruned undetected fault category depending on the nature of the
constraint.
Uncovered Faults
The Uncovered Faults section includes the following item:
Pruned undetected faults
Classification code: UT
Fault Coverage
June 2014
These are faults that are untestable due to the propagation of constant values (or
constraints) applied to the circuit. For example, if a test mode input is constrained to
logic 1 and it propagates to any input of an OR gate, then the faults on the other inputs of
the OR gate become unobservable and therefore undetected. Furthermore, the stuck-at-
one fault on the output of the OR gate is also undetected.
Figure D-7 illustrates some pruned undetected faults.
Figure D-7. Pruned Untested Faults Example
Remaining Faults Classified by signatureAnalyze
The remaining faults cannot be classified by ruleAnalyze:
Faults signatureAnalyze will classify
Classification code: UD
These are faults that are forwarded to ETVerify for classification by the
signatureAnalyze tool.
Stuck-At Fault in Unused Logic
In the Stuck-At Faults in Unused Logic section, the report lists the following items:
Number of unused faults
Classification code: UU
These faults are unobservable because there is no structural path to a scan-tested flip-
flop or a primary output. Usually, this is due to unconnected gate outputssuch as the
unconnected Q output of a flip-flop.
Number of blocked faults
Classification code: BL
Fault Coverage
June 2014
These faults are unobservable in all test and functional modes due to the propagation of
supply signals to gate inputs. Figure D-8 illustrates this case.
Figure D-8. Blocked Faults Example
Stuck-At in Faults External Logic
In the Stuck-At Faults in External Logic section, the report lists the following item:
Number of external faults
Classification code: UX
When using shared isolation in a circuit implementing test methodology, this is the total
number of faults located within the external logic of the circuit, which can potentially be
tested in the next level up in the hierarchy. These faults are excluded from the total
number of stuck-at faults. However, these faults are classified when analyzing the circuit
at the next level up in the hierarchy.
Fault Coverage
Fault Classification Reports
June 2014
A fault coverage report for a circuit is generated when the make target make
display_fault_coverage is executed in the ETScan or ETSignOff steps of the LV Flow. For
information on make targets, refer to Step 4: ETScan and Pre-Layout ETSignOff. This make
target runs the lvFaultCoverageReport tool which generates the report using the fault coverage
data that is generated by the ETVerify tool that runs signatureAnalyze as a sub-process within
it.
The lvFaultCoverageReport tool consolidates the data that is available in the
<moduleName>.ifc files and generates a cumulative fault coverage report for the top level and
ELTs together. By default, the combined logic BIST plus top-up scan vector coverage is
reported. Optionally, the logic BIST only coverage can be displayed and/or the coverage of the
top level only.
The <moduleName>.ifc file, which is generated by signatureAnalyze, contains the pertinent
fault coverage data that is generated by ruleAnalyze and signatureAnalyze. First, this file is
placed in the LV_WORKDIR directory and later copied to the LVDB. A <moduleName>.ifc file
contains stuck-at fault coverage information for both logic BIST and (deterministic) scan
vectors. The file might also contain transition fault coverage and NDetect coverage data in case
that was generated by signatureAnalyze. Some of the fault coverage data in a
<moduleName>.ifc file has been generated by ruleAnalyze and has been forwarded by
signatureAnalyze without change.
The fault coverage that lvFaultCoverageReport reports is based on the original netlist including
the testable gates that are pruned by ruleAnalyze. The pruned testable gates can be the gates on
the clock tree and gates on the asynchronous set/reset tree.
Figure D-9 illustrates the fault coverage report.
For additional examples of fault coverage reports, refer to Special ETVerify Output Files.
Fault Coverage
June 2014
Figure D-9. Fault Coverage Report of a Top-Level Module with Two ELTs
Report created by : lvFaultCoverageReport Version 7.0
Created on : 11/05/08 14:24:18
For reference information see file: ./lvFaultCoverageReport.README
AT-SPEED UNCOLLAPSED FAULT COVERAGE REPORT ---- module : car
Including ELTs : dashboard, engine
----------------------------------------------------------------------
VECTOR SET:
Logic BIST vectors
car : 300
dashboard : 300
engine : 300
Deterministic Top-Up vectors
car (not compressed) : 11
dashboard (not compressed) : 190
engine (not compressed) : 98
SCAN-TESTABLE FAULT CLASSIFICATION:
Detected by vector set : 22329
Logically Redundant faults : 161
Aborted Faults : 4
Total number of scan-testable faults : 22494
AT-SPEED COVERAGE OF SCAN-TESTABLE FAULTS:
Stuck-At (N-detect= 1) fault coverage : 99.98 %
NON SCAN-TESTABLE FAULT CLASSIFICATION:
Redundant Tied Logic Faults : 93
Potentially Detected Tied Faults : 40
Potentially Detected Testmode Faults : 432
Implicitly Detected Faults : 23342
Implicitly Detected Clock Faults : 3023
Implicitly Detected Set/Reset Faults : 1043
Untested Faults : 551
Total number of faults : 51018
AT-SPEED TEST COVERAGE : 98.91 %
----------------------------------------------------------------------
Fault Coverage
June 2014
After generating the fault coverage report a copy of the lvFaultCoverageReport.README file
is placed in the output directory. This README file explains in detail the contents of the fault
coverage report, similar to the explanation in the following sections:
Title Section
Vector Set Section
Scan-Testable Fault Classification Section
Scan-Testable Fault Coverage Section
Non Scan-Testable Fault Classification Section
Total Number of Faults
At-Speed Test Coverage
Warning Messages
Title Section
This section of the fault coverage report includes the main title line and two optional lines:
The top-level module name is printed at the end of the main title line. The following
example title line reports the top-level name car:
AT-SPEED FAULT COVERAGE REPORT ---- module: car
The second title line lists the names of the ELT sub-blocks of the top-level module. This
line is present by default when the fault coverage of the ELTs is included in the
cumulative fault coverage report. When the option -includeELTs Off is used then the
second title line is not printed, and only the fault coverage of the top-level module is
reported. Following is an example of a second title line that lists the ELT sub-blocks
dashboard and engine:
Including ELTs : dashboard, engine
The third title line is only present when the option -lbistOnly On is used:
Pure Logic BIST coverage
For details on runtime options mentioned above, refer to Runtime Options for Creating Fault
Coverage Reports.
Fault Coverage
June 2014
Vector Set Section
The line VECTOR SET: starts the vector set section that has two sub-sections:
Logic BIST vectors
This section specifies for each module how many BIST vectors have been generated.
This sub-section has one line for the top level and one line for each ELT. The following
example shows the number of logic BIST vectors that have been generated for top-level
car and for ELTs dashboard and engine. Note that the report title shows which module
is the top-level module and which modules are the ELTs):
Logic BIST vectors
car :1920
dashboard:15360
engine :7680
This section is optional and is not generated when the
-lbistOnly On option is used (For details on this option, refer to Runtime Options for
Creating Fault Coverage Reports). This sub-section specifies the number of top-up scan
vectors that have been generated for each module. It also shows whether the vectors are
normal scan vectors (not compressed) or seeds generated with the ATPG
Compression capability (compressed). The following example shows that 6 top-up
scan vectors have been generated for top-level car, 717 scan vectors for ELT dashboard
and 468 compressed vectors or seeds for ELT engine:
car (not compressed): 6
dashboard (not compressed):717
engine (compressed):468
Scan-Testable Fault Classification Section
The line SCAN-TESTABLE FAULT CLASSIFICATION: starts the Scan-Testable Fault
Classification section. Scan-testable faults are the faults for which logic BIST and/or scan
vectors are generated by ETVerify. Scan-testable faults are classified by ETVerify. This section
first lists the 2 or 3 classes of covered faults, then 3 classes of uncovered faults, and, finally, the
total number of scan-testable faults. In the report, each class of faults is reported on a separate
line. The number of faults in the class is printed at the end of the line.
Three classes of covered scan-testable faults might be reported:
A Detected by Vector Set
These are faults that are definitely detected by the logic BIST vectors and/or
deterministic scan vectors. A fault can be detected with certainty if, for at least one
Fault Coverage
June 2014
pattern, the Stuck-At-0 or Stuck-At-1 value causes a difference between the expected
output value and the value observed.
B Logically Redundant Faults
These are faults in the presence of which the function of the circuit remains unchanged
as identified by the Deterministic ATPG. Therefore, they cannot be detected.
C Potentially Detected Tristate Enable Faults
These are faults that are potentially detected by the logic BIST vectors and/or
deterministic scan vectors. Potential detections might happen when tristate drivers are
used in a design. A potential detection takes place when on an observable node, the
fault-free circuit has a known logic value, and the logic value of the faulty circuit is
unknown. In practice, these faults can be considered detected in logic BIST because the
large majority of the faults are detected multiple times and the probability of the
unknown values of the faulty circuit to always match the ones of the fault-free circuit is
negligible.
This class is not reported if there are no potentially detected faults, meaning, if there are
no tristate busses in the circuit.
Up to three classes of uncovered scan-testable faults might be reported:
D Undetected (logic BIST) Faults
These are faults that are not detected by the logic BIST vectors. If the Stuck-At-0 or
Stuck-At-1 fault at this gate input or output port was not detected by any vector, this
fault is called an undetected fault. These faults can be detected by a complementary scan
test (such as single or multi mode).
This category is only reported when the option -lbistOnly On is used and at least one
fault falls into this category.
E Untestable Enable Faults
These are faults on enable nets (or logic driving enable nets) of tristate drivers that have
not been potentially detected. The faults cannot be solidly detected because in their
presence, the faulty value on the tristate gate is unknown.
This class is not reported if there are no untestable enable faults, meaning, if there are no
tristate busses in the circuit.
F Aborted Faults
These are faults for which the Deterministic ATPG could not generate a test or which
could not be proven redundant in a reasonable amount of time. These faults are currently
classified as uncovered. This is somewhat conservative since most aborted faults are
actually redundant. The number of aborted faults can be reduced by increasing the
backtrack limitrefer to the LogicBist wrapper inside the LogicTestVectors wrapper in
Fault Coverage
June 2014
the manual ETVerify Tool Reference. The ETVerify run time will be longer when the
backtrack limit increased.
This category is not reported when the option -lbistOnly On is used. For details on this
option, refer to Runtime Options for Creating Fault Coverage Reports.
G Total Number of Scan-Testable Faults
This is the number of scan-testable stuck-at faults. It includes all scan-testable faults for
the top-level module as well as the ELTs. The total number of faults is the sum of all
preceding fault classes:
G = A + B + C + D + E + F
Scan-Testable Fault Coverage Section
This section, which is entitled AT-SPEED COVERAGE OF SCAN-TESTABLE FAULTS,
reports the coverage of the scan-testable portion of the circuit. This is the combinational logic
that is targeted by logic BIST and/or scan vectors.
The length of this section depends on the availability of transition fault and NDetect coverage
data. If neither of these data is present then only one fault coverage number is reported, namely,
the stuck-at fault coverage (for the default NDetect= 1 value). The reported coverage is the
cumulative coverage for the top-level module plus the ELT sub-blocks.
The scan-testable stuck-at fault coverage is the sum of the faults in all covered scan-testable
fault classes divided by the total number of scan-testable faults:
(A + B + C) / G
If transition fault data is available for all modules then the cumulative transition fault coverage
for the top-level module plus ELTs is reported in addition to the stuck-at coverage. If transition
fault data is missing for one or more modules then the transition fault coverage is not reported.
Instead, a warning is appended to the end of the report saying that transition fault data is missing
for some modules (and listing the modules for which this data is available). The transition fault
coverage is calculated using the same formula as is used for the scan-testable stuck-at fault
coverage. Note, however, that the numbers of transition faults that are definitely or potentially
detected are not available in the fault coverage report.
If NDetect coverage data is available for all modules then the cumulative NDetect stuck-at and
transition fault coverage for the top-level module plus ELTs is reported in addition to the basic
(NDetect= 1) stuck-at and transition coverage. (Note that transition fault coverage is reported
only if transition fault data is available). If NDetect coverage data is missing for one or more
modules then the NDetect coverage is not reported. Instead, a warning is appended to the end of
the report saying that NDetect coverage data is missing for some modules (and listing the
modules for which this data is available). If the NDetect value is not the same for all modules
then the reported NDetect coverage will be for the lowest value of N among the modules. In this
Fault Coverage
June 2014
case, a warning will be appended as well to the report listing the modules for which higher
NDetect data is not available.
The NDetect coverage for N > 1 is calculated using the same formula as for the stuck-at fault
coverage. However, the numbers of faults that are definitely or potentially detected N times are
not available in the fault coverage report.
The following example shows the scan-testable fault coverage for a circuit for which both
transition fault data as well as NDetect coverage data is available for all modules:
Transition (N-detect=18)fault coverage: 75.76%
Transition(N-detect= 1) fault coverage: 95.46%
Stuck-At (N-detect=18)fault coverage: 89.37%
Stuck-At (N-detect= 1)fault coverage: 99.99%
Non Scan-Testable Fault Classification Section
The line NON SCAN-TESTABLE FAULT CLASSIFICATION: starts the non scan-testable
fault classification section. The covered non scan-testable faults are detected by various vector
sets even though often no particular vectors have been generated to test these faults (e.g. faults
on the clock tree). The descriptions of the classes of covered non scan-testable faults below
provide more details on how these faults are detected. Non scan-testable faults are classified by
ruleAnalyze. This section first lists the 6 classes of covered faults, then one class of uncovered
faults. In the report each class of faults is reported on a separate line. The number of faults in the
class is printed at the end of the line.
Six classes of covered non scan-testable faults are reported:
H Redundant Tied Logic Faults
These faults are related to nets that have a constant value due to the propagation of
inputs tied to a supply as explained in Pruned redundant tied faults of the
Covered Faults section.
I Potentially Detected Tied Faults
These faults are also related to nets that have a constant value due to the propagation of
inputs tied to a supply as explained in Pruned potentially detected tied faults of the
J Potentially Detected Testmode Faults
These faults are due to the propagation of inputs connected to a test mode signal (such as
LV_TM) or other asserts specified in your.rulea file as explained in Pruned potentially
detected testmode faults of the Covered Faults section.
Fault Coverage
June 2014
K Implicitly Detected Faults
This is the number of implicitly detected faults located in the pruned section of the logic.
These faults are described in Pruned assumed tested faults of the Covered Faults
section.
L Implicitly Detected Clock Faults
Faults on clock inputs of scan-tested flip-flops as well as faults in the entire clock tree
driving these clock inputs are implicitly detected. These faults are catastrophic and
easily detected as explained in Pruned implicitly detected clock faults of the
M Implicitly Detected Set/Reset faults
These are faults on nets connected to the asynchronous set/reset inputs of flip-flops.
These faults are described in Pruned implicitly detected set/reset faults of the
One class of uncovered non scan-testable faults is reported:
N Undetected Faults
These are faults that are untestable due to the propagation of constant values (or
constraints) applied to the circuit. These fault are described in Uncovered Faults.
Total Number of Faults
Total number of faults is the number of all stuck-at faults in the circuit. It includes all faults for
the top-level module as well as the ELTs. It includes both the scan-testable faults as well as the
non scan-testable faults. The total number of faults is the sum of all preceding fault classes
(including the total number of scan-testable faultsG):
Total number of faults = G + H + I + ... + N
At-Speed Test Coverage
The line AT-SPEED TEST COVERAGE: shows the cumulative test coverage for the top-
level module plus ELT sub-blocks. This is the coverage for the whole circuit including scan-
testable faults as well as non scan-testable faults.
The test coverage is the sum of faults in all covered fault classes divided by the total number of
faults:
(A + B + C + H + I + J + K + L + M) / Total number of faults
Fault Coverage
June 2014
Warning Messages
There might be some aspects in the fault coverage report or the underlying data that might
require your special attention. In such case, one or more warning messages will be appended to
the report. Examples are the availability of data that could not be adequately represented in the
report (Refer to Scan-Testable Fault Coverage Section above). If this happens you might want
to consider rerunning ETVerify for some modules with the necessary additional options to
generate the missing data.
The lvFaultCoverageReport tool performs a simple analysis on the data to identify any coverage
anomalies. The tool will warn you if the number of redundant faults for some module is higher
than normal, or if the fault coverage for a module is on the low side. In the latter case, the tool
will attend you to the fact that the logic BIST coverage could be improved by increasing the
number of vectors if such is the case, or that the coverage could be improved by adding top-
up vectorsin case, they are missing.
The following is an example of an information message saying that the fault coverage for ELT
dashboard is on the low side:
Info: The number of detected SCAN-TESTABLE faults (9549) for ELT module
dashboard is less than 99% of the total (9696)
* Increasing the number of logic BIST vectors for ELT module dashboard
probably helps to improve the coverage. Currently the number of vectors is
300. A number of 100,000 is recommended.
Figure D-10 shows a fault coverage report that includes transition and NDetect coverage as well
as most of the previously shown examples.
Fault Coverage
June 2014
Figure D-10. Fault Coverage Report with Transition and N-Detect Coverage
Report created by: lvFaultCoverageReport Version 7.0
Created on : 11/05/08 14:31:06
For reference information see file:./faultcoveragereport.README
AT-SPEED UNCOLLAPSED FAULT COVERAGE REPORT ---- module: car
Including ELTs: dashboard, engine
----------------------------------------------------------------------
VECTOR SET:
Logic BIST vectors
car : 1920
dashboard : 15360
engine : 7680
car (not compressed) : 6
dashboard (not compressed) : 717
engine (not compressed) : 468
Aborted faults : 3
Transition (N-detect=18) fault coverage : 75.76 %
Transition (N-detect= 1) fault coverage : 95.46 %
Stuck-At (N-detect=18) fault coverage : 89.37 %
Fault Coverage
Example of Chip-Level Fault Coverage
June 2014
Undetected Faults : 551
----------------------------------------------------------------------
Warning: N-detect coverage higher than 18 is available for modules 'car' (N=23) and 'engine'
(N=20).
This subsection provides an example of full chip fault coverage, as illustrated in Figure D-11. In
the example, Chip_50 contains the following components:
ELT sub-blocks fifo_ic_COLLAR and fifo_oc_COLLAR, each includes a collared core
and logicTest controller
Top-level logicTest controller
Top-level TAP controller
Fault Coverage
June 2014
Figure D-11. Example of Chip-Level Fault Coverage
To complete full chip fault coverage, the following tasks below are performed. Note that Task 1
is performed during Step 5: Final ETSignOff of the LV Flow on ELT cores.
1. The ruleAnalyze tool is run on the sub-blocks in the chip design. Figure D-12 and
Figure D-13 illustrate the results of the ruleAnalyze run on the ELT sub-blocks
fifo_ic_COLLAR and fifo_oc_COLLAR.
Fault Coverage
June 2014
Figure D-12. Fault Coverage Report for fifo_ic_COLLAR in the rulea.log File
Stuck-At Fault Coverage Data (Logicbist mode) :
(COVERED FAULTS)
--------------------------------------------------------------------
(UNCOVERED FAULTS)
--------------------------------------------------------------------
Stuck-At Faults in unused logic (Logicbist mode) :
Stuck-At Faults in external logic (Logicbist mode) :
Fault Coverage
June 2014
Figure D-13. Fault Coverage Report for fifo_oc_COLLAR in the rulea.log File
(COVERED FAULTS)
--------------------------------------------------------------------
(UNCOVERED FAULTS)
--------------------------------------------------------------------
The ETVerify tool is run on the sub-blocks. Figure D-14 illustrates the fault coverage
report for the ELT fifo_ic_COLLAR, and Figure D-15 illustrates the fault coverage
report for fifo_oc_COLLAR.
Fault Coverage
June 2014
Figure D-14. Fault Coverage Report for the fifo_ic_COLLAR block
Created on : 11/05/08 16:43:10
For reference information see file:./lvFaultCoverageReport.README
AT-SPEED UNCOLLAPSED FAULT COVERAGE REPORT ---- module: fifo_ic
----------------------------------------------------------------------
VECTOR SET:
Logic BIST vectors
fifo_ic : 32768
fifo_ic (not compressed) : 20
Aborted Faults : 1
----------------------------------------------------------------------
Fault Coverage
June 2014
Figure D-15. Fault Coverage Report for the fifo_oc_COLLAR block
Created on : 11/05/08 16:44:41
AT-SPEED UNCOLLAPSED FAULT COVERAGE REPORT ---- module: fifo_oc
----------------------------------------------------------------------
VECTOR SET:
Logic BIST vectors
fifo_oc : 16384
fifo_oc (not compressed) : 14
Aborted Faults : 0
----------------------------------------------------------------------
Next tasks Tasks 2 and 3 are performed during Step 5: Final ETSignOff of the LV
Flow on the top level of the chip.
Fault Coverage
June 2014
2. Once fault coverage is performed on each sub-block, ruleAnalyze is run on the chip to
perform an overall full chip fault coverage. Figure D-16 illustrates the fault coverage
report for Chip_50 after the ruleAnalyze tool is run.
Figure D-16. Fault Coverage Report for Chip_50 in the rulea.log File
(COVERED FAULTS)
--------------------------------------------------------------------
(UNCOVERED FAULTS)
--------------------------------------------------------------------
3. The ETVerify tool is run on the chip. Figure D-17 illustrates the overall full fault
coverage for top-level by itself. Figure D-18 shows the cumulative fault coverage for the
chip including sub-blocks.
Fault Coverage
June 2014
Figure D-17. Top Level Fault Coverage Report for Chip_50 (not including ELTs)
Created on : 11/05/08 16:25:58
AT-SPEED UNCOLLAPSED FAULT COVERAGE REPORT ---- module: chip50
----------------------------------------------------------------------
VECTOR SET:
Logic BIST vectors
chip50 : 32768
chip50 (not compressed) : 27
Aborted Faults : 3
----------------------------------------------------------------------
Fault Coverage
June 2014
Figure D-18. Cumulative Fault Coverage Report for Chip_50 (including ELTs)
Created on : 11/05/08 16:46:47
For reference information see file: ./lvFaultCoverageReport.README
AT-SPEED UNCOLLAPSED FAULT COVERAGE REPORT ---- module : chip50
Including ELTs : fifo_ic, fifo_oc
----------------------------------------------------------------------
VECTOR SET:
Logic BIST vectors
chip50 : 32768
fifo_ic : 32768
fifo_oc : 16384
chip50 (not compressed) : 27
fifo_ic (not compressed) : 20
fifo_oc (not compressed) : 14
Aborted Faults : 4
----------------------------------------------------------------------
Fault Coverage
Runtime Options for Creating Fault Coverage Reports
June 2014
Runtime Options for Creating Fault Coverage
Reports
This section of this chapter describes in more detail all available runtime options that are used to
customize your fault coverage reports.
The lvFaultCoverageReport tool reads the fault coverage data in the <moduleName>.ifc files
that have been generated by signatureAnalyze and copied to the LVDB by ETVerify.
A <moduleName>.ifc file contains stuck-at fault coverage information for both logic BIST and
(deterministic) scan vectors. The file might also contain transition fault coverage and N-detect
coverage data in case that was generated by signatureAnalyze. Some of the fault coverage data
in a <moduleName>.ifc file has been generated by ruleAnalyze and has been forwarded by
signatureAnalyze without change.
The lvFaultCoverageReport tool consolidates the data that is available in the
<moduleName>.ifc files and generates a cumulative fault coverage report for the top level and
ELTs together. By default, the combined logic BIST plus top-up scan vector coverage is
reported. Optionally, the logic BIST only coverage can be displayed.
After generating the fault coverage report, a copy of the lvFaultCoverageReport.README file
is placed in the output directory. This README file explains in detail the contents of the fault
coverage reportthe explanations for each section of the report are provided in the Fault
Classification Reports section.
You can use the following runtime options to generate fault coverage reports according to your
needs:
SYNOPSIS
lvFaultCoverageReport
lvFaultCoverageReport help
lvFaultCoverageReport <toplevelName> -lvdb <lvdbDir> [-option <arg>]
toplevelName specifies the name of the top-level module. It is mandatory to be
specified.
The following options are available:
o -appendLog
When you specify the appendLog option the generated report will be appended
to an existing report file.
o -lvdb <directoryName>
This option allows you to specify the name of the lvdb directory in which the
<moduleName>.ifc files can be found. The LV_WORKDIR in the lvdb directory
Fault Coverage
Runtime Options for Creating Fault Coverage Reports
June 2014
is searched for any files with an .ifc extension. Any <moduleName>.ifc file
which does not match the <toplevelName> is treated as an ELT. This option is
mandatory.
o -includeELTs (On) | Off
This option allows you to enable or disable the inclusion of the fault coverage
data of the ELTs in the cumulative fault coverage report. By default, the ELT
data is included. When this option is disabled the fault coverage of only the top-
level module is reported.
o -lbistOnly On | (Off)
This option allows you to enable or disable the reporting of pure logicBist fault
coverage. When enabled the fault coverage of top-up scan vectors is ignored and
the coverage of only the logicBist vectors, both for the top level module as well
as the ELTs, is reported. The default is Off.
o -log <fileName>
This option allows you to specify the name of the fault coverage report file.
Default is <toplevelName>.faultCoverageReport.
o -outDir <directoryName>
This option allows you to specify the name of the directory where the fault
coverage report file is to be written. This directory must exist prior to running
this tool, otherwise an error will be reported. By default, the fault coverage
report will be written in the current working directory.
o -redundancyOnly On | (Off)
This option allows you to enable or disable the reporting of redundant fault
analysis. When enabled, only the redundant and aborted fault numbers will be
reported. The default is Off.
For example,
% lvFaultCoverageReport car
-lvdb ../../finalLVDB/car.lvdb
collects the <moduleName>.ifc files from the ../../finalLVDB/car.lvdb/LV_WORKDIR directory
and generates a cumulative fault coverage report for the top-level module and ELTs modules
together.
Fault Coverage
Special ETVerify Output Files
June 2014
This section of the chapter describes in more detail the following ETVerify output files:
Undetected Fault List .ufl_all
Aborted Faults
Redundant Faults
Unpruned Fault List .scanTestableFaultList
Undetected Fault List .ufl_all
The undetected fault list file lists the faults in your design that are not detected by any vectors; a
fault indicates a gate input or output port. If the stuck high or stuck low fault at this gate input or
output port was not detected by any vector, this fault is called an undetected fault.
The undetected fault list file <designName>.ufl_all lists the faults in your design that are not
detected by logic BIST vectors. Top-up scan vectors typically detect most of these faults. The
fault classification of such faults is updated to show that they are detected by the top-up vectors.
The undetected fault list file includes, among others, the aborted faults and the redundant faults
(Refer to Aborted Faults and Redundant Faults).
The undetected fault list file uses the same format as the fault list files generated by
ruleAnalyze. See Figure D-3 for an example of a fault list file.
Entries in the undetected fault list file use the following syntax:
flag class portName
flag describes the type of fault that ETVerify cannot detect. The valid values are:
o sa0 specifies a Stuck-At-0 (SA0) fault. This indicates that ETVerify could not
detect the Stuck-At-0 fault on this port.
o sa1 specifies a Stuck-At-1 (SA1) fault. ETVerify could not detect if the port is
stuck at logic 1.
o N-R specifies a non-rising transition fault. ETVerify could not detect the
Slow-To-Rise fault on this port
o N-F specifies a non-falling transition fault. ETVerify could not detect a the
slow-to-fall fault on this port.
class describes the classification of the fault. Valid values are:
Fault Coverage
June 2014
o UD specifies an undetected fault. This indicates that the fault is not detected
by any vectors.
o DC specifies a fault that is detected by compressed scan vectors.
o DA specifies a fault that is detected by normal (uncompressed) scan vectors.
o RE specifies a redundant fault. The function of the circuit remains unchanged
in the presence of this fault as identified by the Deterministic Test Pattern
Generator (DTPG). Therefore, it cannot be detected.
o UA specifies an aborted fault. The Deterministic Test Pattern Generator
(DTPG) could not generate a test for this fault nor could the fault be proven
redundant in a reasonable amount of time.
o UE specifies an untestable enable fault. This is a fault on the enable port of a
tristate driver (or in logic driving this port) that has not been potentially detected.
The fault cannot be solidly detected because in its presence, the faulty value on
the tristate gate is unknown.
o UC specifies a PRPG untestable fault. This is a fault for which
signatureAnalyze was not able to generate a compressed vector. The fault is not
redundant and can be detected with a normal (uncompressed) scan vector.
o PU specifies a potentially detected tristate enable fault. This fault is
potentially detected by the logic BIST vectors and/or deterministic scan vectors.
A potential detection might happen when tristate drivers are used in a design.
o PD specifies a potentially detected fault.
o EQ specifies an equivalent fault. This fault is equivalent to the fault printed on
the line immediately above it.
portName identifies the cell port which contains the current fault.
Aborted Faults
Aborted faults are the faults for which the number of backtracks has been exceeded. Increasing
the number of backtracks (with -backtracks) will usually cause the faults to be covered or be
identified as redundant. The number of aborted faults should be 0 in most cases.
The format of .afl_<mode> files is the same as the format of .ufl_<mode> files. For
information about this format, refer to Undetected Fault List .ufl_all.
ETVerify generates this file only when the tool finds aborted faults in the circuit.
Figure D-19 shows an abbreviated aborted fault list file.
Fault Coverage
June 2014
Figure D-19. Aborted Fault List File
Redundant Faults
A redundant fault is a fault for which it is impossible to find a test pattern. Figure D-20 shows
an example of redundant logic.
Figure D-20. Example of a Redundant Fault
It is impossible to verify that the output of gate 1 in Figure D-20 is permanently high (stuck-
at-1) because of the re-convergence of the logic. This means that the output of gate 1 could be
tied to a logic 1 without changing the logic function.
An equivalent and simpler circuit can then be built to realize the same function. Figure D-21
shows this simpler circuit.
Fault Coverage
June 2014
Figure D-21. Equivalent Circuit for Figure D-20
In theory, redundant faults can be subtracted from the list of faults that need to be detected.
However, some faults may be redundant in test mode only. ETVerify can not find a test pattern
for these faults, but they might cause the circuit to fail in functional mode; consider the circuit in
Figure D-22.
Figure D-22. Example of a False Redundant Fault prior to Pruning
Suppose that the signal IN1 is the output of a non-scannable portion of the circuit and that you
use the test mode signal (TM) to define its value and to avoid a rule violation. After ruleAnalyze
prunes the logic, you obtain the redundant circuit of the previous example shown in Figure D-
23.
Fault Coverage
June 2014
Figure D-23. Example of a False Redundant Fault after Pruning
However, because the signal IN1 will eventually take a logic value of both 0 and 1 in functional
mode, gate 1 is needed to realize the function and must be tested. To run the test, you must
include functional or design verification patterns.
The false redundant faults are likely to appear everywhere around gates controlled by the test
mode (TM) signal. Transparent latches, memories, and tri-state bus drivers are likely to
introduce redundancies because of their special handling during test mode.
Unpruned Fault List .scanTestableFaultList
The unpruned fault list file <designName>.scanTestableFaultList lists all the unpruned faults in
your design that are classified by ETVerify. This file is initially created by ruleAnalyze and is
updated by signatureAnalyze when the logic test vectors are created. In addition to the faults
that are listed in the undetected fault list file <designName>.ufl_all, the unpruned fault list file
lists also the faults that are detected by logic BIST vectors. A unique classification code, DB, is
used to show that a fault is detected by logic BIST vectors.
DBspecifies a fault that is detected by logic BIST vectors.
All other classification codes are the same as the ones used in the undetected fault list file (Refer
to Undetected Fault List .ufl_all).
Note
The unpruned fault list file is an optional file. It is only created when ruleAnalyze is run
with the runtime option -writeFaultListFiles. If this file is not created by ruleAnalyze then
it will not be created or updated by signatureAnalyze.
Fault Coverage
Fault Classification Differences between Tessent FastScan and signatureAnalyze
June 2014
Fault Classification Differences between
Tessent FastScan and signatureAnalyze
The following sections describe the fault coverage differences for two types of fault models:
Stuck-at Fault Classification Difference
Transition Fault Classification Differences
Stuck-at Fault Classification Difference
False redundant faults (Figure D-21 and Figure D-22) are classified ATPG_untestable by
Tessent FastScan, while they are classified redundant by signatureAnalyze.
Transition Fault Classification Differences
Multi-cycle paths, false paths, transmit flip-flops, and control signals might create situations
where Tessent FastScan and signatureAnalyze classify transition faults differently. Each of
these causes is discussed separately in the following sections:
Multi-Cycle Paths
False Paths
Transmit (TX) Flip-Flops
Control Signals
Multi-Cycle Paths
Case 1 below describes the general case where the Tessent FastScan and signatureAnalyze
classification of transition faults on multi-cycle paths (MCPs) differ.
Case 1: Conditional detection
When a gate is located on both a single-cycle path (SCP) and a multi-cycle path (MCP),
then Tessent FastScan only credits a transition fault detection if the fault is sensitized,
and its effect is propagated along an SCP. Similarly, when a gate is located on MCPs
with different multiplicities, then only a transition along the MCP with the lowest
multiplicity is credited for fault detection. The signatureAnalyze tool credits any SCP
and MCP transition for transition fault detection.
Transition faults are not detected by Tessent FastScan in Cases 2-3 as described below:
Case 2: Mixed fan-in gate:
Fault Coverage
June 2014
When a gate has mixed fan-in, that is, one input of the gate is on an SCP whereas an
other input is only on MCPs (or the MCPs through one input have lower multiplicity
than the MCP with the lowest multiplicity through another input) then the transition
faults on the gate input that is only on MCPs (or not on an MCP of the lowest
multiplicity through the gate) will not be detected by Tessent FastScan.
Case 3: Hardware limitation:
When a flip-flop sources both SCPs and MCPs in functional mode then in test mode the
SCPs are not tested at-speed but at the speed of the MCP with the highest multiplicity
that the flip-flop sources. All transitions on these paths occur at least two clock cycles
before the capture cycle. Tessent FastScan does not detect transition faults on paths that
are not tested at-speed.
Figure D-24 illustrates the above Cases 1-3. The red dots mark the location of transition faults
that are conditionally detected as described in Case 1 above. When these faults are detected by
signatureAnalyze, they might or might not be detected by Tessent FastScan. Tessent FastScan
only considers transitions coming from flip-flops M1S1 and M1S2 to detect these faults. Note
that in test mode the (functional) SCP from M12S to FF10 is treated as an MCP as all paths
sourced by M12S are treated the same way in test mode. The yellow dot marks the location of
faults on a gate input that is on an MCP, whereas, the gate is on an SCP (Case 2). These faults
are not detected by Tessent FastScan. The blue dots mark the location of faults that are not
detected by Tessent FastScan due to a hardware limitation in test mode (Case 3). Flip-flop
M12S can only change state two cycles before the capture cycle.
Figure D-24. Transition Faults on Multi-Cycle Paths
Fault Coverage
June 2014
False Paths
In the BurstMode architecture, a flip-flop that sources a false path holds during the rotation
cycles of the burst phase. A functional flip-flop might change state during the capture cycle. A
test-only flip-flop, such as a control test point, never changes state during the capture cycle. The
last scan shift cycle might cause a transition along the false path. For transition fault detection,
Tessent FastScan does not credit a transition which is due to the last scan shift, whereas
signatureAnalyze does credit such a transition.
classification of transition faults on false paths differ.
When a gate is located on both an SCP or MCP and on a False Path (FP), then Tessent
FastScan does not credit a transition fault detection if the fault is sensitized, and its
effect is propagated along the false path. The signatureAnalyze tool credits the last scan
shift transition along the false path for transition fault detection.
In Cases 2-4, transition faults are not detected by Tessent FastScan as described below:
Case 2: Mixed fan-in gate
When a gate has a flip-flop in its fan-in cone that sources an SCP or MCP, then Tessent
FastScan does not credit the detection of a transition fault on that gate if the fault is
sensitized, and its effect is propagated along the false path. Note that this case includes a
gate that is only on false paths but has also a flip-flop in its fan-in cone that sources an
SCP or MCP. This case also includes the transition faults along the holding path of a
flip-flop that sources false paths as well as SCPs and/or MCPs.
Case 3: Hardware limitation
When a flip-flop sources both SCPs or MCPs and false paths in functional mode then, in
test mode, the SCPs/MCPs are not tested at-speed because the flip-flop is constrained in
hardware in such a way that it cannot change state during the rotation cycles.
Case 4
When all flip-flops in the fan-in cone of a gate are sources of false paths, then the
transition faults on the gate are not detectable by Tessent FastScan and the fault
coverage reported will be lower than signatureAnalyze. However, the faults are not
counted in the relevant fault coverage report of Tessent FastScan. The relevant fault
coverage reported is comparable to the coverage reported by signatureAnalyze.
Figure D-25 illustrates Cases 1-3. The red dots mark the location of transition faults that are
conditionally detected as described in Case 1 above. When these faults are detected by
signatureAnalyze, they might or might not be detected by Tessent FastScan; Tessent FastScan
only detects these faults if the transition comes from flip-flops M1S1 and M1S2. Note that in test
mode, the functional SCP from M1FPS to FF10 is treated as a false path as all paths sourced by
Fault Coverage
June 2014
M1FPS are treated the same way in test mode. The yellow dots mark the location of faults on a
gate input that is on a false path, whereas the gate has a flip-flop in its fan-in cone that sources
an SCP (Case 2). These faults are not detected by Tessent FastScan. Note that Tessent FastScan
considers flip-flop M1FPS as a source of an SCP only even if it is a source of both SCP and
false path in functional mode. This is why the yellow faults in the fan-in of flip-flop M1S1 are
not removed from the relevant fault list as would be the case if the functional SCP from M1FPS
to FF10 would not exist. The situation would be similar to the one shown in Figure D-26. The
blue dots mark the location of faults that are not detected by Tessent FastScan due to the
hardware limitation in test mode described earlier (Case 3).
Figure D-25. Transition Faults on False Paths
Figure D-26 illustrates Case 4. The green dots mark the location of faults that are not counted in
the relevant fault coverage in Tessent FastScan. These faults are located on a gate that has only
flip-flops in its fan-in cone that are sources of false paths. (Similar to Figure D-25, the red dots
and the yellow dots mark the location of transition faults that are described in Case 1 and
Case 2, respectively).
Fault Coverage
June 2014
Figure D-26. Transition Faults Excluded from Relevant Fault List
Transmit (TX) Flip-Flops
A transmit (TX) flip-flop holds during the burst phase for some vectors while it toggles for other
vectors. When the flip-flop is holding, the last scan shift cycle is the only possible cause of a
transition at the output of the flip-flop.
classifications of transition faults in the fan-out cone of a TX flip-flop differ.
For transition fault detection, Tessent FastScan does not credit a transition on the output
of a TX flip-flop if the flip-flop is holding during the burst phase. Tessent FastScan only
credits a transition on the flip-flop output if it is toggling during the burst phase. If a TX
flip-flop is holding during the burst phase then signatureAnalyze credits a transition that
is due to the last scan shift cycle.
This case includes transition faults that are located within a different clock domain.
These transition faults are detected by Tessent FastScan only if the transition comes
from an SCP or MCP source within the clock domain where the fault is located.
In Cases 2-3, transition faults are not detected by Tessent FastScan as described below:
Case 2: Mixed fan-in
If a gate within a clock domain has a fan-in that is sourced by a different clock domain
then the transition faults on this gate input are not detected by Tessent FastScan. This
case also includes the transition faults along the holding path of a TX flip-flop.
Case 3: Excluded faults
Fault Coverage
June 2014
If a gate is not located on any intra-clock domain path, then Tessent FastScan removes
all transition faults on that gate from the fault population.
Figure D-27 illustrates the above Cases 1-3. The red dots mark the location of transition faults
that are conditionally detected (Case 1). The faults along the intra-domain path are not detected
when the TX flip-flops are holding, unless they are detected due to a transition coming from
another flip-flop. The transition faults along the cross-domain path can only be detected if the
transition comes from a flip-flop in the same clock domain as the destination flip-flop (CLKB).
The yellow dots mark the location of faults on a gate input that is on a cross-domain path while
other inputs of that gate are within a clock domain (Case 2). The green dots mark the fault
locations of gates on cross-domain paths that are removed from the fault population by Tessent
FastScan (Case 3).
Figure D-27. Transition Faults in the Fan-Out Cone of TX Flip-Flops
Fault Coverage
June 2014
Control Signals
The signatureAnalyze tool ignores transitions from certain control signals which are constant
during the capture cycle, such as ClockEnable (Cen) and ScanEnable (SE). The
signatureAnalyze tool considers transitions coming from CaptureDisable (CD) flops, such as
CDn, CDSE. Tessent FastScan ignores transitions from CD flops as the flip-flops do not toggle
after the last scan shift, but Tessent FastScan considers transitions from Cen and SE as these
signals toggle during the Burst phase. This difference in behavior between Tessent FastScan
and signatureAnalyze might cause minor detection differences for specific vectors, but there is
no overall coverage difference when more vectors are being applied. Figure D-28 illustrates
these faults. The yellow dots mark the location of the faults that are discussed above.
Figure D-28. Control Signals Sourced by SE Controller
June 2014
Appendix E
Managing Your ECO Process
This appendix describes in detail the following processes:
Performing a functional ECO to your circuit and restoring the proper LogicTest mode of
operation following such functional ECOs
Removing testpoints from critical paths
Appendix topics follow this sequence:
Overview of ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Enabling Your Chip to Handle ECO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Performing Your Functional ECO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Analyzing the Post-functional ECO Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Customizing the Post-ECO Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Performing LV-ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Verifying the LV Post-ECO Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Removing Testpoints From Critical Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Identifying Multi-Cycle Path Flip-flops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
ecoGenerate Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Usage of ecoGenerate Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Syntax for .lveco Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Syntax for Critical Paths File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
ruleAnalyze Input File for ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Runtime Options for ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Output Files for ECO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Overview of ECO Process
June 2014
To perform a functional ECO to your circuit and restore the proper LogicTest mode of operation
following such functional ECOs, you perform operations as described in Figure E-1.
Figure E-1. Restoring the Proper LogicTest Mode of Operations
The following sections provide description of the ECO process operations:
Enabling Your Chip to Handle ECO
Performing Your Functional ECO
Analyzing the Post-functional ECO Netlist
Customizing the Post-ECO Netlist
Performing LV-ECO Process
Verifying the LV Post-ECO Netlist
June 2014
Enabling Your Chip to Handle ECO
The LV ECO process is performed on a full chip or an ELT collar netlist which passed the
LogicVision sign-off process prior to having a functional ECO change made to it. The
functional ECO might be done on a close-to-final laid-out version of the chip or even as a re-
spin to an already fabricated chip. For this reason, the LV ECO process was designed to be
achievable on a fully flattened view of the collared cores and chip.
Note
Note that the Embedded Test blocks generated by the LV Flow will contain
approximately 5% of slack for adding scan flip-flops. You do not need to prepare your
design for adding flip-flops or introducing timing paths that are multi-cycle paths.
The process also supports the usage of already instantiated spare gates to implement the LV
ECO corrections. This allows a metal-only layout ECO.
The following sections describe in more detail Preparing Your Netlist to Allow for Metal-Only
Layout ECOs.
Preparing Your Netlist to Allow for Metal-Only Layout
ECOs
If you want to be able to lay out the post-LV ECO netlist with metal-only changes, you need to
equip your laid-out netlist with specific spare cells required by the LV ECO process. The
complete list of cells required by the LV ECO process is listed in Table E-1. You do not need 2-
input AND and OR gates if you instantiate 3-input ones. The unused inputs of the AND and OR
gates will simply be tied to their inactive values. Make sure to use spare cells (combinational
cells such as MUX, OR, AND, Inverter, TieHigh, TieLow) that connect their inputs to constant
value through upper layers of metal. This minimizes the number of mask changes required to
make the ECO. The spare cells should also be distributed among the rest of the functional logic.
Note
All spare cells (combinational cells such as MUX, OR, AND, Inverter, TieHigh, TieLow)
have to be specified in the scang.lib file. The ruleAnalyze (-mode ECO) will copy them
into the .lveco file for further use.
Table E-1. Spare Cells Required by the LV ECO Process
2 input multiplexers
2 input AND gates
3 input AND gates
2 input OR gates
June 2014
Performing Your Functional ECO
When you perform your functional ECOs, you can do anything you like to the combinational
logic as long as you do not violate any of the basic scan rules. For example, all observable nets
must remain controllable. You do not have to worry about introducing new inter-domain paths
or affecting the shared isolation analysis. The LV ECO process analyzes your modified netlist
and automatically performs the corrections to the LogicTest mode.
If you need to add a new flip-flop for your functional ECO, then use scan mux flip-flops with
the scan enable pin tied inactive. Do not attempt to manually insert a new flip-flop into a scan
chain. The LV ECO process detects the new flip-flops and automatically inserts them into the
correct scan chains.
If you stop using some of the pre-existing flip-flops in the function, it is better to leave them in
the scan chain and simply stop using their outputs for your function. Make sure that the inputs
are connected to the circuit tied to a constant. This minimizes the amount of layout
modifications generated from your functional ECO.
Analyzing the Post-functional ECO Netlist
When you perform ECO that changes the functionality of your design, further modifications are
required to correct the LogicTest mode. Those corrections are automatically determined by the
ruleAnalyze LogicTest -mode ECO run. If it turns out the LogicTest mode does not need any
correction, then ruleAnalyze informs youruleAnalyze tool generates a .lveco file.
You use the make target make rulea_eco in the Pre-Layout ETSignOff step of the LV Flow.
The generated .lveco file outlines all actions required to modify a post-functional ECO netlist
and restore the proper behavior of the Scan and LogicBist modes. This file is written out in the
current working directory. The .lveco file might be edited as described in Customizing the Post-
ECO Netlist. This file is a required input file to the ecoGenerate tool.
3 input OR gates
2 input NOR gates
3 input NOR gates
2 input NAND gates
3 input NAND gates
Inverters
Tie low cells
Tie high cells
Table E-1. Spare Cells Required by the LV ECO Process (cont.)
June 2014
The ruleAnalyze tool also generates the <designName>.ecoinfo file in the LV_WORKDIR
directory. This is an information-only file to help you specify a different scan chain insertion
point for a new flip-flop or the relocation of a pre-existing scan flip-flop to another chain. The
ruleAnalyze tool identifies the valid scan insertion input ports where a flip-flop can be inserted
into the scan chain. The scan insertion points are grouped based on their clock domain, multi-
cycle path, transmit capture group, and periphery attributes. For detailed description of the
.ecoinfo file, refer to Syntax for .ecoinfo Input File.
Limitations and Restrictions
Note the following limitations and restrictions on the extent of the functional ECOs:
No new clock domains can be added between the pre- and post-ECO netlists.
The ECO changes cannot result in rule violations other than those related to pre-scan,
shared isolation, and capture-by-domain. For example, there cannot be any Basic or
Synchronous rule violations. The ruleAnalyze -mode ECO run validates such rules and
flags errors. If errors are flagged then you must fix these violations manually.
The post-ECO netlist must be uniquified. The ruleAnalyze tool flags a violation if any
netlist corrections must be made within a non-unique module.
A new rotating scan segment will not be created as part of the LV ECO process. In order
for scan insertion to be possible the ECO flop may be made into a transmit CD flop
and/or have its MCP value increased.
Customizing the Post-ECO Netlist
You can customize the .lveco file to perform the following adjustments:
1. Change the location of flip-flop insertion in the pre-existing scan chain
If you want to avoid scan chain re-ordering during the ECO layout, you need to modify
the NextSIPort property in the Action (InsertInScanChain) wrapper to insert the flip-
flop in the closest allowed location. You can specify any other flip-flop which belongs
to the same ScanChainGroup wrapper as described in the .ecoinfo file generated by
ruleAnalyze.
This modification example is provided in Example 1. Refer to the Example 2 for
instructions on how to insert new flip-flops into a pre-existing scan chain.
2. Specify existing spare gates to use for controlling logic instead of instantiating new
gates
If you want to limit the ECO to a metal-only change, you use the UseSpare wrapper to
map each gate instance to a pre-existing cell in the circuit that has the right location and
function. For example, if the required cell type is AND2, and you have AND3 cells close
June 2014
by, you specify Input A and B as the Input0 and Input1 functions. The C port would be
left unspecified, and, thus, would be left tied high.
This modification example is provided in Example 3.
Complete .lveco File Syntax
Figure E-2 presents complete syntax of the .lveco file generated by the ruleAnalyze -mode ECO
run. The only syntax that you can modify is shown in brown.
Figure E-2. Complete Syntax for the .lveco File

ScanFlipFlop (<PathToFlop>) {
ScanChainPorts {
SI: <PathToPort>;
SO: <PathToPort>;
}
Action (RemoveFromScanChain) {
NextSIPort: <PathToOldNextSIPort>;
}
Action (InsertInScanChain) {
NextSIPort: <PathToNewNextSIPort>;
}
Action (Connect) {
DestinationPort: <Path>;
SourcePort: <Path>;
Gate (<GateType>) {
ID : <ID>;
ReuseGateID : <ID>;
Port (<PortFunction>) {
SourcePort: <Path>;
Gate (<GateType>) {
ID : <ID>;
ReuseGateID : <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
Gate (<GateType>) {
ReuseGateID : <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
}
UseSpare {
Port (<PortFunction>):
<HierarchicalPortName>;
}
}
}
June 2014
UseSpare {
}
}
}
UseSpare {
}
}
}
Action (Intercept) {
SourcePort: <Path>;
Gate (<GateType>) {
SourcePort: <Path>;
Gate (<GateType>) {
ID: <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
Gate (<GateType>) {
ID: <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
}
UseSpare {
}
}
}
}
}
UseSpare {
}
}
PreserveConnection {
...
}
}
...
TestPointRemoval {
// From: <from port path>;
// To: <to port path>;
Action (Connect) {
DestinationPort: <cell input port path>;
Gate (<tieGateType>) {
ID: <ID>;
ReuseGateID: <ID>;
}
}
June 2014
}
}
For detailed description of all wrappers and properties available within the .lveco file, refer to
Syntax for .lveco Input File.
Understanding the .ecoinfo File Syntax
The .ecoinfo file helps you to choose a different NextSIPort inside the Action
(InsertInScanChain) wrapper of the .lveco file. You can choose any other entry listed in the
NextSIPortList wrapper within the same ScanChainGroup wrapper of the .ecoinfo file. You
choose any entry that is closest and with minimal impact on routing.
Figure E-3 presents the complete syntax for the .ecoinfo file.
Figure E-3. Complete Syntax for the .ecoinfo File
ScanChainGroup {
ClockDomain: <ClockDomainName>;
MCP: 1 | 2 | 3 | 4 | False;
InternalCD: <N>;
ExternalCD: <N>;
Periphery: Yes | (No);
ScanChain {
Length: <integer>;
NextSIPortList {
<PathToNextSIPort>;
...
}
...
}
For detailed description of all wrappers and properties available within the .ecoinfo file, refer to
Syntax for .ecoinfo Input File.
Example 1
This section provides example modification for the case when you need to change the location
of flip-flop insertion into a pre-existing scan chain.
In this example, a new flip-flop needs to be inserted into a pre-existing internal scan chain. The
flip-flop is a normal scan flip-flop.
To avoid scan chain re-ordering during the ECO layout, you need to modify the NextSIPort
property in the Action (InsertInScanChain) wrapper of the .lveco file to insert the flip-flop in
the closest allowed location:
ScanFlipFlop (blocka/new_reg) {
ScanChainPorts {
SI: blocka/new_reg/SI;
SO: blocka/new_reg/Q;
June 2014
}
NextSIPort: blocka/scan_reg/SI;
}
Action (Connect) {
DestinationPort: blocka/new_reg/SM;
SourcePort: blocka/LV_SE_CLKA_F1;
}
}
Note
Note that names for PathToFlop in the SI and SO properties must be specified using
the/ delimiter.
You can use the information on the flip-flop locations in the .ecoinfo file:
ScanChainGroup {
ClockDomain: CLKA;
MCP: 1;
Periphery: Yes;
ScanChain {
Length: 98;
NextSIPortList {
blocka/scang_reg/SI;
blocka/scan_0/SI;
blocka/scan_1/SI;
blocka/scan_2_pdmux/B;
...
}
ScanChain {
Length: 100;
NextSIPortList {
blockb/counter_reg_0/SI;
...
}
}
}
You can choose any closest flip-flop from the NextSIPortList wrapper of the same
ScanChainGroup in the .ecoinfo file to insert into the NextSIPort property of the .lveco file.
The modified .lveco file will look as follows:
ScanChainPorts {
}
NextSIPort: blocka/scan_0/SI;
}
June 2014
Action (Connect) {
}
}
For more modification examples, refer to ruleAnalyze Generated .lveco File.
Example 2
This section provides example modification for the case when you need to insert new flip-flops
into a pre-existing scan chain.
In this example, two new flip-flops need to be inserted into an internal pre-existing scan chain.
These flip-flops must be inserted before the pre-existing scan flip-flop flopC, and the scan chain
order must be flopA -> flopB -> flopC, as shown in Figure E-4. New flip-flops are highlighted in
brown.
Figure E-4. Example for Inserting New Flip-Flops
Figure E-5 illustrates the .lveco file for the example above.
Figure E-5. The .lveco File for Example 2
/*
* Action: insert the flip-flop flopA into a
* pre-existing scan chain just before flopC and
* connect the scan enable.
*/
ScanFlipFlop (blocka/flopA) {
ScanChainPorts {
SI: blocka/flopA/SI;
SO: blocka/flopA/Q;
}
NextSIPort: blocka/flopC/SI;
}
Action (Connect) {
DestinationPort: blocka/flopA/SM;
June 2014
}
}
/*
* Action: insert the flip-flop flopB into a
* pre-existing scan chain just before flopC and
* connect the scan enable. Note that flopB will be
*inserted between flopa and flopC since flopA was
*inserted into scan chain with the above action.
*/
ScanFlipFlop (blocka/flopB) {
ScanChainPorts {
SI: blocka/flopB/SI;
SO: blocka/flopB/Q;
}
NextSIPort: blocka/flopC/SI;
}
Action (Connect) {
DestinationPort: blocka/flopB/SM;
}
}
Example 3
This section provides example modification for the case when you need to specify existing
spare gates to use for controlling logic instead of instantiating new gates.
If you want to limit the ECO to a metal-only change, you use the UseSpare wrapper to map
each gate instance to a pre-existing cell in the circuit that has the right location and function.
In the example below, the UseSpare wrapper is used to identify all ports on an existing OR gate
to be used as the two-input OR gate required for the Connect action.
ScanFlipFlop (blocka/scan_reg) {
Action (Connect) {
DestinationPort: blocka/scan_reg/SM;
Gate (OR2) {
Port (Input0) {
SourcePort: LV_CD0;
}
Port (Input1) {
SourcePort: LV_SE_CK1;
}
}
UseSpare {
Port (Input0): blocka/spare_or2_1/A;
Port (Input1): blocka/spare_or2_1/B;
Port (Output): blocka/spare_or2_1/Y;
}
}
}
June 2014
For more modification examples, refer to ruleAnalyze Generated .lveco File.
Performing LV-ECO Process
Once you are satisfied with the edits detailed in the .lveco file, the changes must be applied to
the netlist using the ecoGenerate tool. The edited .lveco file is used as input to ecoGenerate.
The ecoGenerate tool parses the .lveco file and creates a new version of your netlist with the
-modifiedExtension appended to it.
You use the make target make lveco in the Pre-Layout ETSignOff step of the LV Flow.
Runtime Options for ecoGenerate
If you are invoking ecoGenerate from the command line, you use the runtime options described
below. If you type ecog without any parameters, your terminal window displays a summary of
command-line syntax and tool usage.
Verilog Flow for ecoGenerate
This section describes runtime options for ecoGenerate.
Default options that you need not explicitly specify are described in the Other Commonly Used
Options for ecoGenerate.
ecog <designName> <sourceFileName1>
<sourceFileName2>...
-modifiedExtension <modifiedExtension> \
-r <topLevelBlockName> \
-y <libraryDirectoryName>

where the above syntax represents the following criteria:
designName specifies the prefix for all generated intermediate files and serves as
default configuration file prefix
sourceFileName specifies Verilog file that describes a design block.
-modifiedExtension <modifiedExtension>
This option specifies the extension that ecoGenerate appends to output files containing
the top-level assembly of the chip and the generated design objects.
-r <topLevelBlockName>
This option specifies the name of the top-level logic block into which ecoGenerate
merges the sub-blocks with embedded test. topLevelBlockName can be any valid
operating system and language character string.
June 2014
This option instructs ecoGenerate to read the directory that you indicate. You can
include sub-blocks of topLevelBlockName in library directories using the -y command.
Alternatively, you can list the files that contain the sub-blocks in your command line
between the keyword ecog and the first command, such as -extension.
libraryDirectoryName is a valid operating system character string. You can specify
multiple directories but you must precede each directory name with -y.
The ecoGenerate tool reads directories in the same order in which you specify them.
Within a directory, when searching for a specific element, ecoGenerate follows the
search order defined by the -extension option and uses the first instance that it
encounters. The ecoGenerate tool ignores subsequent instances of the same element.
Other Commonly Used Options for ecoGenerate
The ecoGenerate tool assumes the following defaults unless you specify otherwise. When you
want to use values other than the default, include these options on the command line after the
ecog executable.
-configFile <configFileName>
This option enables you to specify an alternative configuration file to be used instead of
default <designName>.lveco.
-define <macroName>
This option defines a macro name (as empty text) that remains in scope throughout the
analysis of every Verilog design file. You can reference this macro in one or more
Verilog source files.
-defineFile <defineFileName>
This option specifies the name of a file containing macro definitions that remain in
scope throughout the compilation of each Verilog design file.
-extension <extension>: [<extension>]...
This option specifies the list of library directory file extensions for Verilog. Within a
given library directory ecoGenerate attempts to resolve a module name by sequentially
looking up file names composed of the module name, a dot, and each extension
specified with this option (i.e. <moduleName>.<extension>). This option is required
whenever a library directory is specified.
-HDLwarningFilter High
This option specifies which level of messages are filtered during an ecoGenerate run.
-incDir <includeDirectoryName>
Removing Testpoints From Critical Paths
June 2014
This option specifies the name of a directory to be searched in resolving Verilog include
file names.
-language (Verilog)
This option controls whether ecoGenerate generates Verilog code.
-log ecog.log
This option specifies the name of the log file generated by ecoGenerate.
-outDir <directoryName>
This option identifies the directory in which ecoGenerate places all of its output files for
the design objects.
-v <libraryFileName>
This option adds the name of a Verilog library file to the search path that ecoGenerate
uses for resolving names appearing in Verilog modules.
Verifying the LV Post-ECO Netlist
A new netlist is created with the post LV ECO edits. The modified netlist file has the
_postLVECO file extension appended to it or the extension you have specified to ecoGenerate
using the -modifiedExtension runtime option.
The LV post-ECO modified netlist must be verified. Step 5: Final ETSignOff needs to be
completed on the current netlist.
Removing Testpoints From Critical Paths
Testpoints usually do not affect your ability to close timing because testpoints are inserted on
complex logic paths which have lots of opportunity to be restructured thus nullifying the effect
of the testpoints.
In rare cases, when testpoints affect your timing closure, you can use ruleAnalyze -mode ECO
to identify testpoints along a critical path you are having problem closing timing on and have
them removed automatically.
To remove testpoints along a critical path in your design, you specify the critical paths in the
critical paths file using the start and end point. The ruleAnalyze tool analyzes the circuit to
identify any testpoints flops directly controlling the input of a multi-input gate in the specified
paths. The results of this analysis are reported in the TestPointRemoval wrapper of the
generated .lveco file. The action used to remove a testpoint from a critical path consists of
connecting the input of the testpoint gate to its inactive value, i.e. the value which is present
during the functional mode. Once this is done, you can take your netlist through an incremental
optimization and the effects of the testpoint on the critical path will be removed. You run
Identifying Multi-Cycle Path Flip-flops
June 2014
ecoGenerate with this .lveco file exactly the way it was explained in Performing LV-ECO
Process.
The critical path file has syntax as follows:
<from port path> <to port path>;
You use this syntax to specify pairs of paths from which the testpoint gate(s) need to be
disconnected. You create this ruleAnalyze input file following these rules:
The levels of hierarchy are determined by /.
The first part of the pair must specify a top-level input port, or a complete path to the
output of a logic gate or flop.
The second part of a pair must specify a top-level output port, or a complete path to the
input of a logic gate or flop.
Multiple path pairs can be specified with each pair terminated by a semi-colon.
Comments in the critical paths file are allowed. A line starting with the # character
renders the entire line a comment. Empty lines are allowed as well.
The following example shows a specification of three critical paths:
topLevelInputPort /top/block/subblk2/tf2/D;
/top/block/subblk3/ff2/Q /top/block/subblk2/tf4/D;
/top/block/subblk5/ff3/Q topLevelOutputPort;
For detailed reference information about the critical paths file, refer to Syntax for Critical Paths
File.
Identifying Multi-Cycle Path Flip-flops
You can identify multi-cycle path (MCP) flip-flops as part of the ECO process. You can
identify MCPs for an existing scan flip-flop or for a flip-flop introduced with an ECO. You
specify multi-cycle paths to ruleAnalyze using the <designName>.lvmcp file. Only one
<designName>.lvmcp file is allowed for ECO.
The <designName>.lvmcp file is automatically read in if it is located on the search path. You
specify the search path using the SimModelDir properties that you supply to ETPlanner.
The syntax for a <designName>.lvmcp file containing lists of flip-flops in multi-cycle and false
paths is as follows:
MCP (x) {
<hierarchicalName1>;
<hierarchicalNameN>;
}
ecoGenerate Input Files
June 2014
FalsePath {
<hierarchicalNameN>;
}
where valid values are as follows:
x specifies a multi-cycle path operating at the 1/x frequency of the domain containing
the flip-flop. The value specified in the MCP wrapper must be less than the clock
domain's burst length. If the desired value is equal to or more than the burst length,
ruleAnalyze automatically changes it to FalsePath. Therefore, for a typical burst length
of 5, the allowed MCP values are 2, 3, or 4.
The FalsePath wrapper is used to specify flip-flops that source a false path. A flip-flop
declared within the FalsePath wrapper always holds its last shifted value during the
entire burst phase.
hierarchicalName specifies the full path and name of each flip-flop sourcing a multi-
cycle or false path.
If you specify a MCP value for an existing scan flip-flop that is already implemented with a
greater MCP value, the scan flip-flop will not be modified. That is, you can increase the MCP
value of an existing MCP flip-flop but you cannot decrease the MCP value of an existing scan
flip-flop.
Additionally, when a MCP value is defined for a scan flip-flop, it must be connected to an
existing scan chain segment with the same clock domain and MCP value properties. If no such
compatible MCP scan chain segment exists, the MCP value is increased until a compatible
chain segment exists. In the worst case, the MCP scan flip-flop will be inserted as a false path
scan flip-flop.
This section describes in detail the ecoGenerate input files .lveco and .ecoinfo. These files
allow you to customize ECO edits.
This Section topics follow this sequence:
Usage of ecoGenerate Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Syntax for .lveco Input File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
ScanFlipFlop (<PathToFlop>) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
ScanChainPorts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Action (RemoveFromScanChain). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Action (InsertInScanChain) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Action (Connect). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
June 2014
Action (Intercept) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Gate (<GateType>) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
TestPointRemoval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
ScanChainGroup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Usage of ecoGenerate Input Files
The .lveco file serves as input to the ecoGenerate tool. The .lveco file is created by ruleAnalyze
(-mode ECO). This file describes the edits that are required in the post-ECO netlist.
You edit the .lveco file written out by ruleAnalyze -mode ECO run to modify it only for the
following reasons:
1. Change the location of flip-flop insertion in the pre-existing scan chain when you are not
re-ordering the scan chains during the layout ECO.
2. Specify existing spare gates to use for the control logic instead of letting ecoGenerate
instantiate new ones when you want to perform a metal-only layout ECO.
The ruleAnalyze tool generates a second file with the extension .ecoinfo. This is an
informational file that lists all compatible scan chain insertion points for all flip-flops. This
helps you to choose a different NextSIPort inside the Action (InsertInScanChain) wrapper of
the .lveco file. You choose a compatible point that has the least impact on scan chain routing.
For detailed information on these files, refer to the following sections:
Syntax for .lveco Input File
Syntax for .ecoinfo Input File
The .lveco file can contain one or multiple ScanFlipFlop wrappersone wrapper per flip-flop
that requires some LogicVision ECO edits, and the TestPointRemoval wrapper if you need to
disconnect some testpoint gates.
Figure E-2 presents the complete syntax for the .lveco file.
Figure E-6. Complete Syntax for the .lveco File
ECOGateInstancePrefix : LVECO<N>_ ;
ScanChainPorts {
SI: <PathToPort>;
SO: <PathToPort>;
June 2014
}
}
}
ScanChainPorts {
SI: <PathToPort>;
SO: <PathToPort>;
}
}
}
Action (Connect) {
SourcePort: <Path>;
Gate (<GateType>) {
ID: <ID>;
ReuseGateID: <ID>;
SourcePort: <Path>;
Gate (<GateType>) {
ID: <ID>;
ReuseGateID: <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
Gate (<GateType>) {
ReuseGateID: <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
}
UseSpare {
}
}
}
UseSpare {
}
}
}
UseSpare {
}
June 2014
}
}
SourcePort: <Path>;
Gate (<GateType>) {
SourcePort: <Path>;
Gate (<GateType>) {
ID: <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
Gate (<GateType>) {
ID: <ID>;
SourcePort: <Path>;
SourcePort: <Path>;
}
UseSpare {
}
}
}
}
}
UseSpare {
}
}
...
}
}
...
TestPointRemoval {
Action (Connect) {
ID: <ID>;
ReuseGateID: <ID>;
}
}
}
Descriptions of the wrappers and properties available within the .lveco file are located in the
following sections.
ECOGateInstancePrefix
June 2014
ECOGateInstancePrefix
The .lveco file contains one ECOGateInstancePrefix property. The ECOGateInstancePrefix
property specifies the prefix text string to use when new combinational gates are inserted for the
LV-ECO edits. The purpose of this property is to allow multiple LV-ECO edits to be applied on
the same netlist. A unique ECOGateInstancePrefix property is automatically selected by
ruleAnalyze to ensure that no name collision can occur when new gates are created.
Syntax
This property syntax is as follows:
ECOGateInstancePrefix : <string> ;
where <string> can be any text string as long as it complies with the HDL identifier naming
requirements.
Default Value
The default is LVECO<N>_ where N can be an integer starting from 0. The ruleAnalyze tool
automatically selects a prefix which is not used by any current instance in your design.
Usage Conditions
Typically, you do not need to modify this property created by ruleAnalyze. You would only use
this property if you would like to use your own naming convention for newly created ECO
gates. However, you must be careful not to use a prefix which might collide with an existing
instance in your design or an instance created by a prior LV ECO process.
Example
The following example specifies that the prefix ECO123_ should be prepended to the
instance name of any new gates created by ecoGenerate.
Configuration (core) {
ECOGateInstancePrefix: ECO123_ ;
Related Information
None
ScanFlipFlop (<PathToFlop>)
June 2014
The .lveco file can contain one or more ScanFlipFlop wrapper. One ScanFlipFlop wrapper is
generated for a flip-flop that requires some LV-ECO edits.
Typically one ScanFlipFlop wrapper is created for each flip-flop. The only exception is when
an existing scan flip-flop must be moved from its current scan chain to another scan chain. For
such LV-ECO edit, two ScanFlipFlop wrappers will be created for the flip-flop: one to remove
the flip-flop and one to insert the flip-flop in the new scan chain.
Syntax
This wrapper starts as follows:
where PathToFlop identifies the scan flip-flop with its instance name.
Default Value
None
Usage Conditions
You do not need to add, remove or move this wrapper when the .lveco file is created by
ruleAnalyze.
Example
The following example specifies that the scan flip-flop blocka/scan_reg must be disconnected
from its current scan chain.
ScanChainPorts {
SI: blocka/scan_reg/SI;
SO: blocka/scan_reg/Q;
}
NextSIPort: blocka/scan_reg_1/SI;
}
}
Note
Note that names for <PathToPort> in the SI and SO properties must be specified using
/.
Related Information
ScanChainPorts Action
ScanChainPorts
June 2014
ScanChainPorts
The ScanChainPorts wrapper is used to perform the RemoveFromScanChain and
InsertInScanChain actions. The ScanChainPorts wrapper contains two properties: SI (scan
input) and SO (scan output). These properties specify the scan input and scan output ports of the
scan flip-flop. Note that a PD flip-flop will have the SI property pointing to input 1 of the
holding multiplexer and not the SI port on the flip-flop itself.
Syntax
The syntax for this wrapper is as follows:
ScanChainPorts {
SI: <PathToPort>;
SO: <PathToPort>;
}
The SI property specifies the scan input port.
The SO property specifies the scan output port.
Default Value
None
Usage Conditions
This property is only required when the RemoveFromScanChain and/or the InsertInScanChain
Action wrappers are present.
Example
The following example specifies scan input and scan output ports of the scan flip-flop
blocka/scan_reg.
ScanFlipFlop (blocka/scan_reg_1) {
ScanChainPorts {
SI: blocka/scan_reg_1/SI;
SO: blocka/scan_reg_1/Q;
}
}
}

Note
Note that names for <PathToPort> in the SI and SO properties must be specified using
/.
Related Information
ScanFlipFlop (<PathToFlop>) Action (InsertInScanChain)
ScanChainPorts
June 2014
Action (RemoveFromScanChain)
Action
June 2014
Action
The ScanFlipFlop wrapper can contain one or more Action wrappers. There are four valid
types for the Action wrapper:
RemoveFromScanChain specifies that the flip-flop is to be removed from its current scan
chain. Refer to Action (RemoveFromScanChain).
InsertInScanChain specifies that the flip-flop is to be inserted into a pre-existing scan
chain. Refer to Action (InsertInScanChain).
Connect defines the connection required for a specific input port associated with the flip-
flop. Refer to Action (Connect).
Intercept defines the signal interception required for a specific input port or output port
associated with the flip-flop. Refer to Action (Intercept).
Each Action wrapper describes a specific edit operation that must be performed on the scan flip-
flop in question. The operations associated with the Action wrapper are applied to the scan flip-
flop in the sequence they appear within the ScanFlipFlop (<PathToFlop>) wrapper.
The usage conditions for each action type are described in the following sections starting with
Action (RemoveFromScanChain).
You never need to add, remove or move the action wrapper when the .lveco file is created by
ruleAnalyze.
Default Value
None
Usage Conditions
The usage conditions for each action type are described in the following sections starting with
Action (RemoveFromScanChain).
Example
Examples for each kind of the Action wrapper are included in the following sections starting
with Action (RemoveFromScanChain).
Related Information
Action (RemoveFromScanChain) Action (Connect)
Action (InsertInScanChain) Action (Intercept)
June 2014
The Action (RemoveFromScanChain) wrapper allows you to specify that the flip-flop is to be
removed from its current scan chain.
Syntax
The syntax for the Action wrappers for the RemoveFromScanChain action type is as follows:
}
where the NextSIPort property specifies the scan path reconnection point after the flip-flop is
removed.
Default Value
None
Usage Conditions
These usage conditions apply to the Action (RemoveFromScanChain) wrapper:
This wrapper must have one NextSIPort property. You never modify this property as it
specifies the flip-flop that immediately follows the current flip-flop in the scan chain. The
ecoGenerate tool uses this information to reconnect the scan chains with the current flip-flop
bypassed.
This wrapper requires ScanFlipFlop (<PathToFlop>) wrapper to be defined.
The Action (RemoveFromScanChain) wrappers are specified in a separate ScanFlipFlop
wrapper from the Action (InsertInScanChain) for the same scan flip-flop. Furthermore, the
all remove action wrapper is listed at the listed at the beginning of the .lveco file.
Example
This example specifies that the flip-flop removed from the existing internal scan chain.
ScanChainPorts {
}
}
}
Related Information
Action (InsertInScanChain)
June 2014
The Action (InsertInScanChain) wrapper is used to specify that the flip-flop is to be inserted
into a pre-existing scan chain.
Syntax
The syntax for the Action wrappers for the InsertInScanChain action type is as follows:
}

where the NextSIPort property specifies the a port on the scan chain where the flip-flop is to be
inserted. Note that the NextSIPort property always needs to point to the SI port of a flop that is
already a part of a scan chain. SD ports of loose flops cannot be added.
Default Value
None
Usage Conditions
These usage conditions apply to the Action (InsertInScanChain) wrapper:
This wrapper must have one NextSIPort property. You can modify this value by
substituting it with another compatible scan insertion point. You get the list of compatible
insertion points from the .ecoinfo file created by ruleAnalyze. For details on how to use this
file, refer to Customizing the Post-ECO Netlist. You select a compatible insertion point that
minimizes the routing requirements of the scan chain. You only do this when you want to do
a layout ECO without scan chain re-ordering.
This wrapper requires ScanChainPorts wrapper to be defined.
Each Action wrapper describes a specific edit operation that must be performed on the scan
flip-flop in question. The operations associated with the Action wrappers are applied to the
scan flip-flop in the sequence they appear within ScanFlipFlop (<PathToFlop>) wrapper.
Example
This example specifies that the flip-flop is to be inserted in the existing internal scan chain just
before the flip-flop blocka/scan_reg_1.
ScanChainPorts {
}
}
}
Related Information
ScanFlipFlop (<PathToFlop>) Syntax for .ecoinfo Input File
June 2014
ScanChainPorts
Action (Connect)
June 2014
Action (Connect)
The Action (Connect) wrapper is used to define the connection required for a specific input port
associated with the flip-flop in the following ways:
Specify a name of the input port using the DestinationPort property.
Connect any port to a specific signal using the SourcePort property or connect the input port
to the output of a new gate using the Gate wrapper.
Syntax
The syntax for the Action wrappers for the Connect action type is as follows:
Action (Connect) {
SourcePort: <Path>;
Gate (<GateType>) {
}
}

The DestinationPort property is used to specify a input port name associated with the
flip-flop. Any pre-existing connection to the specified DestinationPort is removed.
The SourcePort property is used to specify a path to a pre-existing output port name. The
output port specified by the SourcePort property is connected to the input port specified by
the DestinationPort property.
The Gate wrapper is used to specify a gate that connects to the specified
DestinationPort. Valid GateTypes are as follows: MUX, OR2, OR3, AND2, AND3, INV,
TIEHIGH, TIELOW, NOR2, NOR3, NAND2, and NAND3.
Default Value
None
Usage Conditions
These usage conditions apply:
You use either the SourcePort property or the Gate wrapper.
Table E-2 provides information on valid PortFunctions for different gate types.
Table E-2. Valid PortFunctions by GateType
GateType Valid PortFunctions
MUX Input0, Input1, Select
OR2 Input0, Input1
OR3 Input0, Input1, Input2
AND2 Input0, Input1
Action (Connect)
June 2014
Example
This example specifies that the input port blocka/new_reg/SM is to be driven by a two input
OR gate.
Action (Connect) {
Gate (OR2) {
Port (Input0) {
}
Port (Input1) {
SourcePort: LV_CD_0;
}
}
}
}
Related Information
AND3 Input0, Input1, Input2
INV Input
TIEHIGH
TIELOW
NOR2 Input0, Input1
NOR3 Input0, Input1, Input2
NAND2 Input0, Input1
NAND3 Input0, Input1, Input2
Action Gate (<GateType>)
Table E-2. Valid PortFunctions by GateType (cont.)
Action (Intercept)
June 2014
Action (Intercept)
The Action (Intercept) wrapper is used to define a gate interception for a specific input port or
output port associated with the flip-flop. Either a DestinationPort or a SourcePort property
must be specified to denote an input port or an output port to be intercepted. The Intercept
action involves the inserting of a gate between the specified DestinationPort and the net that
originally drove the destination port, or between the specified SourcePort and the net that
originally was driven by the source port. The interception is always done using the unspecified
port function within the Gate wrapper. For example, if the Input0 port function is specified
within a Gate(OR2) wrapper, then the interception is performed between Input1 and output port
of the OR gate.
Syntax
The syntax for the Action wrappers for the Intercept action type is as follows:
SourcePort: <Path>;
Gate (<GateType>) {
}
...
}
}
The DestinationPort property is used to specify a input port name associated with the
flip-flop.
The SourcePort property is used to specify a input port name associated with the flip-
flop.
The Gate wrapper is used to specify a gate to perform the interception. Valid GateTypes
are as follows: MUX, OR2, OR3, AND2, AND3, INV, NOR2, NOR3, NAND2, and NAND3.
The PreserveConnection wrapper is used when the Intercept action is on SourcePort,
and it is required to preserve some of the original fanout of the source port. This wrapper is
used to identify the fanout branch(es) from SourcePort where the interception should NOT
be applied. The fanout branches are identified using one or more DestinationPort properties
defined within the PreserveConnection wrapper.
Default Value
None
Action (Intercept)
June 2014
Usage Conditions
Table E-3 provides information on valid PortFunctions for different gate types.
Example 1
This example specifies that the input port blocka/scan_reg/SM is to be driven by a two-input
OR gate, and that the Input0 of the OR gate is to be driven by the net originally driving
blocka/scan_reg/SM.
Gate (OR2) {
Port (Input0) {
SourcePort: LV_CD_1;
}
}
}
}
Table E-3. Valid PortFunctions by GateType
MUX One of (Input0, Input1, Select)
OR2 One of (Input0, Input1)
OR3 Two of (Input0, Input1, Input2)
AND2 One of (Input0, Input1)
AND3 Two of (Input0, Input1, Input2)
INV
NOR2 One of (Input0, Input1)
NOR3 Two of (Input0, Input1, Input2)
NAND2 One of (Input0, Input1)
NAND3 Two of (Input0, Input1, Input2)
Action (Intercept)
June 2014
Example 2
This example specifies that an OR gate on the scan output is injected to mask all paths except
the scan path.
SourcePort: blocka/scan_reg/Q;
Gate (OR2) {
Port (Input1) {
SourcePort: LV_TM;
}
}
DestinationPort: blocka/scan_reg_1/SI;
}
}
}
Related Information
Action Gate (<GateType>)
Gate (<GateType>)
June 2014
Gate (<GateType>)
The Gate wrapper is used to describe the driver that drives the destination port or the input ports
of other Gate wrappers. There can be up to three levels for the Gate wrapper inside the Action
wrapper:
At the first and second levels, you choose to drive each port of the gate either with another
gate or with SourcePort.
The ports of the third level of Gate can only be connected to SourcePort.
By default, ruleAnalyze -mode ECO always instantiates a separate Gate wrapper for every gate
that is needed to correct the post-functional ECO netlist. You might notice that some Gate
wrappers in two different ScanFlipFlop (<PathToFlop>) wrappers are of identical type, and
each port connects to the same source. The ruleAnalyze tool does not re-use a Gate wrapper
because it is missing the physical layout perspective to know if it would be better to use the
same gate or not for two different connections. If you find that it would be better to share the
same gate, you can edit the .lveco file to specify a gate reuse.
Syntax
The syntax for the Action: Gate wrapper is as follows:
Action (Connect) {
SourcePort: <Path>;
Gate (<GateType>) {
ID: <ID>;
ReuseGateID: <ID>;
SourcePort: <Path>;
Gate (<GateType>) {
...
}
UseSpare {
}
}
}
}
}

You can specify a gate reuse using the following the following syntax in the Gate wrapper:
Table E-3 shows the pin functions you need to specify for each gate type. You can point to a 3-
input spare AND even within a Gate (And2) wrapper. You simply point to the first two inputs as
the third input is already tied to a logic 1.
<gateType>
Table E-3 shows the pin functions you need to specify for each gate type. You can point to a
3-input spare AND even within a Gate (And2) wrapper. You simply point to the first two
inputs as the third input is already tied to a logic 1.
Gate (<GateType>)
June 2014
ID: <id>;
For the first instance of the Gate wrapper you want to share for multiple connection, you
give it a unique id using the ID property. The id can be any arbitrary string.
ReuseGateID: <id>;
For every other instance of the Gate wrapper you want to share, you delete the entire content
of the Gate wrapper and specify the ReuseGateID property with the id matching ID that you
want to re-use.
The most likely gates you want to re-use are tied cells. Those are sourcing static signals so
you can easily share them if the routing allows it.
UseSpare wrapper
If you are following a metal-only layout ECO process, and you already have instantiated
spare gates in your netlist, you can specify the UseSpare wrapper to instruct ecoGenerate to
make connections to your existing cell instead of instantiating a new gate. It is assumed that
your spare gates are tied off as specified in Performing Your Functional ECO.
Usage Conditions
A maximum of three levels of the Gate wrapper nesting is supported.
Example
The following example shows the scan enable port SCAN of the scan_3_reg flip-flop controlled
by the logical ORing of three input signals. The control logic is constructed by cascading two 2-
input OR Gate wrappers.
Action (Connect) {
DestinationPort: coreInstance/scan_3_reg_0/SCAN;
Gate (OR2) {
Port (Input0) {
Gate (OR2) {
Port (Input0) {
SourcePort: coreInstance/LV_testmode;
}
Port (Input1) {
SourcePort: coreInstance/LV_SE_CK1_ext;
}
}
}
Port (Input1) {
SourcePort: coreInstance/LV_SE_CK1_ext;
}
}
}
Related Information
Action ScanFlipFlop (<PathToFlop>)
TestPointRemoval
June 2014
TestPointRemoval
The TestPointRemoval wrapper contains the action necessary to remove the testpoints that were
automatically found by ruleAnalyze -mode ECO run along the critical paths you specified in the
file pointed to by the -criticalPaths runtime option. You do not need to edit this wrapper except
for possibly declaring the spare gate to use for the tie cell. You can also reuse one tie cell from
one Action wrapper to the other.
The action used to remove a testpoint from a critical path consists of connecting the input of the
testpoint gate to its inactive value, i.e. the value that is present during the functional mode. Once
this is done, you can take your netlist through an incremental optimization. The effects of the
testpoint on the critical path will be removed. Most testpoints have no impact on critical path
timing if incremental optimization was performed on the netlist after the testpoints were
inserted. You consider removing the testpoint from the critical path only in rare cases where this
incremental optimization failed to restore the timing slack on a given critical path.
Syntax
This wrapper syntax is as follows:
TestPointRemoval {
Action (Connect) {
ID: <id>;
ReuseGateID: <id>;
UseSpare {
Port (Output): <HierarchicalPortName>;
}
}
}
}

where the above criteria present the following:
//Comments that provide information about critical paths from where testpoints must be
removed. This information is extracted from the critical paths file and filled in by the
ruleAnalyze tool.
Action (Connect) wrapperdefines the connection required for a specific testpoints to be
tied off.
o Specifying a name of the input port to be tied off using the DestinationPort
property.
o Connecting the input port to the output of a tied off cell using the Gate wrapper.
For a typical AND cell on the critical path, ruleAnalyze would specify the full path to the
testpoint-only input port of the AND cell as DestinationPort and TIEHIGH as the type of
gate that drives the inactive value to this input.
For detailed information on this wrapper contents, refer to Action (Connect).
TestPointRemoval
June 2014
Default Value
None
Usage Conditions
The information in the TestPointRemoval wrapper is filled in during the ruleAnalyze run
with -mode ECO if you specify the -criticalPaths runtime option.
If multiple testpoints are cascaded behind a single gate, all those testpoints are removed.
Note that this will have an impact on fault coverage.
If no testpoints are found on a specified path in the critical paths file, ruleAnalyze generates
a warning to such effect.
Example
The following example shows how the input A1 of a functional gate U3/U7 is tied to 0 as it has
been identified as a testpoint along a specified critical path. Instead of instantiating a new
TieHigh cell, the ReuseGateID property is specified to share the output of an existing one.
TestPointRemoval {
// From: U3/DFF1;
// To: U3/U8/DFF5;
Action (Connect) {
DestinationPort: U3/U7/A1;
Gate (TieHigh) {
ReuseGateID: TIE1;
}
}
}
Related Information
Action Managing Your ECO Process
Action (Connect) ruleAnalyze Input File for ECO Process
-criticalPaths and -mode in the manual
ETAnalysis Tools Reference
TestPointRemoval
June 2014
Syntax for .ecoinfo Input File
The .ecoinfo file helps you to choose a different NextSIPort inside the Action
(InsertInScanChain) wrapper of the .lveco file. You can choose any other entry listed in the
NextSIPortList wrapper within the same ScanChainGroup wrapper of the .ecoinfo file. You
choose any entry that is closest and with minimal impact on routing.
Figure E-7 presents the complete syntax for the .ecoinfo file. The information you use to choose
for the .lveco file in marks in brown.
Figure E-7. Complete Syntax for the .ecoinfo File
ScanChainGroup {
MCP: 1 | 2 | 3 | 4 | False;
InternalCD: <N>;
ExternalCD: <N>;
ScanChain {
Length: <integer>;
NextSIPortList {
<PathToNextSIPort>;
...
}
}
...
}
The following sections describe in detail wrappers and properties of the .ecoinfo file.
ScanChainGroup
June 2014
ScanChainGroup
The .ecoinfo file might contain one or more ScanChainGroup wrappers. Each
ScanChainGroup wrapper might contain one or more ScanChain wrappers. A
ScanChainGroup identifies the scan chains and the scan insertion points for each scan chain
which have compatible properties.
Syntax
The syntax for the ScanChainGroup wrappers is as follows:
ScanChainGroup {
MCP: 1 | 2 | 3 | 4 | False;
InternalCD: <N>;
ExternalCD: <N>;
ScanChain {
Length: <integer>;
NextSIPortList {
<PathToNextSIPort>;
...
}
}
...
}
Default Value
None
Usage Conditions
None
Example
This example provides a list of available SI ports for two scan chains that belong to the same
scan chain group.
ScanChainGroup {
ClockDomain: CLKA;
MCP: 1;
Periphery: Yes;
ScanChain {
Length: 98;
NextSIPortList {
blocka/scan_0/SI;
blocka/scan_1/SI;
...
}
}
ScanChain {
Length: 100;
NextSIPortList {
ScanChainGroup
June 2014
...
}
}
}
Related Information
ruleAnalyze Input File for ECO Process
June 2014
ruleAnalyze Input File for ECO Process
The ruleAnalyze tool uses the critical paths file as an input when run with -mode ECO. The
purpose of this file is to specify the paths from which testpoints should be removed.
Syntax for Critical Paths File
The critical paths file is an input to ruleAnalyze when the tool is run with -mode ECO. This file
contains information about critical paths in your design from where the testpoints need to be
removed. The ruleAnalyze tool analyzes the circuits to identify any testpoints flops directly
controlling the input of a multi-input gate in the specified paths. The results of this analysis are
reported in the TestPointRemoval wrapper of the ruleAnalyze output file.lveco. Later, the
ecoGenerate tool will remove these testpoints from the post-ECO netlist.
The critical path file has syntax as follows:
<from port path> <to port path>;
This syntax is used to specify pairs of paths from which the testpoint gate(s) need to be
disconnected. You create this ruleAnalyze input file following these rules:
The levels of hierarchy is determined by /.
The first part of the pair must specify a top-level input port, or a complete path to the output
of a logic gate or flop.
The second part of a pair must specify a top-level output port, or a complete path to the input
of a logic gate or flop.
Multiple path pairs can be specified with each pair terminated by a semi-colon.
Comments in the critical paths file are allowed. A line starting with the # character
renders the entire line a comment. Empty lines are allowed as well.
To specify the critical paths file for the ruleAnalyze run with -mode ECO, you use the runtime
option -criticalPaths <designName> where designName is a path to the file containing the
critical paths in the design.
The following example shows a specification of three critical paths:
topLevelInputPort /top/block/subblk2/tf2/D;
/top/block/subblk3/ff2/Q /top/block/subblk2/tf4/D;
/top/block/subblk5/ff3/Q topLevelOutputPort;
Related information
TestPointRemoval Managing Your ECO Process
ruleAnalyze Runtime Options in the manual
ETAnalysis Tools Reference
Runtime Options for ECO Process
June 2014
This section describes all available runtime options for ecoGenerate that are used for managing
your ECO process.
Section topics follow this sequence:
-config. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
-configFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
-define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
-defineFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
-extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
-HDLwarningFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
-incDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
-language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
-log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
-lvlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
-modifiedExtension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
-outDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
-r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
-y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
-yvhdl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
The ecoGenerate tool modifies the post-ECO netlist to prevent violation of the LogicVision
design rules. The new design files are written with the extension <modifiedExtension>
appended to preserve the original design files.
The complete syntax for running ecoGenerate from the command line is as follows.
June 2014
ecog
ecog -help
ecog <designName> <sourceFileName1>
<sourceFileName2>...
-config <configurationName>
-define <macroName>
-HDLwarningFilter Off | Low | (High)
-language (Verilog) | VHDL
-log <fileName>
-lvlib <lvlibFileName>
-r <topModuleName>
-yvhdl <vhdlLibraryName>
Valid values for command-line options are case-insensitive.
In the syntax above, designName specifies the prefix for all generated intermediate files and
serves as default configuration file prefix, and sourceFileName specifies Verilog file that
describes a design block.
Specifying the -help option displays a summary of the command-line syntax and usage. Typing
ecog without any parameters also displays this summary.
Descriptions of the runtime options available for ecoGenerate are located on the following
pages.
-config
June 2014
-config
The -config option specifies a top-level VHDL configuration declaration for the circuit. This
option provides an alternative means of specifying the top-level VHDL entity/architecture pair
of a design.
Syntax
The following syntax specifies this option:
-config <configurationName>
where configurationName is a VHDL identifier.
Default Value
None
Usage Conditions
You cannot use -config with the -r option.
Example
The syntax below instructs ecoGenerate to use the defg configuration declaration for the design.
ecog top top.vhds -config defg
Related Information
Identifiers -r
-configFile
June 2014
-configFile
The -configFile option enables you to specify an alternative configuration file to be used
instead of default <designName>.lveco.
Syntax
where configFileName can be any identifier that is a valid operating system filename.
configFileName might include path information as well.
Default Value
The default value is <designName>.lveco.
Usage Conditions
None
Example
This example instructs ecoGenerate to read the specified configuration file designA.lveco.
ecog myDesignA -configFile designA.lveco
Related Information
Identifiers
-define
June 2014
-define
The -define option defines a macro name (as empty text) that remains in scope throughout the
analysis of every Verilog design file. You can reference this macro in one or more Verilog
source files.
Syntax
-define <macroName>
where macroName is a valid Verilog character string.
Default Value
None
Usage Conditions
The -define option is similar to a define line in a design file because it allows 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 allows 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.
ecog myConfig myDesign.v -define NOCHECKS
Related Information
Identifiers -defineFile
-defineFile
June 2014
-defineFile
The -defineFile option specifies the name of a file containing macro definitions that remain in
Syntax
where defineFileName is a valid operating system file name.
Default Value
None
Usage Conditions
The following usage conditions apply:
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
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 via the -define
option).
If defineFileName is specified as a relative path, it is assumed to be relative to the directory
in which you invoked ecoGenerate.
The -defineFile option can be specified multiple times.
Example
In the following example, the configuration file is top.lveco. The circuit file is myDesign.v, and
the file myDefines.v contains the global macro definitions.
ecog top.lveco 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.
Related Information
-define
-extension
June 2014
-extension
The -extension option specifies the list of library directory file extensions for Verilog. Within a
given library directory ecoGenerate tries to resolve a module name by sequentially looking up
file names composed of the module name, a dot, and each extension specified with this option
(i.e. <moduleName>.<extension>). This option is required whenever a library directory is
specified.
Syntax
where each extension is a valid file extension.
Default Value
None
Usage Conditions
These usage conditions apply to -extension:
This option is required whenever you specify a library directory with the -y option.
Use colons (:) to separate multiple extensions.
Do not supply the period (.) separating the extension from the file name.
Example
The following syntax instructs ecoGenerate to use the extensions scan and vb1 when searching
files within the Verilog library directory lib1.
ecog top coreBlock.v -y lib1 \
-extension scan:vb1
Related Information
Identifiers -y
-HDLwarningFilter
June 2014
-HDLwarningFilter
The -HDLwarningFilter option specifies which level of messages are filtered during an
ecoGenerate run.
Syntax
-HDLwarningFilter Off | Low | (High)
where valid values are as follows:
Offindicates that no messages are filtered during an ecoGenerate run.
Lowindicates that unimplemented RTL warning messages occurring during compilation
of VHDL packages are not filtered.
Highindicates 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.
ecog top coreBlock.v -HDLwarningFilter Off
Related Information
None
-incDir
June 2014
-incDir
The -incDir option specifies the name of a directory to be searched in resolving Verilog include
file names.
Syntax
where includeDirectoryName is a valid operating system directory name.
Default Value
None
Usage Conditions
The following usage conditions apply:
If includeDirectoryName is specified as a relative path, it is assumed to be relative to the
directory in which you invoked ecoGenerate.
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.lveco. The circuit file is myDesign.v, and
the -incDir option is specified twice:
ecog top.lveco 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.
Related Information
None
-language
June 2014
-language
The -language option controls whether ecoGenerate generates Verilog code for the design
objects. Default file extension is .vb.
Syntax
-language (Verilog)
Default Value
The default value is Verilog.
Usage Conditions
None
Example
The following syntax instructs ecoGenerate to read in the input files and to generate Verilog
descriptions for the ecoGenerate design objects.
ecog top top.v -language Verilog
Related Information
-extension
-log
June 2014
-log
The -log option specifies the name of the log file generated by ecoGenerate.
Syntax
-log <fileName>
where fileName is a valid operating system filename.
Default Value
The default file name is ecog.log.
Usage Conditions
These usage conditions apply for -log:
If you do not specify a log file using the -log option, then ecoGenerate writes the log file to
the output directory specified using the -outDir option as <outputDirectory>/ecog.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 the -outDir option. 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 ecoGenerate and generates a log file, ecog_Run1.log in the out1 directory.
ecog myDesign.v -log ecog_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
ecog myDesign ./chiptesta.log
ecog myDesign -outDir out out/chiptesta.log
ecog myDesign -log mylog ./mylog
ecog myDesign -outDir work \
-log ../logdir/mylog ../logdir/mylog
ecog myDesign -outDir work work/mylog
-log mylog
Related Information
Identifiers -outDir
-lvlib
June 2014
-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.
Syntax
-lvlib <lvlibFileName>
where lvlibFileName can be any absolute or relative path name that is a valid operating system
path specification.
Default Value
When defined, the following three lvlib files are always read by ecoGenerate prior to reading
lvlib files specified on the command line with the -lvlib option runtime option:
LogicVision-defined default $LVLIBHOME/lvlib describes IEEE and Synopsys libraries.
Other lvlib files can override definitions in these 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
LogicVision 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
If you have a pure VHDL design or a mixed HDL design that contains Verilog and VHDL, you
need to create an lvlib file.
Example
The file ./myLvlibFile is a VHDL library description file that contains the following text:
topLib => ./top_out
extLib => ./ext_out
topLib <= ./*.vhd ./*.vhds
extLib <= ./ext/*.vh ./ext/*.vhd
work := topLib
In the following syntax example, ./myLvlibFile is the name of the lvlib file that ecoGenerate
uses. myDesign.vhds refers to the file describing the circuit design.
ecog top myDesign.vhds -lvlib ./myLvlibFile
-lvlib
June 2014
Related Information
Identifiers
-modifiedExtension
June 2014
-modifiedExtension
The -modifiedExtension option specifies the extension that ecoGenerate appends to output files
containing the top-level assembly of the chip and the generated design objects.
Syntax
where modifiedExtension is a valid operating system character string.
Default Value
The default for -modifiedExtension is _bta.
Usage Conditions
Do not confuse -modifiedExtension option with the -extension option:
The -extension option specifies the extensions that ecoGenerate checks when searching
design files.
The -modifiedExtension option specifies the extension that ecoGenerate appends to the
modified output netlist filenames.
Example
This syntax example adds the extension _a to ecoGenerate output files.
ecog myPLL myDesign.v -modifiedExtension _a
Related Information
Identifiers -extension
-outDir
June 2014
-outDir
The -outDir option identifies the directory in which ecoGenerate places all of its output files for
the design objects.
Syntax
The syntax for this option is as follows:
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 ecoGenerate.
Usage Conditions
If you specify a directory that does not exist, ecoGenerate creates the directory.
Example
In this syntax example, ecoGenerate creates the directory Run1 and stores all ecoGenerate
output files in Run1.
ecog top design/top.v -outDir Run1
Related Information
-log
-r
June 2014
-r
The -r option specifies the name of the top-level Verilog module declaration of the design.
Syntax
-r <topModuleName>
where topModuleName is a Verilog identifier.
Default Value
If you do not specify either the -r option or the -config option, the first module or entity
declaration name located in the source files specified on the command line is used as the top.
The ecoGenerate tool searches these source files from left to right.
Usage Conditions
These usage conditions apply to -r:
You cannot use -r with -config.
topModuleName must refer to a module 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.
ecog top top.v -r blocka
Related Information
Identifiers -config
-v
June 2014
-v
The -v option adds the name of a Verilog library file to the search path that ecoGenerate uses for
resolving names appearing in Verilog modules.
Syntax
where libraryFileName is a valid operating system file name.
Default Value
None
Usage Conditions
These usage conditions apply to -v:
The ecoGenerate tool resolves names in module instantiation statements by searching
through libraries specified with the -v, -yvhdl, and -y options in the order in which they are
specified; that is, ecoGenerate searches from first to last, or left to right, on the command
line.
In a library file, all modules in the file are potential candidates for resolving a name
appearing in Verilog modules.
ecoGenerate accepts multiple library file names. Precede each file name with the -v option.
Unless you specify a directory path preceding libraryFileName, ecoGenerate searches for
the specified file in the directory in which you invoked ecoGenerate.
Example
In this example, ecoGenerate loads the source file top.v and searches the library file block1.vb
for any unresolved name bindings.
ecog top top.v -v block1.vb
Related Information
Identifiers -yvhdl
-y
-y
June 2014
-y
The -y option adds the name of a Verilog library directory to the search path that ecoGenerate
uses for resolving names appearing in Verilog modules.
Syntax
where libraryDirectoryName is a valid operating system directory name.
Default Value
None
Usage Conditions
These usage conditions apply to -y:
If you are using LogicVision tools for scan test and/or logic BIST, you must specify -y to
point to the location where you ran the Prepare Logic Flow on each of your core modules.
This points ecoGenerate to the .scaninfo file generated by ruleAnalyze during the Prepare
Logic Flow phase.
Names in module instantiation statements are resolved by searching through libraries
specified with the -v, -yvhdl, 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, ecoGenerate first checks for a
match with a Verilog or LogicVision primitive. If no match is found, the tool checks the
other modules in the file for a potential match. If there is no match, then ecoGenerate checks
the source files followed by the normal library search.
The ecoGenerate tool accepts multiple library directory names. Precede each directory name
with the -y option.
You must use the -extension option in conjunction with this option.
A library directory file should contain at least one module or UDP; it may contain a
complete hierarchy as long as its top module has the same name as the file.
Examples
In the following example, the -y option is specified twice.
ecog top top.v -y ./mySource \
-y ./myLibrary -extension v:vb
The ecoGenerate tool resolves names in the circuit file top.v by searching directories in the
following order:
-y
June 2014
mySource
myLibrary
When ecoGenerate searches these library directories, the tool fist looks for files with the
extension .v, then for files with the extension .vb.
The next example combines the -v and -y options. The module top is the designs top-level
module and must reside in top.v.
ecog top top.v -v mod1.v -y ./
-extension v:vb
Names in top.v and mod1.v are resolved by first checking for matches with a Verilog or
LogicVision primitive.
If no match is found, ecoGenerate searches for a match in the source file top.v.
If no match is found in top.v, ecoGenerate searches the library file mod1.v. All modules in
mod1.v are visible.
If no match is found in mod1.v, ecoGenerate scans the library directory ./. Only modules
whose names are the same as the file in which they reside are visible when searching./.
The ecoGenerate tool resolves names appearing in files in the library directory ./ by first
checking for a match with a Verilog or LogicVision primitive. If no match is found,
ecoGenerate searches within the files local hierarchy for an embedded module. If there is no
match, then ecoGenerate checks the source files followed by the normal library search.
Related Information
Identifiers -v
-extension -yvhdl
-yvhdl
June 2014
-yvhdl
The -yvhdl option adds the name of a VHDL logical library to the search path that ecoGenerate
uses for resolving names appearing in Verilog modules. This feature permits binding Verilog
module instances to VHDL entity declarations.
Syntax
-yvhdl <vhdlLibraryName>
where vhdlLibraryName is a VHDL logical library name.
Default Value
None
Usage Conditions
These usage conditions apply to -yvhdl:
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 ecoGenerate 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 designs top-level module or design entity. It must reside in top.v or
in the library which is designated as WORK in the lvlib file $project/lvlib.project.
ecog top top.v \
-r top \
-v mod1.v \
-yvhdl extLib \
-lvlib $project/lvlib.project

The ecoGenerate tool resolves names in Verilog files as follows:
-yvhdl
June 2014
It first checks for a match with a Verilog or LogicVision primitive.
If no match is found, ecoGenerate 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, ecoGenerate checks the VHDL library extLib. All VHDL design
entities from extLib are searched in a case-insensitive manner.
The ecoGenerate tool resolves names in VHDL files by searching the VHDL libraries specified
in the appropriate use clauses. (For a detailed discussion of how ecoGenerate resolves VHDL
names, refer to lvlib VHDL library file.)
Related Information
Identifiers -y
-lvlib -v
Output Files for ECO Process
June 2014
This section describes the output files created during ECO process.
Section topics follow this sequence:
ecoGenerate Output Files
The ecoGenerate tool outputs LV post-ECO netlist files with the ECO edits required to make
your design logic test compliant.
ruleAnalyze Generated .lveco File
The ruleAnalyze tool creates the .lveco file in the current working directory to be used by the
ecoGenerate tool. This file is created during ruleAnalyze run with -mode ECO. The ruleAnalyze
tool checks the post-ECO netlist to determine what edits are required to prevent violation of the
LogicVision design rules. The .lveco file outlines the edits that are required.
Detailed information on .lveco file syntax is provided in ecoGenerate Input Files.
The following sections provide examples for various types of post-ECO edits.
Example 1
DescriptionA new flip-flop cannot be inserted into an existing scan chain.
ActionIsolate the flip-flop from test.

SourcePort: blocka/new_reg/Q;
Gate (OR2){
Port (Input1){
SourcePort: LV_TM;
}
}
}
}
June 2014
Example 2
DescriptionA new flip-flop needs to be inserted into an internal scan chain. The flip-flop
is a normal scan flip-flop.
ActionInsert the flip-flop into a pre-existing scan chain and connect the scan enable.

ScanChainPorts {
}
}
Action (Connect) {
}
}
Example 3
DescriptionA new flip-flop needs to be inserted into an internal scan chain. The flip-flop
is a receive (RX) flip-flop on capture group 1.
ActionInsert the flip-flop into a pre-existing scan chain and connect the scan enable to an
OR gate.

ScanChainPorts {
}
}
Action (Connect) {
Gate (OR2) {
Port (Input0) {
SourcePort: LV_CD1;
}
Port (Input1) {
}
}
}
}
June 2014
Example 4
DescriptionA new flip-flop needs to be inserted into a periphery scan chain. The flip-flop
is an input periphery flip-flop. The flip-flop is a TX flop on capture group 0 in internal test
mode. The flip-flop is a TX flop on capture group 2 in external test mode.
ActionInsert the flip-flop into a pre-existing periphery scan chain, connect the scan enable
to an OR gate, and inject a holding mux on the scan in.
ScanChainPorts {
}
}
Action (Connect) {
Gate (OR3) {
Port (Input0) {
SourcePort: LV_testmode;
}
Port (Input1) {
SourcePort: blocka/LV_SE_CLKA_F1_ext;
}
Port (Input2) {
SourcePort: blocka/LV_CD2_ext;
}
}
}
DestinationPort: blocka/new_reg/SI;
Gate (MUX) {
Port (Input0) {
SourcePort: blocka/new_reg/Q_net;
}
Port (Select) {
Gate (OR2) {
Port (Input0) {
Gate (AND2) {
Port (Input0) {
}
Port (Input1) {
SourcePort: blocka/LV_testmode;
}
Port (Input1) {
SourcePort: blocka/LV_SE_CLKA_F1_ext;
}
}
}
}
}
June 2014
Example 5
DescriptionA pre-existing scan flip-flop needs to be changed from a normal scan flip-flop
to a receive (RX) flip-flop on capture group 0.
ActionInject a spare OR gate on the existing scan enable path.

Action (Connect) {
Gate (OR2) {
Port (Input0) {
SourcePort: LV_CD0;
}
Port (Input1) {
}
}
UseSpare {
Port (Input0): blocka/spare_or2_1/A;
Port (Input1): blocka/spare_or2_1/B;
Port (Output): blocka/spare_or2_1/Y;
}
}
}
Example 6
DescriptionA pre-existing scan flip-flop needs to be changed from a normal scan flip-flop
to a transmit (TX) flip-flop on capture group 0.
ActionInject an OR gate on the existing scan enable path, and inject a MUX on the
existing scan in path.

Action (Connect) {
Gate (OR2) {
Port (Input0) {
SourcePort: LV_CD1;
}
Port (Input1) {
}
}
DestinationPort: blocka/scan_reg/SI;
Gate (MUX) {
Port (Input0) {
}
Port (Select) {
}
}
June 2014
}
Example 7
DescriptionA pre-existing scan flip-flop needs to be moved from an MCP1 scan chain to
an MCP2 scan chain.
ActionRemove a flip-flop from the existing MCP1 scan chain, insert a flip-flop into the
existing MCP2 scan chain, connect a frequency 2 scan enable to scan enable port, and inject
MUX on the scan in the port for the MCP hold.

ScanChainPorts {
SI: blocka/scan_reg/SI;
SO: blocka/scan_reg/Q;
}
}
}
Action (Connect) {
}
DestinationPort: blocka/scan_reg/SI;
Gate (MUX) {
Port (Input0) {
SourcePort: blocka/scan_reg/Q_net;
}
Port (Select) {
SourcePort: blocka/LV_CE_CLKA_F2;
}
}
}
}
Example 8
DescriptionA pre-existing scan flip-flops output must be masked such that only the shift
path remains.
ActionInject an OR gate on the scan output to mask all paths except the scan path.

June 2014
Gate (OR2) {
Port (Input1) {
SourcePort: LV_TM;
}
}
DestinationPort: blocka/scan_reg_1/SI;
}
}
}
ruleAnalyze Generated .ecoinfo File
The ruleAnalyze tool creates the .ecoinfo file in the LV_WORKDIR directory. This file is
created during ruleAnalyze run with -mode ECO. The .ecoinfo file is an informational file that
helps you to choose a different NextSIPort inside the Action (InsertInScanChain) wrapper of
the .lveco file. You can choose any other entry listed in the NextSIPortList wrapper within the
same ScanChainGroup wrapper of the .ecoinfo file. You choose any entry that is closest and
within minimal impact on routing.
Figure E-7 presents the sample .ecoinfo file.
June 2014
Figure E-8. Sample .ecoinfo File
ScanChainGroup {
ClockDomain: CLKA;
MCP: 1;
Periphery: Yes;
ScanChain {
Length: 98;
NextSIPortList {
blocka/scan_0/SI;
blocka/scan_1/SI;
...
}
}
ScanChain {
Length: 100;
NextSIPortList {
...
}
}
}
ScanChainGroup {
ClockDomain: CLKA;
MCP: 2;
InternalCD: 1;
Periphery: No;
ScanChain {
Length: 50;
NextSIPortList {
blocka/io_reg_0/SI;
blocka/io_reg_2_pdmux/B;
...
}
}
}
June 2014
Appendix F
Formal Verification with Embedded Test
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
README File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Preparing for Formal Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Generating and Editing the Formal Verification Files. . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Formal Verification User Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Formal Verification Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Performing Formal Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Final RTL vs. Customer Golden Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Pre-Scan vs. Post-Scan Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Pre-Layout vs. Customer Golden Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Pre-Layout Netlist vs. Post-Layout Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Checking Formal Verification Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Overview
This appendix describes support for Formal Verification with Synopsys Formality. You can
perform functional equivalency checking of a netlist before and after the insertion of Mentor
Graphics Embedded Test. Formality scripts are generated using ETPlanner and during
ETAssemble execution. In order to provide complete Formal Verification of the design, these
scripts can be included as part of the functional Formal Verification scripts.
Note
This chapter is not a substitute for the Formal Verification manuals. It is expected that
you are familiar with the Formality tool and its use model.
The tasks involved in preparing for and performing Formal Verification are as follows:
Task 1 Preparing for Formal Verification. You edit the ETPlanner configuration file
to add the FormalityLibFile property.
Task 2 Generating and Editing the Formal Verification Files. You perform the
following two tasks:
Overview
June 2014
o The Formal Verification user file templates are created during Step 2: ETPlanner of
the LV Flow. You then edit these files, if necessary, using the information provided
in each file header.
o When ETAssemble is run, the .fms constraint scripts are created.
These files serve as input to Task 3.
Task 3 Performing Formal Verification. Depending on where you are in the LV Flow,
you can perform different kinds of Formal Verification, comparing different netlists.
Task 4 Checking Formal Verification Results. You verify the results of your Formal
Verification by checking various log files.
These tasks are described in the sections following Figure F-1 that shows when you perform
Formal Verification during the LV Flow. To simplify the explanation of these tasks versus the
LV Flow they are labeled in the figure. Note that you can run several tasks one after another.
For example, you can run Task 2 and 3 in Step 3: ETAssemble, or Task 2, 3, and 4 in Step 4:
ETScan and Pre-Layout ETSignOff of the LV Flow.
Overview
June 2014
Figure F-1. Formal Verification Tasks During the LV Flow
Preparing for Formal Verification
June 2014
README File
In addition to this document and the Formality tool manuals, you can use the README file as
guideline for Formal Verification. Once the FormalityLibFile property has been added to the
ETPlanner configuration file, the README file includes additional information explaining
when to execute the Formal Verification.
Preparing for Formal Verification
For Task 1, you activate the Formal Verification feature via ETPlanner by adding the
FormalityLibFile property in the ETPlan: ICTechnology wrapper of the ETPlanner
configuration file.etplan. The FormalityLibFile property syntax is as follows:
ETPlan (<designName>) {
ICTechnology (<VendorLibID>) {
FormalityLibFile
(<LibID>): <HierFilePath>;
}
}

LibID refers to the unique names that you assign to your file library.
HierFilePath is a Synopsys technology library file named <Technology ID>.db.
Generating and Editing the Formal Verification
Files
In the first task, you edited the ETPlanner configuration file to add the FormalityLibFile
property. In this task, you generate the following files:
Formal Verification User Files You first run ETPlanner to create the Formal
Verification user file templates. You then edit these files if necessary, using the
information found in each file header.
Formal Verification Constraint Files When ETAssemble is run, the .fms constraint
scripts are created.
Once the files are created and have been edited appropriately, you can move onto Performing
Formal Verification.
Generating and Editing the Formal Verification Files
June 2014
Formal Verification User Files
ETPlanner creates a set of Formal Verification (FV) user file templates with the following
naming convention:
<moduleName>_<type>_user.fms.
where type can have one of the following values, depending during which step of the LV Flow
the file was generated:
etassemble Generated during the ETAssemble step and used in the
Final RTL vs. Customer Golden Netlist Formal Verification.
prepost_scan Generated during the ETScan step and used in the
Pre-Scan vs. Post-Scan Netlist Formal Verification.
scaninsert Generated during the Pre-Layout ETSignOff step and used in the
Pre-Layout vs. Customer Golden Netlist Formal Verification.
prepost_layout Generated during the Final ETSignOff step and used in the
Pre-Layout Netlist vs. Post-Layout Netlist Formal Verification.
You must edit these files based on the information contained in each file header prior to running
Formal Verification. It is required to specify the reference or implemented design file, the
blackox file name, or module name.
Once the Formal Verification user files have been generated and edited, you can proceed with
Task 3Formal Verification Constraint Files.
User File Example
Figure F-2 shows a <module name>_etassemble_user.fms file with the typical constraint file
format for a TOP level when there is a legacy core and block. You must follow the instructions
in the header to edit the file.
Figure F-2. Sample file - ETAssemble/<moduleName>_etassemble_user.fms
#############################################
# IMPORTANT CHANGES YOU MUST MAKE #
#############################################
#
# Perform the following mandatory changes
# to the "Reference Design" and "Implemented
# Design" sections by defining the fields:
#
# <Golden module Netlist>
# List all modules Gate or RTL files
# required to create the car
# golden net list i.e. Original design
# net list without any BIST. When
# having design, the golden
June 2014
# net list
# When a design includes embedded
# core, it is recommended to create
# the golden net list without the
# embedded core in order to minimize
# useless golden netlist size and
# formality tool execution. However,
# you need to manually create for each
# embedded core a black box and add the
# appropriate black box declarations.
# The embedded core formal verification
# check is done in each embedded core
# ETSignOff.
#
# <ETAssemble output module Netlist>
# List all files required to create the
# final RTL with all embedded test logic
# (ETAssemble output) netlist
#
#############################################
#
# ****************************
# * Select environment setup *
# ****************************
#
setup
#
# ******************************
# * Design and black box setup *
# ******************************
#
# ====================
# = Reference Design =
# ====================
#
read_verilog -container r -libname WORK {
<Golden Module Netlist>
../../../dashboard_LVWS/ETAssemble/outDir/dashboard.emptyShell

../../../ENGINE_PROJECT/engine_COLLAR.lvdb_updated50/engine_COLLAR.scan_s
hell
}
#
read_db -container r {
../../../Dolphin/FormalVerLib
../../../Dolphin/FormalVerMem_128x8_16ww1x
../../../Dolphin/FormalVerMem_8kx32_16ww1x
}
#
set_black_box r:/WORK/dashboard
set_black_box r:/WORK/engine_COLLAR
#
set_top r:/WORK/car
#
# ======================
June 2014
# = Implemented Design =
# ======================
#
read_verilog -container i -libname WORK {
<ETAssemble output module Netlist>
../../../dashboard_LVWS/ETAssemble/outDir/dashboard.emptyShell

../../../ENGINE_PROJECT/engine_COLLAR.lvdb_updated50/engine_COLLAR.scan_s
hell
}
#
read_db -container i {
../../../Dolphin/FormalVerLib
../../../Dolphin/FormalVerMem_8kx32_16ww1x
}
#
set_black_box i:/WORK/dashboard
set_black_box i:/WORK/engine_COLLAR
#
set_top i:/WORK/car
#
#
# *********************************
# * Enable Design Functional Mode *
# *********************************
#
source ./car_funcmode.fms
#
# ******************************
# * Constant propagation setup *
# ******************************
#
# Please uncomment the following line when using
# an older version of the formality tool that does
# not support the new property replacement
# verification_assume_const_reg_init
#
# set verification_assume_const_reg_init true
#
set verification_assume_reg_init liberal
#
# ************************
# * Compare both designs *
# ************************
#
verify
#
# ********************
# * Exit script mode *
# ********************
#
#start_gui
exit
#
June 2014
Formal Verification Constraint Files
Once the Formal Verification user files have been generated and edited, you must generate
Formal Verification constraint files. The following Formal Verification constraint files are
created during the ETAssemble step:
ETAssemble/outDir_fv/<moduleName>_funcmode.fms
This file contains the necessary constraints to enable the functional mode. It is used
during Final RTL vs. Customer Golden Netlistand Pre-Layout vs. Customer Golden
Netlist Formal Verification tasks that compare the customer golden netlist against
intermediate netlists created during the LV Flow.
ETSignOff/outDir_fv/<moduleName>_disable_scanchains_and_tps.fms
This file contains all necessary constraints to enable the pre-scan, post-scan, and layout
checks. The constraints contained in this file disable all scan chains, testpoints, and
logicTest controllers. This prevents verification failure resulting from scan re-ordering.
This file is used in the following types of Formal Verification: Pre-Layout vs. Customer
Golden Netlist and Pre-Layout Netlist vs. Post-Layout Netlist.
Once the Formal Verification constraint files have been generated, you are ready to move to
Task 3Performing Formal Verification.
Figure F-3 and Figure F-4 show examples of the Formal Verification constraint files generated
the ETAssemble step.
Figure F-3. Sample File - ETAssemble/outDir_fv/<moduleName>_funcmode.fms
#########################################################################
#####
#
# Formality script: enables the functional circuitry
#
#########################################################################
#####
#
# Reference design constraints
#
set_constant -type port r:/WORK/car/TRST 0
#
# Implemented design constraint
#
set_constant -type port i:/WORK/car/TRST 0
#
# Legacy Core External Ports Constraints
#
set_constant -type port r:/WORK/car/engine_INST/TCK 0
set_constant -type port i:/WORK/car/engine_INST/TCK 0
#
set_dont_verify_point -type port r:/WORK/car/engine_INST/LV_SI0_ck100_ext
set_dont_verify_point -type port i:/WORK/car/engine_INST/LV_SI0_ck100_ext
#
June 2014
set_dont_verify_point -type port
r:/WORK/car/engine_INST/LV_SI1_ck100_MCP2_ext
i:/WORK/car/engine_INST/LV_SI1_ck100_MCP2_ext
#
set_dont_verify_point -type port r:/WORK/car/engine_INST/LV_SI_ck33_ext
set_dont_verify_point -type port i:/WORK/car/engine_INST/LV_SI_ck33_ext
#
r:/WORK/car/engine_INST/LV_CD_CK100MHz_ext
i:/WORK/car/engine_INST/LV_CD_CK100MHz_ext
#
set_dont_verify_point -type port r:/WORK/car/engine_INST/LV_CD0_ext
set_dont_verify_point -type port i:/WORK/car/engine_INST/LV_CD0_ext
#
r:/WORK/car/engine_INST/engine_COLLAR_AUX_SI[0]
i:/WORK/car/engine_INST/engine_COLLAR_AUX_SI[0]
#
#
Figure F-4. Sample File - ETSignOff/outDir_fv
<moduleName>_disable_scanchains_and_tps.fms
#########################################################################
#####
#
# Formality script: Disable all scan chains and test points
#
#########################################################################
#####
#
# Reference design constraints
#
set_dont_verify_point -type port r:/WORK/car/dashboard_INST/LV_CD[0]
set_dont_verify_point -type port r:/WORK/car/dashboard_INST/LV_CD[1]
#
set_dont_verify_point -type port r:/WORK/car/dashboard_INST/LV_SI[0]
#
set_constant -type port
r:/WORK/car/LVISION_JTAP_INST/LVISION_JTAP_EXT_SIG/BIST_EN0 0
r:/WORK/car/LVISION_JTAP_INST/LVISION_JTAP_DR_CTRL/INT_DR_LATCH[0] 0
#
r:/WORK/car/LVISION_JTAP_INST/LVISION_JTAP_IR_REG/INSTR[12] 1
#
# Implemented design constraints
#
set_dont_verify_point -type port i:/WORK/car/dashboard_INST/LV_CD[0]
set_dont_verify_point -type port i:/WORK/car/dashboard_INST/LV_CD[1]
Performing Formal Verification
June 2014
#
set_dont_verify_point -type port i:/WORK/car/dashboard_INST/LV_SI[0]
#
i:/WORK/car/LVISION_JTAP_INST/LVISION_JTAP_EXT_SIG/BIST_EN0 0
i:/WORK/car/LVISION_JTAP_INST/LVISION_JTAP_DR_CTRL/INT_DR_LATCH[0] 0
#
i:/WORK/car/LVISION_JTAP_INST/LVISION_JTAP_IR_REG/INSTR[12] 1
#
# Legacy Core External Ports Constraints
#
set_constant -type port r:/WORK/car/engine_INST/TCK 0
set_constant -type port i:/WORK/car/engine_INST/TCK 0
#
set_dont_verify_point -type port r:/WORK/car/engine_INST/LV_SI0_ck100_ext
set_dont_verify_point -type port i:/WORK/car/engine_INST/LV_SI0_ck100_ext
#
r:/WORK/car/engine_INST/LV_SI1_ck100_MCP2_ext
i:/WORK/car/engine_INST/LV_SI1_ck100_MCP2_ext
#
set_dont_verify_point -type port r:/WORK/car/engine_INST/LV_SI_ck33_ext
set_dont_verify_point -type port i:/WORK/car/engine_INST/LV_SI_ck33_ext
#
r:/WORK/car/engine_INST/LV_CD_CK100MHz_ext
i:/WORK/car/engine_INST/LV_CD_CK100MHz_ext
#
set_dont_verify_point -type port r:/WORK/car/engine_INST/LV_CD0_ext
set_dont_verify_point -type port i:/WORK/car/engine_INST/LV_CD0_ext
#
#
#
In the previous Formal verification tasks, you generated and edited the Formal Verification user
and constraint files necessary for running different kinds of Formal Verification.
In this task, you execute specific make targets corresponding to the type of Formal Verification
that you wish to perform. Formal Verification performs the specified comparison to ensure that
the addition of Embedded Test has not affected your design.
June 2014
You can perform the following types of Formal Verification:
Final RTL vs. Customer Golden Netlist This type of Formal Verification is
performed during the ETAssemble step.
Pre-Scan vs. Post-Scan Netlistand Pre-Layout vs. Customer Golden Netlist These
types of Formal Verification are performed during the ETScan step.
Pre-Layout Netlist vs. Post-Layout Netlist This type of Formal Verification is
performed during the ETSignOff step.
Note
You must execute the make targets specifically. Formal Verification does not run
automatically.
For more information about running make targets, refer to Inserting and Verifying Embedded
Test.
Once you have performed the required Formal Verification, you can check the results in the log
files that are output from each type of Formal Verification. This task is described in Checking
Formal Verification Results.
Final RTL vs. Customer Golden Netlist
You can compare the final RTL with all embedded test logic netlist (output by ETAssemble)
against the customer golden netlist. This type of Formal Verification is done during the
ETAssemble step, by executing the fv_postETAvsGolden make target.
Input Files
The following input files are used in this type of Formal Verification:
<moduleName>_etassemble_user.fms
This file contains the necessary constraints for executing Formal Verification on the
final RTL with all embedded test logic (ETAssemble output) netlist against the customer
golden netlist. You must edit this file to specify the following:
o All files required to build the customer golden netlist and ETAssemble output
netlist.
o All additional necessary blackboxes.
outDir_fv/<moduleName>_funcmode.fms
This file is sourced by the <moduleName>_etassemble_user.fms file while executing
the fv_postETAvsGolden make target. For more information, refer to Generating and
Editing the Formal Verification Files.
June 2014
Output Files
When you perform this type of Formal Verification, the following files are generated in the
ETAssemble directory:
outDir_fv/fv_post_eta_vs_golden.log
This file contains the results of your Formal Verification. For more information on
checking this log file, refer to Checking Formal Verification Results.
outDir_fv/post_eta_vs_golden_formality.log
This file is a copy of the Formality log created by the Formality tool.
outDir_fv/post_eta_vs_golden_fm_shell_command.log
This file is a copy of the fm_shell_command.log file.
Pre-Scan vs. Post-Scan Netlist
You can compare the pre-scan (post-ETAssemble) netlist against the post-scan (pre-layout)
netlists. This type of Formal Verification is done using the fv_preLayoutVsPostETA make
target.
This type of Formal Verification is performed during the ETScan step.
Input Files
<moduleName>_prepost_scan_user.fms This file contains guidelines for performing
Formal Verification on the pre-scan (post-ETA) netlist against the post-scan (pre-layout)
netlists. You must edit this file to specify the following:
o The files required to build the pre-scan netlist.
o Any additional necessary black boxes.
/outDir_fv/.<moduleName>_disable_scanchains_and_tps.fms This file is sourced by
<moduleName>_etassemble_use.fms while performing a pre-scan vs. post-Scan netlist
Formal Verification. For more information, refer to Generating and Editing the Formal
Verification Files.
Output Files
When you perform a pre-scan vs. post-scan Formal Verification, the following files are
generated in the ETScan directory:
outDir_fv/fv_pre_layout_vs_post_eta.log
June 2014
This file contains the results of the pre-scan vs. post-scan Formal Verification. For more
information on checking this log file, refer to Checking Formal Verification Results.
outDir_fv/fpre_layout_vs_post_eta_formality.log
outDir_fv/pre_layout_vs_post_eta_fm_shell_command.log
This file is a copy of the fm_shell_command.log.
June 2014
Pre-Layout vs. Customer Golden Netlist
You can compare the pre-layout netlist (the output of ScanInsert) against the customer golden
netlist. This type of Formal Verification is done using the fv_preLayoutVsGolden make
target.
This type of Formal Verification is performed during the ETScan step.
Input Files
<moduleName>_scaninsert_user.fms
This file contains guidelines for executing Formal Verification on the pre-layout netlist
(the output of ScanInsert) against the customer golden netlist. You must edit this file to
specify the following:
o All files required to build the customer golden netlist.
o All additional necessary black boxes.
ETAssemble/outDir_fv/<moduleName>_funcmode.fms
This file is sourced by the <moduleName>_etassemble_user.fms file while comparing a
pre-layout netlist vs. customer golden netlist. For more information, refer to Generating
and Editing the Formal Verification Files.
Output File
When you compare the pre-layout netlist and the customer golden netlist, the following files are
generated in the ETScan directory:
outDir_fv/fv_pre_layout_vs_golden.log
This file contains the results of Formal Verification. For more information on checking
this log file, refer to Checking Formal Verification Results.
outDir_fv/pre_layout_vs_golden_formality.log
outDir_fv/pre_layout_vs_golden_fm_shell_command.log
Checking Formal Verification Results
June 2014
Pre-Layout Netlist vs. Post-Layout Netlist
You can compare the pre-layout against a post-layout netlist. You perform this comparison
using the fv_preVsPostLayout make target.
This type of Formal Verification is performed during the Final ETSignOff step.
Input Files
The following input files are used:
<moduleName>_prepost_layout_user.fms
This file contains guidelines for completing the setup prior to executing Formal
Verification on the pre-layout against the post-layout netlist. You must edit this file to
specify all blackboxes.
<moduleName>_disable_scanchains_and_tps.fms
This file contains all necessary constraints to enable the pre-scan, post-scan, and layout
checks. The constraints contained in this file disable all scan chains, test points, and
logicTest controllers. This prevents verification failure resulting from scan reordering.
Output Files
When you compare the pre-layout netlist and the post-layout netlist, the following files are
generated in the ETSignOff directory:
outDir_fv/fv_pre_vs_post_layout.log
This file contains the results of Formal Verification. For more information on checking
this log file, refer to Checking Formal Verification Results.
outDir_fv/prepost_layout_formality.log
outDir_fv/prepost_layout_fm_shell_command.log
To check the result of Formal Verification, you view the following log files:
fv_post_eta_golden.log
fv_pre_layout_vs_post_eta.log
June 2014
fv_pre_layout_vs_golden.log
fv_pre_vs_post_layout.log
Search for the Verification Results section. You should see the keyword Verification
SUCCEEDED when the both implemented and reference designs are equivalent. However, it is
recommended to check each log file in its entirety in order to ensure that there are no
undesirable warnings.
Figure F-5 presents the sample Verification Results section:
Figure F-5. Sample Verification Results
* Verification Results *
Verification SUCCEEDED
Reference design: r:/WORK/myDesign
Implementation design: i:/WORK/myDesign
194 Passing compare points
----------------------------------------------------
Matched Compare Points BBPin Loop Net BlPin Port DFF LAT TOTAL
----------------------------------------------------
Passing (equivalent) 0 0 0 0 0 13 181 0 194
Failing (not equivalent) 0 0 0 0 0 0 0 0 0
Not Compared
Unread 0 0 0 0 0 7 0 7
June 2014
Appendix G
Adding Embedded Boundary Scan Into Your
Design
This appendix provides an overview of the steps required to add boundary-scan cells directly
into any core containing I/O cells.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Embedded Boundary Scan Insertion Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Recursive Integration and Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Changes to ETCreate Block/ELTCore Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Performing Stand-Alone Verification of Custom Embedded BScan Cells. . . . . . . . . . . 333
Introduction
Increasingly, chip I/O cells are being placed directly into cores in order to be closer to the logic
they service. This approach typically results in significant physical design benefits including
reduced signal routing and improved timing. Mentor Graphics embedded boundary scan
feature allows boundary scan cells to be integrated alongside their associated I/O cells within
the core rather than at the top level of the chip. Boundary scan cells can be added to any core at
any level within a design. A three -level example is shown in Figure G-1.
The embedded boundary scan feature automates both the integration of the boundary scan cells
and verification of the resulting boundary scan segment within the core.
This approach not only maintains and extends the physical design benefits of placing I/O cells
directly into cores, but also enables a more efficient core re-use methodology as all design and
DFT sign-off activity can take place fully at the core level.
The embedded boundary scan feature is also fully integrated with Mentor Graphics' ETLogic

logic BIST solution and further simplifies the integration of logic BIST into cores containing
embedded I/Os.
Adding Embedded Boundary Scan Into Your Design
Embedded Boundary Scan Insertion Flow
June 2014
Figure G-1. Boundary-Scan Cell Integration
Within the normal chip or block flow, ETPlanner creates an .etassemble configuration file to be
used as input to ETAssemble and allows you to instruct the tool on how you want any
embedded test capabilities configured and integrated into your design. Adding embedded
boundary scan to a core is performed outside this normal flow, however, and ETAssemble is
used as a point tool. You start by using ETAssemble to generate a Makefile with available
targets to generate and verify your embedded boundary scan implementation (refer to Figure G-
2 on page 328) as well as a starter .etassemble file and simScript. You create these templates
using the following syntax:
etassemble <designName> -genTemplate On \
-CADEnvFile <cadEnvFile> \
-etDefFile <etDefFile> \
-ICTechFile <ICTechFile>
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 tthe
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.
June 2014
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.
The generated <block>.etassemble file is shown in Figure G-3. For detailed information on the
properties used within this file, refer to .etassemble Configuration File of the ETAssemble
Reference manual.
The generated simScript is shown in Figure G-4. It is used to fully certify the implemented
boundary-scan segment at the core level. There is no need to wait until top-level integration
with a TAP to simulate and sign off the embedded boundary scan segment. For detailed
information on the properties used within this file, please refer to section TAP Verification
Section of the ETVerify Reference manual.
Before running make bscan (see the list of Make targets below), note that the default for the
RTLEditingEngine property is Incore (legacy editing engine). If you wish to run ETAssemble
with the HDLE editing engine or with auto uniquification enabled, add the following to the
.etassemble file:
EmbeddedTest {
AutoUniquify : AllEditedModules;
RTLEditingEngine : HDLE;
}
For more information about when to use the HDLE editing engine, refer to the LV Flow
Migration to Tessent Editing Engine appendix.
June 2014
Figure G-2. Generated Files When Using -genTemplate On
June 2014
Figure G-3. Sample ETAssemble Starter Template for Embedded Boundary
Scan Flow
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 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.
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;
}
EmbeddedBScanPortNaming {
// <FunctionName>: <pinName>;
ForceDisable: ForceDisable;
ClockBscan: ClockBScan;
UpdateBScan: UpdateBScan;
ShiftBScan: ShiftBScan;
ShiftBScan2Edge: ShiftBScan2Edge;
SelectJtagInput: SelectJtagInput;
SelectJtagOutput: SelectJtagOutput;
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 ELT core 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
June 2014
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>, ...];
ExternalAuxOutPins: <OutputPinName> [<OutputPinName>, ...];
}
}
Figure G-4. Generated .etEarlyVer File
etv (<designName>) {
JtagVerify (<designName>) {
PatternName: tapbistv_<designName>;
SimulationScript: <designName>_sim.script;
TCKPeriod: 100.0ns;
LVBScanFile: outDir/<designName>.lvbscan;
TestStep (Default) {
RunTest: BscanReg;
RunTest: Input;
RunTest: Sample;
RunTest: HighZ;
RunTest: Clamp;
RunTest: Output;
}
}
}
Recursive Integration and Verification Flow
The embedded boundary scan integration and verification process is fully recursive and can be
applied to any number of levels of hierarchy. An illustration of the recursive flow for the simple
design is provided in Figure G-5.
At each level (beginning with the lowest), ETAssemble is first run to insert the appropriate
embedded boundary scan cells and to generate a <blockModule>.lvbscan file which describes
the added boundary scan cells. This file then serves as input to ETVerify to drive verification, as
well as input to ETAssemble at the next level.
Changes to ETCreate Block/ELTCore Flow
June 2014
Figure G-5. Recursive Embedded Boundary Scan Flow
The ETCreate Block/ELTCore flow is fully compatible with the new embedded boundary scan
feature. The necessary flow steps needed to accommodate embedded boundary-scan segments
are shown in the flow diagram of Figure G-6.
June 2014
Figure G-6. ETCreate Flow for Cores with Embedded Boundary Scan
When going through the standard flow, you need to make the following modifications:
When you run ETChecker, use the -etcScanDataFile runtime option to point to the
<root>.etcScanData file created by ETAssemble when it was run to insert the
embedded boundary-scan cells (the <root>.etcScanData file is normally created by
ruleAnalyze in the bottom-up flow).
Make sure to not use either the lv.BoundaryScanInstance nor the lv.NonScanInstance
properties on the boundary-scan cells.
When you run ETAssemble, make sure you have the <root>.lvbscan file (created earlier
by ETAssemble when it was run to insert the embedded boundary scan cells) visible in
the design search path.
The <root>.etcScanData and <root>.lvbscan files can easily be hand-created for
blocks where the embedded boundary scan insertion was performed manually.
After completing the ELTCore flow with the above modifications, a cores embedded
boundary-scan segment will be connected to the logicTest controller as shown in Figure G-7.
During core-level internal test mode (INT_TM signal active), the embedded boundary-scan
segment is scanned by the logicTest controller and fully supports the Shared Isolation
technique. Therefore, it provides for full internal test coverage all the way to the boundary scan
flops.
During core-level external test mode (EXT_TM signal active), the boundary-scan segment
becomes part of the chip-level boundary-scan chain (including all controls) and forces constant
known values on the chip pins (the EXT_TM signal is ORed with the SelectJtagOutput signal).
For the rare case of a signal from an input pin captured by an embedded boundary-scan cell
feeding directly through the core, a DI cell is added on the corresponding core output port to
support the external test mode.
Performing Stand-Alone Verification of Custom Embedded BScan Cells
June 2014
Figure G-7. Embedded Boundary Scan Usage in ELT Core
Performing Stand-Alone Verification of
Custom Embedded BScan Cells
This section provides instructions on how to verify your custom embedded boundary-scan cells
when both boundary-scan insertion and .lvbscan file creation are not performed by the Tessent
EBScan flow.
Note
Support of custom boundary-scan cells is limited to those that have RTL similar to
boundary-scan cells generated by the Tessent EBScan flow. For details, see the Custom
Boundary-Scan Cell Support Limitations and Solutions section.
1. Bring both your netlist and your .lvbscan file into the same work directory. For the
purpose of this example, assume that your embedded boundary-scan design is named
block, and your netlist is named block_vb.
2. Run these commands:
etassemble block \
-genTemplate on \
-icTechFile <file_path> \
-cadEnvFile <file_path> \
-etDefFile <file_path>
June 2014
This creates the following files:
Makefile
block.etassemble
simScript
3. Create your block.etEarlyVer file. (In the standard embedded boundary-scan flow,
bscang normally creates this file.) Create your own copy from the following template:
etv (block) {
JtagVerify (block) {
PatternName: tapbistv_block; //test bench root name
SimulationScript: block_sim.script; //generated script file
TCKPeriod: 100.0ns;
LVBScanFile: block.lvbscan; //your .lvbscan file
TestStep (Default) {
RunTest: BscanReg;
RunTest: Input; //if your ebscan has input/observe_only/
//bidir cells
RunTest: Sample; //if your ebscan has input/observe_only/
//bidir cells
RunTest: HighZ; //if your ebscan has a forceDisable control
RunTest: Output; //if your ebscan has output/bidir cells
}
}
}
4. Create your block.f_bscan (verilog -f file for simulation).
5. Run this command:
make testbench
6. Modify your Makefile target block_sim; delete the line:
-y outdir/*.v
7. Run this command:
make sim
8. Create your block.etcScanData file for ETChecker at one level higher. You can use this
example:
# Define your clockBscan pin.
lv.ClockDomainBase -pin block.ClockBscan -frequency 100
-label clockBscan -bscan
# Those pins might bear other names in your .lvbscan file.
# Here, their names are self-documenting.
lv.Assert -pin block.ForceDisable -value 1 -bscan
lv.Assert -pin block.SelectJtagInput -value 1 -bscan
lv.Assert -pin block.SelectJtagOutput -value 0 -bscan
lv.Assert -pin block.ShiftBscan2Edge -value 0 -bscan
lv.Assert -pin block.UpdateBscan -value 1 -bscan
June 2014
lv.NonScanTestablePin -name block.BScanSI block.BScanSO -bscan
# List all your pad functional input/output pins.
lv.PadCell -name block -padIO A Y -bscan
# Declare your internal bscan cells this way (here, all bscan cells
# are contained within the bgroup instance named DEF):
lv.InternalScanInstance -name block.DEF
9. You can ignore the following Make targets:
bscan
block_compile
concatenated_netlist
Custom Boundary-Scan Cell Support Limitations
and Solutions
Support of custom boundary-scan cells is limited to those that have RTL similar to boundary-
scan cells generated by the Tessent EBScan flow. Specifically, they must include a retiming
flip-flop in their serial path, and their shift enable signal must be shiftBscan2Edge, NOT
shiftBscan. Currently, synchronous cells using a free-running TCK (test clock) are not directly
supported.
Although ETVerify cannot create a block-level test bench that verifies a non-compliant
embedded custom boundary-scan cell, ETVerify still, however, can test such a cell as part of its
chip-level JtagVerify test, with these stipulations: The cell is correctly connected to the Mentor
Graphics top-level TAP, and the cells .lvbscan file accurately describes its internal boundary-
scan registers with BSDLInfo wrappers. At the parent-level, you can write a Tessent Shell
script to perform the following:
1. Connect the cell's required control signals to the TAP, which has a variety of output
control signals from which to choose such as captureBscan, enableUpdateBscan, and
enableClkBscan.
2. If needed, instantiate a retiming flop before or after the cell, depending on the polarity of
your boundary-scan clock.
3. Instantiate any required custom mode-decoding logic in the cell's parent module. The
TAP controller provides the following mode-related signals:
selectJtagInput Active high during scan test
selectJtagOutput Active high during EXTEST and HIGHZ modes
forceDisable Active high during HIGHZ mode
June 2014
bscanOnly Active high for any TAP instruction that accesses the boundary-scan
register
All boundary-scan control signals that are not documented in this appendix can be omitted from
the .lvbscan file and connected with the above Tessent Shell script. Please consult with your
Mentor Graphics representative before starting such an implementation.
June 2014
Appendix H
Integrating Modules With Pre-Existing Scan
Chains
This appendix describes how to integrate the following types of objects with pre-existing non-
burst-ready scan chains into the LV Flow:
Legacy 4.x ELT core or block modules
Generic sub-block modules with third-party scan chains
Memories with internal scan logic such as scan chains
This appendix provides as well a detailed example on how to handle a memory with internal
scan logic.
Introduction of Hard Module Concept in ETChecker. . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Legacy 4.x ELT Core or Block Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Blocks With Third-Party Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Memories With Internal Scan Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Example Memory With Internal Scan Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Example Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Example Memory Library File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
ruleAnalyze Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Example of a Memory Within Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Introduction of Hard Module Concept in
ETChecker
A module with pre-existing scan chains is fixed (hard) as far as the LV Flow is concerned and
cannot be modified. This concept has always been well understood by the ETScan step but was
completely ignored by Step 1: ETChecker up until LV2005 Version 5.0b. This missing
concept in ETChecker could result in violations being incorrectly assumed to be fixable when in
fact you would find out during Step 3: ETAssemble or Step 4: ETScan and Pre-Layout
ETSignOff that the action needed to correct the violation would have to be done inside the hard
module. Then this required you to go back to the ETChecker step and to specify properties
such as lv.InjectControl to deal with the violations.
Integrating Modules With Pre-Existing Scan Chains
Introduction of Hard Module Concept in ETChecker
June 2014
An example of such situation, as illustrated in Figure H-1, is a flip-flop inside a hard module
which captures the output of a non-scan instance found outside the hard module. When
ETChecker sees this situation, it assumes that the flip-flop will be handled differently during the
ETScan step, and that it will be kept in shift mode even during the capture cycle in such a way
as not to be influenced by the unknown value coming from the non-scan instance. This
assumption is correct when the flip-flop is not within a hard module with pre-existing scan
chains. However, when the flip-flop is inside a hard module, ETScan is not able to modify the
scan circuitry and prevent the flip-flop from capturing the unknown.
Figure H-1. Illustration for Hard Module Concept
Starting with LV2005 Version 5.0b, ETChecker reads in an .etcScanData file for each hard
module with pre-existing scan chains. This .etcScanData file is generated by ruleAnalyze when
verifying the LogicTest compliance of the hard module. In the .etcScanData file, the hard
module is described as being hard to ETChecker which allows for proper handling. As can be
seen in the example .etcScanData file shown in Figure H-5, the syntax used to identify a
module as a hard module is the lv.HardModule property.
With the example situation described above, where a flip-flop inside a hard module captures the
output of a non-scan instance found outside the hard module, ETChecker now knows not to
assume the flip-flop will be isolated during ETScan. Instead, ETChecker will issue a
ScanRule_2 violation for the non-scan instance because it is observable by the flip-flop inside
the hard module, and there is no way to modify the scan chain to prevent it from capturing the
value from the non-scan flip-flop. Like with any other ScanRule_2 violations, you are provided
with an lv.InjectControl property inside the .etpInfoFixViolations File to auto-fix this violation
by inserting a control cell to control the net which is observed by the flip-flop inside the hard
module. It is exactly what you would have needed to do before Version 5.0b except that now the
violation is detected by ETChecker the first time, and you do not need to wait for the ETScan
step to find those issues.
Legacy 4.x ELT Core or Block Modules
June 2014
There are three types of objects which contain pre-existing scan chains that are not BurstMode-
ready. Those are:
Blocks With Third-Party Scan Chains
Memories With Internal Scan Logic
The following sections describes how to generate an .etcScanData file for them and how to
easily handle them during the entire LV Flow.
A legacy ELT core or block is a module that has an embedded test inserted in it with
embeddedTest Version 4.x. Such ELT core and block modules can easily be reused in a LV2005
chip. You simply need to add an .etcScanData file to their existing LVDB directory and point
the LVDB directory with ETChecker using the -lvdbDir option.
The following steps are all that is needed to handle legacy ELT core or block modules:
1. Add an .etcScanData file to the LVDB Version 4.x using the following commands:
rulea <legacyLVDB>/core_collar.scan_shell\
-overrides <legacyLVDB>/core_collar.rulea_ext \
-y <myLibDir> -extension <mylibext> \
-burstReady Off
cp core__collar.etcScanData <legacyLVDB>/LV_WORKDIR

Note
Make sure that you do not use .rulea file in this step. Only .rulea_ext extension is used for
legacy ELTcore modules.
2. When you run ETChecker on the chip or block containing the legacy ELT core or block
module, point to the lvdb directory of the legacy ELT core or block module using
the -lvdbDir option. The .etcScanData file you placed inside the LVDB directory in Step
1 will automatically be read in by ETChecker, and it will know to treat it as a hard
module. For legacy ELT core modules, you do not need to provide its netlist to
ETChecker as it will automatically load the scan_shell found within the LVDB. You do
need to provide the complete netlist of legacy block modules.
3. Proceed with the rest of theLV Flow. The connection and test reuse of the legacy ELT
core or block will be transparent and fully automated.
June 2014
When you have a block with pre-existing chains that you want to integrate into logic test, you
must first run ruleAnalyze on the stand-alone block. This is to verify that the block is
compatible with Mentor Graphics logic test. Follow these steps:
1. Create the .rulea file and ruleAnalyze run-script. Here is an example of the run script:
rulea ../netlist/block.v \
-r block \
-y ../logicvision/scan_models \
-y ../verilog \
-extension scan:v \
-burstReady Off \
-viewer On \
-debugWarnings On \
-log rulea_block.log
For the .rulea file, you will need to define your clocks, scan enables, TestMode pins and
Asserts. Here is an example of a .rulea file:
ClockDomainBase (SYSCLK) {
Label: SYSCLK;
Polarity: ACTIVEHIGH;
Override: Both;
}
Testmode {
SCAN_MODE: 1;
}
Assert {
CLOCK_SEL: 1;
}
ScanEnable (SCAN_ENABLE) {
Polarity: ActiveHigh;
}
ScanChain {
ScanIn: i_scan_in1[start];
ScanOut: o_scan_out1[end];
}
The TestMode ports will automatically be forwarded to ETChecker in the generated
.etcScanData file. The Assert ports will not get forwarded to ETChecker. Asserts should
be used on clock select signals, and you must then manually add an lv.ETClockEnable
when running ETChecker.
Although, this is not a recommended approach, the clock select signal and scan mode
signal are often the same port on these blocks. If the clock select signal is also used as a
scan mode signal, then you should specify it as a TestMode instead of Assert when
running ruleAnalyze. The TestMode will then get forwarded automatically to
ETChecker, and the port will also need to be specified with an lv.ETClockEnable. The
reason it needs to be specified as both a TestMode and ETClockEnable is that
ETChecker will only assert TestMode or ETClockEnable for certain rules and checks.
June 2014
ETAssemble will only connect the port up to ETClockEnable since that will be asserted
in all cases.
Although not required, the ScanChain wrapper is very helpful for debugging when
ruleAnalyze traces the scan chains. The wrapper is repeatable for every start and end
point of a chain. With the ScanChain wrapper, ruleAnalyze reports errors if the chain
extraction fails. Without the ScanChain wrapper, ruleAnalyze tries to extract as many
scan chains as possible from pin to pin to infer what is scan and what is non-scan. Then
ruleAnalyze reports as non-scan any flip-flop that is not extracted as part of a scan chain.
Furthermore, ruleAnalyze may report errors or warnings that could be unclear to you.
For example, you may receive an error like this:
Error [ICRN17-03603582] : RULE 10 : The Non Scan flip-flop
'link_BL3.block1.Moon2.master_reg_0_' is not isolated from
testable logic.
Hint:
All Non Scan flip-flops must not be observable during test.
You must either manually isolate this flip-flop with testmode
or specify this flip-flop as a NonScanInstance with isolate=Yes
and rerun scanGenerate.
Or you may receive a warning like this:
Warning [GWRN00-00871326] : Inconclusive false path check
from 'link_BL3.block1.Moon2.master_reg_0_.SDFFRX2_inst_A1 (lv_ppi)
to ......
2. If the block passes the ruleAnalyze checks, an .etcScanData and .scandata file will get
generated. For ETChecker, you will need to add the runtime option -etcScanDataFile
and point to the .etcScanData files in your ETChecker runscript.
For running Tessent SoC, these files need to be put in a directory that will get read by
the tools. A good place to put them is your block netlist directory. You could also create
a directory called LV_files and put them there. You must then make sure to add the
LV_files directory as a ScanModelDir in your .LVICTech file for the LV Flow. The
.scandata file will be used by the tools that are run in the ETScan step. Make sure there
is a -y in the ETScan Makefile target for ruleAnalyze and scanGenerate that point to the
directory that contains the .scandata files.
The netlist for the block with pre-existing chains also needs to be included with a
SimModelDir, SimModelFile, or VerilogDashFFile in the .LVICTech file during Step 2:
ETPlanner so that the tools know where to pick up the netlist.
Some memories come equipped with internal scan logic which is reused during the logic test
modes. To have the scan logic properly understood and handled by the LV Flow, you perform
these steps:
Example Memory With Internal Scan Logic
June 2014
1. Run ruleAnalyze on the memory module with internal scan logic as was described in
Step 1 of the previous section. Point to the generated .etcScanData file during
ETChecker run and make sure the .scandata file is in the Verilog search path of
scanGenerate during the ETScan step.
2. Typically, memory modules are tested by memory BIST so you need to describe the
presence of the internal scan logic to ETAssemble. You do that using the following
properties in the .lvmemlib file of the memory:
TransparentMode : None;
ObservationLogic : On | Off;
InternalScanLogic : On;
You specify ObservationLogic to Off when flip-flops inside your memory which
observe the address and control signals are part of the scan chain. If they are not, then
specifying ObservationLogic to On will instruct ETAssemble to put an observation flip-
flop inside the memory collar.
3. Run the LV Flow as usual. Note the following minor differences:
During Step 1: ETChecker, point to the .etcScanData file of the memory containing
internal scan logic and to the .lvmemlib file which has the InternalScanLogic property
set to On. This will have the following impact on the ETChecker step:
o Memory modules with internal scan logic will not be black-boxed. It will bind your
supplied scan model of the memory modules.
o The .etcScanData file will declare the memory module as a hard module and will
instruct ETChecker to deal with it as a hard module as describe is section
Introduction of Hard Module Concept in ETChecker.
During Step 3: ETAssemble, the following will happen:
o Scan models for the memories with internal scan logic will not be created by
ETAssemble so that your scan model describing the internal scan logic is found
during ETScan.
o Note that starting with LV2005 Version 5.0b, the OE ports on the memory are no
longer forced off inside the memory BIST collar during scan unless
TransparentMode is used with tri-state mux. This only happens when
TransparentMode is specified as SyncMux, and your OE pins on the memory are not
tied on in the chip.
This section provides an example of a memory with internal scan logic, showing how it is made,
described in the .lvmemlib file, and used in the LV Flow.
June 2014
Example Memory
Figure H-2 provides the example of a memory with internal scan logic.
Figure H-2. Example Schematic View of Memory Model with Internal Scan Logic
There are flip-flops on the address, control and input data pins which are used during both the
functional operation mode of the memory and during scan. A bypass multiplexer is used to
bypass the memory core and drive the output data pins with the flip-flops used to sample the
input data pins. Note that the tri-state buffer is still after the bypass mux. It is your responsibility
to ensure the output enable is controllable during scan and fully decoded if multiple memories
are connected to the same bus. The majority of the time, the output enable signal is tied on in the
chip, and it will be left tied on during scan inside the collar starting with ETAssemble LV2005
Version 5.0b.
You need a scan model for your memory where the memory core logic is not visible to
ETChecker and ruleAnalyze. There are multiple advantages of sharing the same model for
simulation and the scan rule checking but the major one is that the parallel-load test benches
created from the information extracted by ruleAnalyze on the scan view can be used to simulate
with the real memory models including back-annotated timing.
There are several ways to achieve this objective:
The first one is illustrated with the example circuit shown in Figure H-2. Notice how the
memory core is inside a sub-module. If your Verilog model is separated in this way
where the logic that is also used in scan is in the top module, and the memory core is
June 2014
inside a sub-module, you can use the Verilog model as the scan model too. You declare
the memory core as a black box module, and its contents with behavioral code is
ignored during the ruleAnalyze run.
A second method that can be easily implemented for any memory model with limited
structure changes to your model is as follows:
a. Surround all behavioral code not related to the internal scan logic inside a compiler
directive like this:
ìfdef KeepInternalScanLogicOnly
èlse
<behavioral core here>
èndif

b. At the top of your model, add the following lines that will automatically define
KeepInternalScanLogicOnly when the model is loaded in ETChecker or
ruleAnalyze:
ìfdef LV_scanmodel
`define KeepInternalScanLogicOnly
èndif
ìfdef lv_rtl_primitives
`define KeepInternalScanLogicOnly
èndif
c. Finally, replace the RTL description of your flip-flops used to retime the input pins
with an instantiation of a flop module
Before:
always @(posedge clk) din_q = se ? {si, din_q[31:1]} : din;
After:
assign din_d = se ? {si, din_q[31:1]} : din;
<memModName>_FF din0 (.ck(clk), .d(din_d[0]),
.q(din_q[0]));
...
<memModName>_FF din31 (.ck(clk), .d(din_d[31]),
.q(din_q[31]));

and declare the <memModName>_FF definition at the bottom of the file below the
endmodule statement of the memory. Make sure to use the memory module name as
a prefix to the flop module name. That will ensure that the flop module name is
unique across all memory models.
module <memModName>_FF (ck, d, q);
input ck, d;
output q;
ìfdef LV_scanmodel
ìfdef gatedClock
lv_ppo gated_prim0 (d0);
lv_clockg_p gated_prim1 (ck);
LV_MUX gated_prim2 (.Y(d0), .A(q), .B(d), .S(ck) );
June 2014
èlse
lv_ppo A0 (d);
lv_clock_p A2 (ck);
èndif
lv_ppi A1 (q);
èlse
reg q;
always @ (posedge ck) q = d;
èndif
endmodule
June 2014
Example Memory Library File
Figure H-3 illustrates the memory library file for the example memory shown in Figure H-2. It
only shows a sub-set of the properties relevant to the internal logic. Notice the three properties
at the top which instruct the tools to insert neither transparent mode nor observation logic in the
collar, and that the memory has internal scan logic.
In the port description section, notice how the SI and SE ports are declared as LogicLow ports
and SO as an Open port. Finally, the port BYP is described as a ScanTest port.
Figure H-3. Example Memory Library File
MemoryTemplate (SYNC_1RW_16x8) {
TransparentMode: None;
ObservationLogic: Off;
InternalScanLogic: On;
Port (CLK){
Function: Clock;
}
Port (OE){
Function: OutputEnable;
}
Port (WE){
Function: WriteEnable;
}
Port (D[7:0]){
Function: Data;
Direction: Input;
}
Port (D[7:0]){
Function: Data;
Direction: Output;
}
Port (Q[7:0]){
Function: Data;
Direction: Input;
}
Port (A[3:0]){
Function: Address;
}
Port (BYP){
Function: ScanTest;
}
Port (SE){
Function: LogicLow;
}
Port (SI){
Function: LogicLow;
}
Port (SO){
Function: Open;
}
}
June 2014
ruleAnalyze Preparation
Figure H-4 illustrates the .rulea file that needs to be prepared for running ruleAnalyze on the
memory module with the internal scan logic. Notice how the memory core sub-module is
declared as a black box.
Figure H-4. Example SYNC_1RW_16x8.rulea File
ScanEnable (SYE) {
}
TestMode {
BYP: 1;
}
Module (SYNC_1RW_16x8_CORE){
Function: OutputEnable;
}
A successful run of ruleAnalyze on the SYNC_1RW_16x8.v file confirms that your memory is
logic test compliant and generates these files:
./SYNC_1RW_16x8.scandata
./SYNC_1RW_16x8.etcScanData
Figure H-5 shows the generated .etcScanData file that you would obtain for the memory
example shown in Figure H-2.
Figure H-5. The .etcScanData File for the Example Memory
//--------------------------------------
// This file created by: ruleAnalyze
// release: 5.0b-Build20060401.03
// Created on: 04/05/06 01:02:03
//--------------------------------------
lv.HardModule -name SYNC_1RW_16x8
// ***************************************************
// TestModes
// ***************************************************
lv.TestMode -name SYNC_1RW_16x8.BYP -polarity 1
// ***************************************************
// Non Scan Instances
// ***************************************************
// ***************************************************
// Black Box Modules
// ***************************************************
lv.BlackBoxModule -name SYNC_1RW_16x8_CORE \
-isolation Verify
June 2014
Example of a Memory Within Wrapper
Figure H-6 shows the same memory but wrapped inside a module with the output data pins
pipelined. The memory BIST testing is applied to the wrapper module in this example. The
memory wrapper is the module described in the .lvmemlib file with the InternalScanLogic
property set to On. You still use the .etcScanData file and the .scandata files you created for the
memory module itself. The memory wrapper is treated as a soft module by ETChecker, and that
it is still the memory module that is the hard module with the pre-existing scan chains to be
connected during ETScan.
Figure H-6. Example Verilog Model Within Wrapper
June 2014
Appendix I
Providing Direct Scan Access for ATPG
Tools
This appendix describes how to add direct scan for use with ATPG tools.
Mentor Graphics currently supports ATPG access with the logic test Scan-Thru-TAP and multi-
chain configurations. However, these configurations are not compatible with ATPG tools using
the Direct Scan protocol, such as Synopsys TetraMax and Mentor Graphics Tessent FastScan.
This document describes how to add ATPG access that is compatible with the Direct Scan
protocol.
The following topics are covered in this appendix:
Adding Third-Party ATPG Access to Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Enabling ATPG Access to Your Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Mentor Graphics Technology and Flow Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Capture-By-Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Rules Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Adding Third-Party ATPG Access to Your
Design
The Direct Scan feature allows you to automatically create a direct access of the multi-chain
scan test of the top-level logicTest controller. With a single dedicated test pin, you can enable
this mode and gain control of the scan chains by passing the TAP controller.
Figure I-1 illustrates the tasks you need to perform during the LV Flow.
Providing Direct Scan Access for ATPG Tools
Adding Third-Party ATPG Access to Your Design
June 2014
Figure I-1. Direct Scan Tasks within the LV Flow
To add scan ATPG support to your design, you need to manually specify the
DirectScanEnablePin property inside the LogicTest wrapper of the .etassemble file.
Note
The direct scan mode is applicable to the top level of the chip. As such internal logic of
ELT cores within the top level will not be tested. Note that the external isolation logic
will be part of the top-level logic and will be tested in this mode.
However, you can use the direct scan mode if there are ELT controllers in the design. The
direct scan mode feature excludes all internal logic of the ELT cores.
The pin is automatically added to the Assert wrapper in the .rulea overrides file and to the
Assert wrapper in the .designe override file.
Enabling ATPG Access to Your Design
June 2014
Figure I-2 illustrates an example of the section of the .etassemble configuration file specific to
the direct scan-enable feature.
Figure I-2. Example .etassemble Configuration File
Configuration (MyChip) {
LogicTest {
DirectScanEnablePin (1): DIRECT_SE;
}
}
Enabling ATPG Access to Your Design
After you run the ETAssemble tool, an RTL module called
<designName>_LVISION_DIRECTSCAN_MUXES is created and is used to intercept all scan
control signals that need to be controlled for the Direct Scan mode to work. To use the direct
scan mode with your third-party scan tools, you assert the direct scan-enable pin to its active
value. The TAP TMS pin will control the scan enable of scan registers.
When the Direct Scan mode is activated, it configures the circuit in the following manner:
The TAP is automatically put in reset mode, and the tdi and tdo chain bypasses all the
TAP internal registers.
The TMS input pin becomes an active high scan-enable signal for all scan chains.
The TCK clock is injected as the clock for all scan chains.
The boundary-scan chain is forced into shift mode, even during the capture cycle.
selectJtagInput and selectJTagOutput are both left inactive such that all inputs and
outputs are part of the direct scan test.
Mentor Graphics Technology and Flow Notes
June 2014
Mentor Graphics Technology and Flow Notes
This section describes the tasks you must perform to eliminate issues between Mentor Graphics
technology and flows. Specifically, you must ensure that the Capture-By-Domain feature and
rules checking tools operate correctly.
Capture-By-Domain
CaptureByDomain is still active and prevents any hold time problem between the clock
domains if you implemented the Capture-By-Domain feature for the normal Scan-Thru-TAP
Multi mode. The information about the Mentor Graphics proprietary Capture-By-Domain
solution will not be passed to your ATPG tool, so you need to explicitly instruct the tool to treat
multi-domain capture paths as correct-by-construction so that they are not masked.
Rules Checking
When your design contains the Direct Scan feature, the direct scan-enable pin must be asserted
to its inactive polarity in order for designExtract and ruleAnalyze to perform their rules
checking. ETAssemble automatically asserts the direct scan-enable pin to inactive polarity for
you.
June 2014
Appendix J
Reusing Functional Shift Registers
This appendix describes how to re-use Functional Shift Registers in Tessent LogicBIST and
SoCScan. This feature allows you to implement intelligent handling of Functional Shift
Registers in the ETScan step of the LV Flow.
Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Enabling Functional Shift Register Reuse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Output Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
scanGenerate .scang_scan Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
ruleAnalyze .scandef Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Concept
In the ETScan step of the LV Flow, functional shift register paths must be identified and reused
whenever possible. Furthermore, logical module boundaries will not affect the functional shift
register reuse. That means that a functional shift register is not limited to the same module
boundary but can cross multiple module boundaries as shown in Figure J-1.
Figure J-1. Functional Shift Registers Location
Enabling Functional Shift Register Reuse
June 2014
Enabling Functional Shift Register Reuse
To enable the Functional Shift Register Reuse feature, you can do one of the following:
In Step 2: ETPlanner of the LV Flow, you can set the ReuseFuncShiftRegisters
property ETPlanner input files to Yes for ELTCore, Block, or Top modules in your
design. You can as well set up the maximum segment size of reused shift registers using
the ETPlanner ReuseFuncShiftRegistersMaxSize property.
Later in the process, in Step 4: ETScan and Pre-Layout ETSignoff of the LV Flow, you
can specify the scanGenerate -reuseFuncShiftRegisters runtime option to Yes without
going back to ETPlanner. The value of this option will be set depending on the
ETPlanner ReuseFuncShiftRegisters property value for corresponding the ELTCore,
Block, or Top module. You can as well specify maximum segment size of reused shift
registers.
Output Results
The scanGenerate and ruleAnalyze tools identify and trace the Functional Shift Registers during
the ETScan step of the LV Flow. The following output files will provide the results of this
process:
scanGenerate .scang_scan Output File
ruleAnalyze .scandef Output File
scanGenerate .scang_scan Output File
The .scang_scan output file will include information when Functional Shift Registers are
reused. The ">>" characters will be added to the flops which are part of the reused Shift
Register. For example:
chain (chain_0) { // 55 elements
scanin : LV_SI0_int connected to
LVISION_LOGICTEST_INST.TO_ISCAN_SEG[1];
scanout : LV_SO0_int connected to
LVISION_LOGICTEST_INST.FROM_ISCAN_SEG[1];
CGC_FE_2.LV_bridge_0 [siGating+siRetiming+mux+pipeline] : clockA1
(LV_BURST_CLK_CTRL_I1.clkOut1)
CGC_FE_2.flop1: SD +> Q
MDs_1.flop2: SD +> Q // 4-element shift
MDs_2.flop2: >> SD +> Q
CGC_FE_52b.flop2: SD +> Q
Output Results
June 2014
The above scan chain fragment indicates that there is a reused Shift Register from MDs_1 to
MDs_4. The ">>" characters augmented to the MDs_2, MDs_3, and MDs_4 flops indicate that
they are untouched by scanGenerate.
For complete information on this file, refer to .scang_scan File in the manual ETAnalysis Tools
Reference.
ruleAnalyze .scandef Output File
The .scandef file is created by ruleAnalyze on a post-scan inserted netlist and is used for scan
chain reordering. Information is provided in the .scandef file when a Functional Shift Register is
identified; it will be declared in a new + ORDERED section. This will ensure that the Shift
Register will be moved as a single entity during scan reordering. For example:
+ ORDERED
MDs_1.flop2 ( IN SD ) ( OUT Q )
For complete information on this file, refer to .scandef File in the manual ETAnalysis Tools
Reference.
Output Results
June 2014
June 2014
Appendix K
Two-Pass Flow
This appendix describes how to delay the insertion of Logic Test in the LV Flow by running
ETAssemble twice.
Purpose of the LV Two-Pass Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Pass 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Pass 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Purpose of the LV Two-Pass Flow
In the regular LV Flow, the TAP/WTAP, Memory BIST, and Logic Test IP are all inserted in a
single ETAssemble run. With the Two-Pass LV Flow, the single ETAssemble run is split up
into two runs so that the Logic Test IP can be inserted at a later time. The Two-Pass Flow can be
used to insert Memory BIST in the RTL netlist during Pass 1 and then have Logic Test inserted
in the Gate netlist during Pass 2.
Pass 1
In Pass 1 of the LV Flow, ETAssemble is just run to insert the non-Logic Test IP, such as
Memory BIST. Because the Logic Test will be inserted using the same TAP/WTAP controller
inserted in Pass 1, the LogicTest BistEnable and other control signals will be reserved for use in
Pass 2.
The following sections describe the tasks you have to implement during each pass of the Two-
Pass LV Flow.
Figure K-1 illustrates Pass 1 of the LV Flow.
Two-Pass Flow
Pass 1
June 2014
Figure K-1. Pass 1 of the LV Flow
Perform the following tasks, as illustrated in Figure K-1, to complete.
1. Run ETChecker normally with lv.EmbeddedTest -logic Off.
Point to the childrens Pass1LVDB with the -lvdbDir option when using Bottom-Up
methodology.
2. In ETPlanner, specify these two properties in the .etplan file:
ModuleOptions (<moduleName>) {
PrepareForLogicTest: RTL | Gate | (No);
DedicatedMultiChainNumber: <int>;
}
Use PrepareForLogicTest RTL if you plan to run ETChecker/ETAssemble on the
RTL view in Pass 2, otherwise, use Gate.
If auxiliary Logic Test scan chains are to be inserted during Pass 2, then you must
specify the DedicatedMultiChainNumber property in Pass 1 so that the multi-chain
muxing logic can be created.
3. The rest of Pass 1 is unaffected:
The TAP/WTAP will reserve BistPort0 and several UserIRBits for future logicTest
controller.
Pre-layout sign-off can be taken all the way up.
ETChecker
ETPlanner
ETAssemble
Functional

Pass 1
Pre-Layout
LVDB
RTL

Functional
RTL w/ ET
Bottom-Up
Methodology
Pre-Layout
ETSignOff
Two-Pass Flow
Pass 2
June 2014
Pass 2
In Pass 2 of the LV Flow, ETAssemble will reuse the TAP/WTAP inserted in Pass 1 when
inserting the Logic Test IP.
Figure K-2 illustrates Pass 2 of the LV Flow.
Figure K-2. Pass 2 of the LV Flow
Perform the following tasks, as illustrated in Figure K-2, to complete Pass 2:
1. Run ETChecker normally with lv.EmbeddedTest -logic On -memory Off:
Point to the Pass1 pre-layout LVDBs of the root module with the -lvdbDir runtime
option.
ETChecker
ETPlanner
ETAssemble
ETScan

Functional
Pass 1
Pre-Layout
LVDB

Pass 2
Pre-Layout
LVDB
RTL w/ ET

LVDB /
Test Patterns
Functional

RTL to
Netlist
RTL w/ all ET
GDSII Flow
w/ ET
Bottom-Up
Methodology
Pre-Layout
ETSignOff
Final
ETSignOff
Two-Pass Flow
Pass 2
June 2014
Also point to the Pass2 pre-layout LVDBs of the child physical regions when using
Bottom-Up methodology.
If using Top-Down methodology, point to the Pass 1 pre-layout LVDBs of the child
physical regions with the -lvdbDir runtime option.
2. Run ETPlanner in GenPlan mode and point to Pass1 pre-layout LVDBs of the root
module with the -preLayoutLVDBDir runtime option:
Point to the Pass 2 pre-layout LVDBs of the child physical regions with the same
-preLayoutLVDBDir runtime option when using Bottom-Up methodology.
Point to Pass 1 pre-layout LVDB of the child physical regions with the same
-preLayoutLVDBDir option when using Top-Down methodology.
3. The rest of Pass 2 is unaffected.
The logicTest controller will connect to the signals, like the BistEnable, on the pre-
existing TAP/WTAP that were created during Pass 1. The resulting pre-layout LVDB
and final LVDB in Pass 2 will include both the Memory BIST inserted in Pass 1 and the
Logic Test data.
Note
Clock labels specified in ETChecker between Pass 1 and Pass 2 should be consistent to
avoid potential conflicts when ETAssemble is run in Pass 2.
June 2014
Appendix L
Utilizing Flop Trays
This appendix describes utilize flop trays (multiple flip-flop cells) in their designs to save on
power requirements by sharing clock inverters within the multi-bit cell.
Flop Trays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Using Flop Trays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Flop Tray Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Flop Trays
A flop tray cell contains multiple flip-flops which are connected into one existing scan chain as
illustrated in Figure L-1. Each flip-flop within the tray has its own dedicated data input and data
output pins on the cell. Flop trays are typically pre-constructed in a technology library in
various size increments such as 2, 4, 8, 16, and 32.
Flop Trays
June 2014
Figure L-1. Example Flop Tray Cell with 3 Flip-Flops
In the previous versions, scan insertion in LV Flow did not allow the insertion of a multiple flip-
flop scan cell. The only exception was the 2-bit synchronizer cell which has a very specific use
and set of requirements. The purpose of the feature is to integrate support for flop tray cells into
the LV Flow when implementing Tessent LogicBIST.
Requirements
The following requirements must be met for the flop tray cells support:
There must be a single scan path between an input and an output pin of the flop tray cell
controlled by a single scanenable pin. All flip-flops within the flop tray must be on the
single scan path.
All flip-flops in the flop tray must be driven by a single clock pin on the cell and must be
active on the same edge.
Any retiming flip-flops or lock-up latches are not allowed within a flop tray cell.
Using Flop Trays
June 2014
Using Flop Trays
It is assumed that you introduce flop tray cells in a post-synthesis optimization step, meaning
that the concept of flop trays does not exist within the RTL netlist. Your design is analyzed in
the post-synthesis step, and compatible registers are identified which can be grouped into multi-
bit flop tray cells.
After the multi-bit optimization step is executed, the modified gate-level netlist must be run by
ETChecker for re-analysis. In addition, the flop cell module definitions instantiated as the result
of the optimization must be declared with the ETChecker property:
lv.HardModule -name <flopTrayModName> -allowedOnPeripheryChain
The lv.HardModule specification is required in order for ETChecker to treat the flop tray cell as
a single unit for capture-by-domain and periphery analysis instead of individual flip-flops. The
-allowedOnPeripheryChain option is needed because by default lv.HardModule instances are
forced to reside within the internal test logic by inferring Dedicated Isolation (DI) on the pins
interfacing with lv.HardModule.
In the ETScan step of the LV Flow, you need to define your flop tray cells in the Scan Mapping
input file (scang.lib) used by scanGenerate. A new floptray mapping cell type is added
specifically for this purpose.
Figure L-2 shows the flop tray module syntax specification and the set of allowable pin
functions (highlighted in red).
Figure L-2. Flop Tray Module Specification Syntax in scang.lib
Library (<technologyName>) {
Module (<moduleName>) {
Type: floptray;
Pin (<pinName>){
Function: scanenable | scanenablenot | scanin | scanout |
scanoutnot | dataout | dataoutnot;
}
}
}
Note that there will only be support for a scanned version of a flop tray cell in the netlist,
meaning, there will be no support for flop tray cells of type nonscan and prioritydata. Flop tray
cells are expected to have a pre-scanned path, and no cell mapping is required. Scan hold for
flop tray cells will always be implemented using clock-gating.
Figure L-3 provides an example of a scang.lib module entry for the flop tray cell shown in
Figure L-1.
Using Flop Trays
June 2014
Figure L-3. Example Flop Tray Module Specification
Library (myTechLib) {
Module (FlopTray3Cell) {
Type: floptray;
Pin (SE){
}
Pin (SI){
Function: scanin;
}
Pin (SO){
Function: scanout;
}
Pin (Q2){
Function: dataout;
}
}
}
Note that the specified dataout pin of flop tray must correspond to the output of last flip-flop
within the flop tray chain (Q2 in the example cell). This is because the dataout pin is used as an
alternate pin to use in place of scanout. All other output pins controlled by the other flip-flops of
the flop tray, such as Q0 and Q1, must not be declared.
Flop Tray Limitations
These limitations are applicable to the Flop Tray support for this version:
Only flop tray cells with a single scanenable, scanin, scanout, clock pins are supported
Flop tray scan mapping entries must be manually added to the scan mapping file.
June 2014
Appendix M
LV Flow Migration to Tessent Editing Engine
This appendix describes the LV Flow migration to the Tessent Editing Engine including usage
scenarios and existing limitations.
Overview of Migration to Tessent Editing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Syntax for Setting Up an Editing Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Auto-Uniquification Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Design with System Verilog Not Supported by Legacy Editing Engine . . . . . . . . . . . 367
Design with VHDL Not Supported by Legacy Editing Engine . . . . . . . . . . . . . . . . . . 367
Design with System Verilog Keywords Supported by Legacy Editing Engine . . . . . . 368
Limitations on Language Support in the LV Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Overview of Migration to Tessent Editing
Engine
In order to enable automatic uniquification of designs and to provide full language support
when inserting test logic, the ETAssemble step of Tessent Hierarchical Integrated Flow has
been ported to Tessent Editing Engine. Enhancements were made as well to the ETChecker and
ETPlanner steps of the flow. New options, properties, and runtime options that allow the
following actions are described in Syntax for Setting Up an Editing Engine section:
Enable auto uniquification
All restrictions on insertion of test logic into non-unique designs have been removed.
Enable SystemVerilog parsing
Inhibit execution of designExtract and have ETassemble generate the
TestConnectionMap file
This should normally be set for SystemVerilog parsing and, optionally, for VHDL.
Prepend a specified string to the name of each module edited by ETAssemble
Inhibit the insertion of assignment statements into edited files
Several usage scenarios are described in the Usage Scenarios section.
Syntax for Setting Up an Editing Engine
June 2014
Syntax for Setting Up an Editing Engine
Table M-1 provides a summary of syntax used for setting up an editing engine while enabling
automatic uniquification of designs when logic is inserted during the LV Flow.
Usage Scenarios
Several usage scenarios and the required actions are described in the following sections:
Auto-Uniquification Required
Design with System Verilog Not Supported by Legacy Editing Engine
Design with VHDL Not Supported by Legacy Editing Engine
Design with System Verilog Keywords Supported by Legacy Editing Engine
Auto-Uniquification Required
Specify the -RTLEditingEngine option in ETChecker property lv.EmbeddedTest as HDLE.
The -autoUniquify option defaults to asNeeded. ETChecker detects which modules need to be
uniquified prior to editing. Refer to the ETChecker User's and Reference Manual for the details
of this algorithm. In addition, you can use the lv.UniquifyInstance property to tell ETChecker
about additional modules that need to be edited beyond those that can be detected by
Table M-1. Syntax for Setting Up an Editing Engine
Property Description
lv.EmbeddedTest
-RTLEditingEngine (HDLE) | Incore
-autoUniquify Off | asNeeded | allEditedModules
The options for the ETChecker
lv.EmbeddedTest property
lv.UniquifyInstance The ETChecker property
-f_sv The ETChecker runtime option
-VHDLVersion The ETChecker runtime option
AllowVCSVerilogExceptions The ETPlanner property in the .etplan file
BypassDesignExtract The ETPlanner property in the .etplan file
ETAssembleEditedModulePrefix The ETPlanner property in the .etplan and
.ETDefaults files
InhibitAssigns The ETPlanner property in the .etplan file
SystemVerilogDashFFile The ETPlanner property in the .etplan file
-hdleInfo On | (Off) The ETAssemble runtime option
Usage Scenarios
June 2014
ETChecker. These options are forwarded to ETPlanner and ETAssemble. The Tessent Editing
Engine is used in ETAssemble.
Design with System Verilog Not Supported by
Legacy Editing Engine
Your design contains System Verilog constructs not supported by the legacy editing engine.
This scenario requires the following actions:
Specify the -RTLEditingEngine option in ETChecker as HDLE.
Create a command file for ETChecker containing the paths of your System Verilog
design files. Include in this file any standard Verilog options (for example, -y, -v) needed
to compile those files. Specify the -f_sv runtime option to ETChecker with this
command file as the option value.
Create a command file for ETPlanner similar to the one for ETChecker. Specify the
SystemVerilogDashFFile property in the .etplan file with this command file as the
property value.
Note
In many cases ETPlanner and ETChecker will be run from different directories, and the
file paths in the command file will be relative to the current working directory. Normally
in such cases, a single command file cannot be used because the relative paths from the
ETPlanner and ETChecker directories to the design files probably will not match. If the
file paths are absolute or if ETPlanner and ETChecker are run from directories where the
relative paths to the design files match, then the same file can be used for both steps.
Specify the BypassDesignExtract property in the .etplan file to Yes to inhibit execution
of designExtract. The .tcm file will be generated by the ETAssemble tool.
The Tessent Editing Engine will be used in ETAssemble.
When inserting Tessent MemoryBIST during the top-down insertion and after signing-off one
or more child blocks, you need to change the directory to the ETAssemble directory of the
parent workspace and execute the following:
make tcmgen
Design with VHDL Not Supported by Legacy
Editing Engine
Your design contains VHDL constructs not supported by the legacy editing engine. The
following actions are required:
Limitations on Language Support in the LV Flow
June 2014
Specify the -RTLEditingEngine option in ETChecker as HDLE. The Tessent Editing
Engine will be used as the editing engine in ETAssemble.
Specify the BypassDesignExtract property in the .etplan file to Yes to inhibit execution
of designExtract. The .tcm file will be generated by the ETAssemble tool.
When inserting Tessent MemoryBIST during the top-down insertion and after signing-off one
or more child blocks, you need to change the directory to the parent workspace's ETAssemble
directory and execute the following:
make tcmgen
Design with System Verilog Keywords Supported
by Legacy Editing Engine
Your design contains System Verilog keywords; however, those keywords are supported by the
legacy editing engine. The designExtract tool does not need to be bypassed in such scenario.
If auto uniquification is required, then specify the -RTLEditingEngine option in
ETChecker as HDLE; otherwise, this option does not need to be specified.
Create a command file for ETChecker containing the paths of your System Verilog
design files. Include in this file any standard Verilog options (for example, -y, -v) needed
to compile those files. Specify the -f_sv runtime option to ETChecker with this
command file as the option value.
This step is needed only if the -RTLEditingEngine option was specified as HDLE in
ETChecker. In that case, create a command file for ETPlanner similar to the one for
ETChecker. Specify the SystemVerilogDashFFile property in the .etplan file with this
command file as the property value.
Note
In many cases ETPlanner and ETChecker will be run from different directories, and the
file paths in the command file will be relative to the current working directory. Normally
in such cases, a single command file cannot be used because the relative paths from the
ETPlanner and ETChecker directories to the design files probably will not match. If the
file paths are absolute or if ETPlanner and ETChecker are run from directories where the
relative paths to the design files match, then the same file can be used for both steps.
Limitations on Language Support in the LV
Flow
The following sections describe the limitations to language support in the LV Flow.
June 2014
Limitations Applicable to the ETChecker Tool
The following limitations are applicable to ETChecker.
The use of parameter overrides in the instantiation of parameterized SystemVerilog
interfaces are not supported.
Nested SystemVerilog interfaces are not supported. The following example illustrates a
nested interface:
interface intA;
intB intB_inst();
endinterface
interface intB;
endinterface
Logic inside a SystemVerilog interface (for example, continuous assignments) cannot
be traced. If signals that appear in that logic are connected to memory ports, rule check
failures are likely to occur.
Limitations Applicable to the Tessent Editing
Engine
Some limitations are applicable to the Tessent Editing Engine. In the following bulleted items,
the word ignored implies that the construct is read and can be written when needed; however,
tracing and modification of code that depends upon that construct are not supported.
Language constructs that are not covered by the RTL-synthesizeable subset are ignored.
One of the implications of this is that cross-scope references are ignored, and you may
need to manually edit these references after ETAssemble completes. The following are
two types of cross-scope references that are ignored:
o Hierarchical references that cross module boundaries are ignored. If a net in such a
reference needs to be renamed, a manual update will be required. The following
example illustrates such a hierarchical reference:
module top ( input in1, output o1 );
DUT INST1 ( in1, out1 );
endmodule
module DUT ( input in1, output out1 );
wire w1, w2;
assign w1 = top.INST1.w2; // This is an absolute hierarchical
// reference that crosses a module boundary.
endmodule
o Variables declared inside packages or $unit compilation scope are ignored. If such a
variable needs to be renamed, a manual update will be required.
June 2014
Enum methods such as next, prev, first, and last are not interpreted during
tracing/modification. This limitation could affect tracing (for example, if the return
value of the method is used as an alternative in a case generate statement). The
following example illustrates this limitation:
module joe ( input in1, output out1 );
typedef enum {S[2]} states_t;
parameter states_t p1 = S1;
case(p1)
p1.first : begin
assign out1 = p1.first;
end
p1.last : begin
assign out1 = p1.last;
end
endcase
endmodule
The signal out1 cannot be traced.
Ports of an enum type cannot be intercepted. This limitation is a constraint on the
construction of custom objects.
Net and port objects declared to be one of the following types can only be accessed for
editing purposes as a complete net / port:
o User-defined types
o Struct types (packed and unpacked)
o Unions
o Packed arrays of more than one dimension
o Unpacked arrays of one or more dimensions
The above limitation constrains the types of connections that can be made with custom
objects. You cannot construct a custom object that accesses a field within a user-defined
type, a struct, or a union. Likewise, you cannot construct a custom object that accesses
an element within an unpacked array or within a packed array of more than one
dimension.
Tracing through procedural blocks, procedural statements, functions, and tasks is not
supported.
Extern modules are ignored. This limitation will be an issue if the module port list needs
to be modified.
In a mixed design (VHDL and Verilog or SystemVerilog), only one version of a design
unit can be compiled into a given logical library. In other words, no support currently
exists for overriding a previously compiled version with a new one.
A given VHDL file cannot be compiled into multiple logical libraries.
June 2014
SystemVerilog interfaces are supported in the Tessent Editing Engine with the following
limitations:
o Multi-dimensional instantiation of SystemVerilog interfaces is ignored. This
limitation affects tracing and modification of any logic that is dependent upon those
interfaces. The following example illustrates multi-dimensional instantiation of
interfaces:
interface intfA;
endinterface
module top ( input in1, output o1 );
intfA my_intf_array [3:0][4:0] ();
endmodule
o Edits to the design by the ETAssemble tool that require modification of
SystemVerilog interfaces are not supported.
o Modification of the outside connection on a port whose type is a SystemVerilog
interface is not supported. This limitation affects tools such as Tessent
BoundaryScan, which need to intercept outside connections on pad cell keyports.
This limitation is also a constraint on the construction of custom objects.
o Inserting an instance of a module containing a port whose type is a SystemVerilog
interface is not supported.
Other Flow Limitations
The following additional flow limitations exist.
In a bottom-up flow, unpacked dimensions cannot be used in the port definitions of the
root modules of a child block. An example of such a construct is the following:
input cb_flow_type [18:0];
When the BypassDesignExtract property is set to Yes, the following additional
limitations apply:
o The Non-Programmable memory BIST controller that uses a memory collar is not
supported. A warning will be issued for this case.
o The two-pass flow is not supported.
o Most clock schemes are supported including the clock from a child block feeding the
parent and a child blocks clock feeding another child block. However, in the event
that an unsupported clock scheme is encountered, a clock override mechanism is
provided. You must specify a TCMGenClockSource wrapper in the .etassemble file.
The syntax is as follows:
TCMGenClockSource(subModuleInstancepathName.clockPortName){
June 2014
ReferencePin: currentModuleClockPortName;
ReferencePinInv: currentModuleClockPortNameInv;
FreqRatio: ##;
}
where FreqRatio is the frequency ratio between currentModuleClockPortName and
subModuleInstancepathName.clockPortName.
The following is an example:
// In car.etassemble file
Configuration (car) {
BoundaryScan {
Overrides {
}
}
TAP {
InjectTCKOnClockSources: All;
Connections {
...
}
}
TCMGenClockSource (dashboard_INST.CK33MHz){
ReferencePin: CLKTEST;
FreqRatio: 2;
}
}
o You cannot bypass designExtract for a child block and then use designExtract in the
parent block. The reverse is not true; meaning, you can run designExtract on a child
block and then bypass designExtract in the parent. The latter is required for legacy
LVDB support.
o The ULTRA controller is supported with two limitations. First, in order to retarget
the ULTRA controller to the parent block, when the pads for the ETSerdes ports are
located in the parent block (as opposed to the child block which instantiates the
ULTRA controller), the path from the pad to the ETSerdes port on the child block
must be a direct connect; meaning, there can be no intervening logic other than
simple assigns. Second, two and only two levels of workspace hierarchy are
supported, with the ultra controller instantiated in the child block.
o Asserts that you manually add in the .designe file are not written to the .tcm file.
These need to be added manually to the .tcm file itself or to the appropriate
PinSettings wrappers in the ETVerify configuration file.
o Custom objects used in designAssemble are not reflected in the .tcm file. For
example, if the following CustomObject were used to intercept a clock multiplexer
select and gate in some new logic, a memory BIST controllers expected clock
source and/or frequency ratio could change, and the ETVerify tool would not see
that reflected in the .tcm file.
CustomObject(Gate2InterceptDestination) {
June 2014
Var(ModuleName): AND2;
Var(InstanceName): clock_control_i/clock_mux_select_and_i;
Var(OutputPin): Y;
Var(Input0Pin): A;
Var(Input1Pin): B;
Var(InterceptPort): clock_control_i/clock_bypass_mux/S;
Var(Input1Connection): clock_control_i/clock_bypass_en;
}
To ensure that the .tcm file is generated correctly, specify a TCMGenClockSource
wrapper in the .etassemble file to reflect the change in the clock source.
Ports that are declared in the top module of a child block or ELTCore cannot be declared
using a SystemVerilog generic interface type. The following example illustrates a
generic interface type:
module mem1 (interface pins, input clk);
endmodule
Ports that are declared in the top module of a child block or ELTCore can be declared
using a SystemVerilog interface type with modports; however, the modport to be used in
instantiations of the module must be specified in the module declaration. The following
example illustrates a module declaration with the modport specified in the module
declaration (which is always allowed):
interface my_bus;
wire [0:127] data;
wire [31:0] address;
modport my_view (input address, inout data);
endinterface
module joe (my_bus.my_view bus1);
endmodule
The following example, using the same interface my_bus, illustrates a module
declaration with the modport specified in an instantiation of the module (which is not
allowed in the top module of a child block or ELTCore):
module top (input in1, output out1);
my_bus bus1;
joe i1 (bus1.my_view);
endmodule
module joe (my_bus bus1);
endmodule
Parameter overrides cannot be used in the instantiation of a child block or ELTCore.
Implicit port syntax (in other words, .*) cannot be used in the instantiation of a child
block or ELTCore. The following example illustrates the use of implicit port syntax:
June 2014
module top( input in1, output out1 );
joe i1( .* );
endmodule
module joe( input in1, output out1 );
endmodule
There are certain conditions under which a VHDL simulation model cannot be used for
a memory. If that memory is instantiated from Verilog and a memory scan model was
generated by ETAssemble or was provided by the user, the VHDL simulation model
cannot be used.
Top-level port declarations are limited to one packed dimension and zero unpacked
dimensions (SystemVerilog) and simple vectors (VHDL) when boundary scan needs to
be inserted into the design.
If a custom object is used to make connections to a net or port inside an unrolled
generate loop (unrolled due to a previous run of ETAssemble on the current design), the
escaped names used for the unrolled loop labels in the edited design file must be used in
the custom object. For example, if the following path were used before the design was
first edited:
A/B[0]/P1
then after loop unrolling, the required syntax is as follows:
A/\B[0] /P1
Note the \ character and the space character after the ] character.
The Verilog construct array of instances is not supported for instances that need to be
edited.
June 2014
Appendix N
Power-Aware Scan Insertion
In the LV flow, the scan insertion step ETScan does not take any power information into
consideration when inserting testpoints and scan chains. As a result, if two flip-flops are on the
same scan chain but belong to different power domains, you must reorder the flip-flops. This
appendix describes the method for making the testpoint and scan chain insertion power-aware
by reading a Common Power Format (CPF) or Universal Power Format (UPF) file into Tessent
Shell. Additionally, this method enables you to create scan partitions, or scan clusters, so that
scan chains can be restricted to specific instances. As part of power-aware scan insertion,
Tessent Shell is used to automatically clone Scan Enable Controllers (SEC)s so that a unique
SEC is used for the power domain and scan cluster.
Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Scan Chain Concatenation with Multiple Power Domains. . . . . . . . . . . . . . . . . . . . . . . . . 379
Usage Model
The ETPlanner properties used to perform power-aware scan insertion in the LV Flow are as
follows:
In the .ETDefaults file:
EmbeddedTestDefaults {
LogicTest {
AllowMultiPowerDomainChains: Yes | (No);
ScanPartitioning: Yes | (No);
}
ATPGRulesOnlyLogicTest {
}
}
In the .etplan file:
ETPlan (xxx) {
ModulesGate (xxx) {
PowerFormatFile (UPF|CPF): <file>;
}
}
EmbeddedTest {
GlobalOptions {
ScanPartitioning: Yes | (No);
Usage Model
June 2014
}
ModuleOptions(.*) {
}
}
}
Use the ScanPartitioning property to enable creating scan partitions using a power format file
and/or specifying scan clusters in the design by means of an include dofile. Enabling this
property adds a new Makefile target to the ETScan step of the LV Flow between the targets
make testpointa and make scang make scan_partition. This target invokes Tessent Shell
using the new dofile <designName>_scan_partition.tcl.
Use the PowerFormatFile property to identify where the UPF/CPF file is located. The specified
file is then read into the Tessent Shell dofile, <designName>_scan_partition.tcl, using the
read_upf or read_cpf command. If you do not specify the PowerFormatFile property, the scan
partitioning dofile tries to find a UPF/CPF file called <designName>.(upf|cpf) in the same
directory where the root design file is located.
Use the AllowMultiPowerDomainChains property to control how you want scan chains to be
constructed with respect to power domains. A value of No indicates that each scan chain
generated cannot span more than one power domain.
Figure N-1 illustrates where the new Makefile target (marked in Red) fits into the ETScan step
of the LV Flow.
Usage Model
June 2014
Figure N-1. The make scan_partition Target in the ETScan Step
The Tessent Shell dofile used by the make scan_partition target performs the following:
1. Reads the pre-scan Verilog netlist.
2. Loads the .tcl_rulea_prescan file that was created by make rulea_prescan. This file
contains Tcl lists of all clock domains, their scan-testable flip-flops, and the SECs.
3. Adds a rulea_clock_domain attribute to each scan-testable flip-flop.
4. Adds a scan_cluster attribute for objects of type instance and then sets the
-applies_to_child_instances option to On. You can create an include dofile that can be
used to set the scan_cluster attribute, thereby providing a method to manually partition a
design for scan.
5. If the ETPlanner PowerFormatFile property was specified, loads the UPF/CPF file to
get the power domain information. Tessent Shell then populates the
power_domain_name attributes for the design objects.
6. Partitions the design based on the presence of the scan_cluster attribute.
make rulea_prescan
make testpoina
make scang
make scan_partition
.tcl_rulea_prescan
.siga_prescan
User
Input
CPF/UPF .tpinfo
ATPG
Netlist
.scan_partition
_info
Netlist
library
.tpinfo
ruleAnalyze
Tessent Shell
testpointAnalyze
scanGenerate
Usage Model
June 2014
7. If a clock domain has more than one power domain partition or scan cluster, clones the
clock domains SEC for each power domain partition and for each user-defined
scan_cluster.
8. Writes out the new Verilog netlist, <designName>.<gateExtension>_prescan.
9. Reads the testpoint information file (.tpinfo) created by testpointAnalyze.
10. If a testpoint has been marked to reuse a functional flip-flop, compares the power
domain of the functional flip-flop and the testpoint gate. If the power domains differ,
replaces the functional flip-flop in the .tpinfofile with a - and uses a dedicated testpoint
flip-flop. For testpoints that use a dedicated flip-flop, adds a new column entry,
scan_partition, that lists all of the scan partitions that the testpoint gate belongs to. One
of these identified scan partitions is used by scanGenerate when the testpoint is inserted.
The modified .tpinfo file is then written out so that it can be read in by scanGenerate.
11. Writes out a scan partition information file. This file describes to scanGenerate which
scan partition each scan-testable flip-flop and SEC belong to.
The output files from the make scan_partition target (Verilog netlist, .tpinfo, and
scan_partition_info) are then read in by make scang so that scanGenerate can insert the
testpoints and scan chains in their respective scan partition. The .scan_partition_info file is
specified to scanGenerate using the new -scanPartitionInfoFile runtime option.
The .scang_scan file generated by scanGenerate provides detailed information about the
modifications made to the design. This file contains additional information showing which scan
partition each chain belongs to.
Figure N-2 shows an example of a chain segment where the name of the power domain the scan
segment belongs to is listed with the starting bridge cell of the segment.
Figure N-2. Chain Segment Example
chain (chain_0) {
scanin: MGsg_SI0_int connected to
LVISION_LOGICTEST_INST.TO_ISCAN_SEG[85];
scanout: MGsg_SO0_int connected to
LVISION_LOGICTEST_INST.FROM_ISCAN_SEG[85];
LV_bridge_0 [siGating+siRetiming+mux+pipeline]:
clock_domain_core_clk_power_domain_PDcore
(LV_BURST_CLK_CTRL_I1.LV_CLK_GATING1.LV_CLOCK_CELL_MUX.Y)
pc_inst.pc_reg_31_: SD +> Q {LTRX}
...
The ruleAnalyze tool supports scan chains partitioned by power domains during generation.
Prior to v2013.3, the PARTITION labels created within the file used the chains clock domain
base to control reordering. This restricted scan flops from different clock domains from scan re-
ordering with each other but did not control re-ordering between power domains.
Usage Model
June 2014
The ruleAnalyze tool now creates PARTITION labels using the instance name of the Scan
Enable (SE) controller sourcing the chain segment. Because SE controllers are cloned for each
power domain, restricting re-ordering based on SE controllers ensures that a scan flip-flop is not
scan-reordered with another flip-flop from a different power domain.
You can use the following ruleAnalyze runtime option to control the file partition:
-scanDefPartitionBy ClockDomain | (SEController) | SyncGroup
Scan Chain Concatenation with Multiple Power
Domains
Although partitioning allows for control of rotating scan segment creation to avoid mixing
power domains, partitioning does not restrict the concatenation of two rotation segments into
the same scan chain if the segments have different power domain attributes. This section details
the additional functionality added in v2013.3 to allow the creation of scan chains to be restricted
to a single power domain.
scanGenerate
The following scanGenerate command-line option enables or disables the power domain based
scan chain stitching:
-allowMultiPowerDomainChains On | (Off)
The -allowMultiPowerDomainChains option defaults to Off. With an Off value, scanGenerate
only creates scan chains using segments with the same PowerDomain attribute. If the existing
-allowMultiDomainChains option is also set to Off, then all scan chains will be a single clock
domain and single power domain.
ETPlanner
The AllowMultiPowerDomainChains property is in the ModuleOptions wrapper of the .etplan
file as well as to the LogicTest and ATPGRulesOnlyLogicTest wrappers of the .ETDefaults file.
For example:
ModuleOptions {
The AllowMultiPowerDomainChains property value is passed on to the scanGenerate makefile
target as the -allowMultiPowerDomainChains command-line option.
Usage Model
June 2014
Scan Partition Power Domain Attributes
Prior to v2013.3, pre-existing scan chains were not attributed to a specific scan partition. Pre-
existing scan chain segments now are stitched as individual rotating segments and are free to be
concatenated with other rotating segments. To support power domain based scan chains, pre-
existing scan chain segments now have scan partition attributes so that they can be accounted
for during stitching.
To add the attributes, modifications were made to the rulea prescan mode and the scan
partitioning Tessent Shell script. ScanGenerate now processes the ScanOutPorts wrapper of the
.scan_partition_info file. ScanGenerate uses the properties of this wrapper to associate scan
partition and power domain attributes to the pre-existing chain segments.
Rulea PreScan
The rulea prescan mode generates a .tcl_rulea_prescan file that contains association between
flip-flops and clock domains as well as SE controllers and clock domains. For pre-existing
memory scan chains, rulea now reports the scan output port of the existing scan chain segments
instead of the memory scan flops. The following example shows where the scanout so1 port of
the memory mem_inst is reported:
array set clock_domains { \
clk1 { \
{moda_inst/data_reg[0]} \
{mem_inst/so1} \
Scan Partition Tessent Shell Script
The scan partitioning Tessent Shell script invoked via the make scan_partition target now
handles the reporting of memory scan output ports. If memory chain segments are partitioned
into scan clusters, the corresponding scan output port is reported in the ScanOutPorts wrapper
within the .scan_partition_info output file. For example:
ScanPartitionInfo {
ScanPartition(clock_domain_clk1_power_domain_default_flops_cluster) {
ScanEnableController: LV_SE_CTRL_BL5_P_INT_I1_1;
ExternalScanEnableController: LV_SE_CTRL_BL5_P_EXT_I1_1;
PowerDomain: default_flops_cluster;
ScanOutPorts {
"mem_inst/so1";
}
Flops {
"\test_reg[0] ";
Limitations
When the LogicTest controller hardware is constructed during the ETAssemble step, it has no
knowledge of the scan partition and power domain constraints. As a result, the number of
internal and external scan ports created could result in scan chain balancing issues during the
ETScan step.
Usage Model
June 2014
Furthermore, the scan ports (internal/external) created by ETAssemble may be insufficient to
accommodate the allowMultiDomainChains and allowMultiPowerDomainChains option
settings; more constraint groups may exist than there are available scan chain ports to which you
can connect. When this occurs, scanGenerate flags an error and instructs you to rerun
ETAssemble with increased scan chain numbers:
LogicTest {
NumberOfInternalScanChains: 33;
NumberOfPeripheryScanChains: 47;
}
Usage Model
June 2014
June 2014
Appendix O
Getting Help
There are several ways to get help when setting up and using Tessent software tools. Depending
on your need, help is available from documentation, online command help, and Mentor
Graphics Support.
Documentation
The Tessent software tree includes a complete set of documentation and help files in PDF
format. Although you can view this documentation with any PDF reader, if you are viewing
documentation on a Linux file server, you must use only Adobe
Reader
versions 8 or 9, and
you must set one of these versions as the default using the MGC_PDF_READER variable in
your mgc_doc_options.ini file.
For more information, refer to Specifying Documentation System Defaults in the Managing
Mentor Graphics Tessent Software manual.
You can download a free copy of the latest Adobe Reader from this location:
http://get.adobe.com/reader
You can access the documentation in the following ways:
Shell Command On Linux platforms, enter mgcdocs at the shell prompt or invoke a
Tessent tool with the -Manual invocation switch. This option is available only with
Tessent Shell and the following classic point tools: Tessent FastScan, Tessent
TestKompress, Tessent Diagnosis, and DFTAdvisor.
File System Access the Tessent bookcase directly from your file system, without
invoking a Tessent tool. From your product installation, invoke Adobe Reader on the
following file:
$MGC_DFT/doc/pdfdocs/_bk_tessent.pdf
Application Online Help You can get contextual online help within most Tessent
tools by using the help -manual tool command:
> help dofile -manual
This command opens the appropriate reference manual at the dofile command
description.
Getting Help
Mentor Graphics Support
June 2014
Mentor Graphics Support
Mentor Graphics software support includes software enhancements, access to comprehensive
online services with SupportNet, and the optional On-Site Mentoring service.
For details, refer to this page:
http://supportnet.mentor.com/about
If you have questions about a software release, you can log in to SupportNet and search
thousands of technical solutions, view documentation, or open a Service Request online:
http://supportnet.mentor.com
If your site is under current support and you do not have a SupportNet login, you can register for
SupportNet by filling out a short form here:
http://supportnet.mentor.com/user/register.cfm
All customer support contact information is available here:
http://supportnet.mentor.com/contacts/supportcenters/index.cfm
Third-Party Information
For information about third-party software included with this release of Tessent products, refer to the Third-Party Software for
Tessent Products.
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula
END-USER LICENSE AGREEMENT (Agreement)
This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively Products)
between the company acquiring the Products (Customer), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (Mentor Graphics). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT.
1.1. To the extent Customer (or if agreed by Mentor Graphics, Customers appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an Order), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any additional
or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order management
system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and physically signed
by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month or
the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes or
other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a valid
certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all applicable
taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all payments free
and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by Customer
hereunder will be Customers sole responsibility. If Customer appoints a third party to place purchase orders and/or make
payments on Customers behalf, Customer shall be liable for payment under Orders placed by such third party in the event of
default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics delivery of Software by electronic means is subject to Customers provision of
both a primary and an alternate e-mail address.
2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation and design data (Software) are copyrighted, trade secret and confidential
information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not expressly granted
by this Agreement. Mentor Graphics grants to Customer, subject to payment of applicable license fees, a nontransferable, nonexclusive
license to use Software solely: (a) in machine-readable, object-code form (except as provided in Subsection 5.2); (b) for Customers
internal business purposes; (c) for the term of the license; and (d) on the computer hardware and at the site authorized by Mentor
Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer may have Software temporarily used by an employee for
telecommuting purposes from locations other than a Customer office, such as the employees residence, an airport or hotel, provided
that such employees primary place of employment is the site where the Software is authorized for use. Mentor Graphics standard
policies and programs, which vary depending on Software, license fees paid or services purchased, apply to the following: (a)
relocation of Software; (b) use of Software, which may be limited, for example, to execution of a single session by a single user on the
authorized hardware or for a restricted period of time (such limitations may be technically implemented through the use of
authorization codes or similar devices); and (c) support services provided, including eligibility to receive telephone support, updates,
modifications, and revisions. For the avoidance of doubt, if Customer provides any feedback or requests any change or enhancement to
Products, whether in the course of receiving support or consulting services, evaluating Products, performing beta testing or otherwise,
any inventions, product improvements, modifications or developments made by Mentor Graphics (at Mentor Graphics sole discretion)
will be the exclusive property of Mentor Graphics.
3. ESC SOFTWARE. If Customer purchases a license to use development or prototyping tools of Mentor Graphics Embedded Software
Channel (ESC), Mentor Graphics grants to Customer a nontransferable, nonexclusive license to reproduce and distribute executable
files created using ESC compilers, including the ESC run-time libraries distributed with ESC C and C++ compiler Software that are
IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMERS COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.
linked into a composite program as an integral part of Customers compiled computer program, provided that Customer distributes
these files only in conjunction with Customers compiled computer program. Mentor Graphics does NOT grant Customer any right to
duplicate, incorporate or embed copies of Mentor Graphics real-time operating systems or other embedded software products into
Customers products or applications without first signing or otherwise agreeing to a separate agreement with Mentor Graphics for such
purpose.
4. BETA CODE.
4.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively Beta Code), which may not be used without Mentor Graphics explicit authorization. Upon Mentor Graphics
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to test
and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.
4.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customers use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customers evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
4.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customers feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 4.3 shall survive termination of this Agreement.
5. RESTRICTIONS ON USE.
5.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices and
legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall remain
the property of Mentor Graphics or its licensors. Customer shall maintain a record of the number and primary location of all
copies of Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customers employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Except as otherwise permitted for purposes of interoperability as specified by applicable and mandatory local
law, Customer shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive any source code from Software.
Log files, data files, rule files and script files generated by or for the Software (collectively Files), including without limitation
files containing Standard Verification Rule Format (SVRF) and Tcl Verification Format (TVF) which are Mentor Graphics
trade secret and proprietary syntaxes for expressing process rules, constitute or include confidential information of Mentor
Graphics. Customer may share Files with third parties, excluding Mentor Graphics competitors, provided that the confidentiality
of such Files is protected by written agreement at least as well as Customer protects other information of a similar nature or
importance, but in any case with at least reasonable care. Customer may use Files containing SVRF or TVF only with Mentor
Graphics products. Under no circumstances shall Customer use Products or Files or allow their use for the purpose of developing,
enhancing or marketing any product that is in any way competitive with Products, or disclose to any third party the results of, or
information pertaining to, any benchmark.
5.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use. Customer shall not disclose or permit disclosure of source code,
in whole or in part, including any of its methods or concepts, to anyone except Customers employees or on-site contractors,
excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in any manner
except to support this authorized use.
5.3. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (Attempted Transfer), without Mentor Graphics prior written consent and
payment of Mentor Graphics then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customers permitted successors in
interest and assigns.
5.4. The provisions of this Section 5 shall survive the termination of this Agreement.
6. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.
7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed, will
substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not warrant
that Products will meet Customers requirements or that operation of Products will be uninterrupted or error free. The warranty
period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must notify Mentor
Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty applies only to the
initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a) Software updates or
(b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty shall not be valid if
Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in compliance with this
Agreement. MENTOR GRAPHICS ENTIRE LIABILITY AND CUSTOMERS EXCLUSIVE REMEDY SHALL BE, AT
MENTOR GRAPHICS OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF THE PRODUCTS TO
MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE PRODUCTS THAT DO NOT MEET THIS
LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B)
PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF WHICH ARE PROVIDED AS IS.
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.
8. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY WOULD BE VOID
OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS OR ITS LICENSORS BE
LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR
SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, EVEN IF MENTOR GRAPHICS
OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL MENTOR
GRAPHICS OR ITS LICENSORS LIABILITY UNDER THIS AGREEMENT EXCEED THE AMOUNT RECEIVED FROM
CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR SERVICE GIVING RISE TO THE CLAIM. IN THE CASE
WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITY FOR ANY
DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8 SHALL SURVIVE THE TERMINATION OF THIS
AGREEMENT.
9. HAZARDOUS APPLICATIONS. CUSTOMER ACKNOWLEDGES IT IS SOLELY RESPONSIBLE FOR TESTING ITS
PRODUCTS USED IN APPLICATIONS WHERE THE FAILURE OR INACCURACY OF ITS PRODUCTS MIGHT RESULT IN
DEATH OR PERSONAL INJURY (HAZARDOUS APPLICATIONS). EXCEPT TO THE EXTENT THIS EXCLUSION OR
RESTRICTION OF LIABILITY WOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION
WITH THE USE OF MENTOR GRAPHICS PRODUCTS IN OR FOR HAZARDOUS APPLICATIONS. THE PROVISIONS OF
THIS SECTION 9 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
10. INDEMNIFICATION. CUSTOMER AGREES TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND ITS
LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE OR LIABILITY, INCLUDING ATTORNEYS FEES,
ARISING OUT OF OR IN CONNECTION WITH THE USE OF MENTOR GRAPHICS PRODUCTS IN OR FOR HAZARDOUS
APPLICATIONS. THE PROVISIONS OF THIS SECTION 10 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
11. INFRINGEMENT.
11.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired by
Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics will
pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and agrees
that as conditions to Mentor Graphics obligations under this section Customer must: (a) notify Mentor Graphics promptly in
writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the action; and (c)
grant Mentor Graphics sole authority and control of the defense or settlement of the action.
11.2. If a claim is made under Subsection 11.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
11.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of other
than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that Customer
makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor Graphics
licensors who do not provide such indemnification to Mentor Graphics customers; or (h) infringement by Customer that is
deemed willful. In the case of (h), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.
11.4. THIS SECTION 11 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMERS SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR
TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
12. TERMINATION AND EFFECT OF TERMINATION.
12.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon written
notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement or
any license granted hereunder will not affect Customers obligation to pay for Products shipped or licenses granted prior to the
termination, which amounts shall be payable immediately upon the date of termination.
12.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination, Customer shall ensure that all use of the affected Products ceases, and shall return hardware and
either return to Mentor Graphics or destroy Software in Customers possession, including all copies and documentation, and
certify in writing to Mentor Graphics within ten business days of the termination date that Customer no longer possesses any of
the affected Products or copies of Software in any form.
13. EXPORT. The Products provided hereunder are subject to regulation by local laws and United States (U.S.) government agencies,
which prohibit export, re-export or diversion of certain products, information about the products, and direct or indirect products thereof,
to certain countries and certain persons. Customer agrees that it will not export or re-export Products in any manner without first
obtaining all necessary approval from appropriate local and U.S. government agencies. If Customer wishes to disclose any information
to Mentor Graphics that is subject to any U.S. or other applicable export restrictions, including without limitation the U.S. International
Traffic in Arms Regulations (ITAR) or special controls under the Export Administration Regulations (EAR), Customer will notify
Mentor Graphics personnel, in advance of each instance of disclosure, that such information is subject to such export restrictions.
14. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.
15. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.
16. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customers normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customers
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customers
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 16 shall survive the termination of this Agreement.
17. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America. All disputes arising out of or in relation to this Agreement shall be submitted to the exclusive jurisdiction of the courts
of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when the laws of Ireland apply. Notwithstanding the foregoing,
all disputes in Asia arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a single arbitrator
to be appointed by the chairman of the Singapore International Arbitration Centre (SIAC) to be conducted in the English language, in
accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be incorporated by
reference in this section. Nothing in this section shall restrict Mentor Graphics right to bring an action (including for example a motion
for injunctive relief) against Customer in the jurisdiction where Customers place of business is located. The United Nations
Convention on Contracts for the International Sale of Goods does not apply to this Agreement.
18. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.
19. MISCELLANEOUS. This Agreement contains the parties entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Some Software may contain code distributed under a third party license agreement that may provide
additional rights to Customer. Please see the applicable Software documentation for details. This Agreement may only be modified in
writing, signed by an authorized representative of each party. Waiver of terms or excuse of breach must be in writing and shall not
constitute subsequent consent, waiver or excuse.
Rev. 140201, Part No. 258976

LVflow

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

LVflow

Uploaded by

Copyright:

Available Formats

This manual is part of a fully-indexed Tessent documentation set.

To search across all Tessent manuals, click on the binocular icon

is used pursuant to a sublicense from LMI, the exclusive licensee of

SerDes Test macros.

intfA my_intf_array [3:0][4:0] ();

You might also like