Hybrid TK/LBIST Flow User’s Manual

For Use with Tessent® Shell

Software Version 2014.2

June 2014

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.

© 2013-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

 Table of Contents

Chapter 1
Introduction to the Hybrid TK/LBIST Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Hybrid TK/LBIST Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Bottom-Up Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Step 1: Test Point Generation and Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Step 2: Scan Insertion and X-Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Step 3: EDT and Tessent LogicBIST IP Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Step 4: LogicBIST Fault Simulation and Pattern Creation. . . . . . . . . . . . . . . . . . . . . . . . . 12
Step 5: Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Step 6: Top-Level ICL Network Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Step 7: ICL Extraction and Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Top-Down Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 2
Test Point Generation and Insertion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Test Point Generation and Insertion Step Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Test Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
User-Defined Test Point Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Back-to-Back Test Generation Command Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Multi-Cycle Path and False Path Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Scannability Design Rule Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Analyzing and Inserting the Test Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Test Point Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
delete_test_points Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Test Point Dofile Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Example of Performing Test Point Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Example of Test Point Insertion With Custom Prefix for Inserted Logic . . . . . . . . . . . . . . . 28
Test Point Generation and Insertion Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Chapter 3
Scan Insertion and X-Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Scan Insertion and X-Bounding Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Requirements for Using a Third-Party Scan Insertion Tool . . . . . . . . . . . . . . . . . . . . . . . . 33
X-Bounding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Scan Insertion and X-Bounding Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Performing Scan Insertion and X-Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Example of Scan Insertion and X-Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Scan Insertion and X-Bounding Command Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Hybrid TK/LBIST Flow User’s Manual, v2014.2 3

June 2014
 Table of Contents

Chapter 4
EDT and LogicBIST IP Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
EDT and LogicBIST IP Generation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
TAP Controller and LogicBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Clock Controller Connections to the EDT/LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . 44
EDT and LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Programmable Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Clock Control Logic and Named Capture Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Programmable Capture Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Low-Power Shift. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
IJTAG Network in EDT/LogicBist IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
EDT and LogicBIST IP Generation Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Generating the EDT and LogicBIST IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Output Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Timing Constraints for EDT and LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
EDT and EDT-Bypass Timing Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Constrains for Different Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Usage Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
EDT and LogicBIST IP Generation Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapter 5
LogicBIST Fault Simulation and Pattern Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
LogicBIST Fault Simulation and Pattern Creation Overview . . . . . . . . . . . . . . . . . . . . . . . . 66
Low-Power Shift Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Fault Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Performing LogicBIST Fault Simulation and Pattern Creation. . . . . . . . . . . . . . . . . . . . . . . 68
Example of Core-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Fault Simulation and Pattern Creation Command Summary. . . . . . . . . . . . . . . . . . . . . . . . . 70

Chapter 6
Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Pattern Generation Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Required Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Retargeting Dofile Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Performing Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Example of Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Pattern Generation Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Chapter 7
Top-Level ICL Network Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Top-Level ICL Network Integration Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Performing Top-Level ICL Network Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Example of Top-Level ICL Network Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Top-Level ICL Network Integration Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
Table of Contents

Chapter 8
ICL Extraction and Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
ICL Extraction and Pattern Retargeting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Performing ICL Extraction and Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
ICL Extraction and Pattern Retargeting Command Summary . . . . . . . . . . . . . . . . . . . . . . . 94

Chapter 9
Hybrid TK/LBIST Embedded Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
EDT/LogicBIST IP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Hybrid EDT/LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Shared Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Inserted LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
New LogicBIST Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Programmable Registers Inside Hybrid IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Low-Power Shift Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Appendix A
Interface Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Interface Pin Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
LogicBIST Controller Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Clock Controller Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
EDT/LogicBIST Wrapper Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Segment Insertion Bit Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Appendix B
File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Synthesis Script Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Timing Script Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
ICL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
PDL Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Appendix C
ECO Implementation in the Hybrid TK/LBIST Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Appendix D
Test Coverage Reporting During Test Point Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Test Coverage Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Incremental Relevant Test Coverage Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
False Paths and Test Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Fault Classes and Fault Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
“Blocked by xbounding” Faults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Uncontrollable/Unobservable Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Hybrid TK/LBIST Flow User’s Manual, v2014.2 5

June 2014
 Table of Contents

Example Test Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Appendix E
PrimeTime Script for Preventing Test Points on Critical Paths . . . . . . . . . . . . . . . . . . . . 117
Using the PrimeTime Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Appendix F
Test Point Analysis for Target Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Appendix G
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Third-Party Information
End-User License Agreement

6 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 List of Figures

Figure 1-1. Per-Core Steps (Bottom-Up Method) or Top-Down Method Steps . . . . . . . . . . 10

Figure 1-2. Complete Flow (Bottom-Up Method). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 2-1. Test Point Generation and Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 2-2. AND Control Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 2-3. OR Control Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 2-4. Observe Point Sharing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 2-5. Test Point Sharing Across Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 3-1. Scan Insertion and X-Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 3-2. Inverted Feedback Muxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 4-1. EDT and LogicBIST IP Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 4-2. TAP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 4-3. Clock Controller Before IP Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 4-4. Clock Controller After EDT/LogicBIST IP Generation . . . . . . . . . . . . . . . . . . . 46
Figure 4-5. Block-Level View of the EDT/LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 4-6. Final Top-Level Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 4-7. Clocking During EDT Shift Mode of Operation. . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 4-8. SIBs Insertion and Integration of Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 5-1. LogicBIST Fault Simulation and Pattern Creation . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 6-1. Pattern Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 7-1. Top-Level SIB Netlist Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 7-2. Top-Level ICL Network Integration Dofile Example . . . . . . . . . . . . . . . . . . . . 84
Figure 7-3. DftSpecification Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 8-1. ICL Extraction and Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figure 9-1. Timing Diagram for LogicBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 9-2. Low-Power Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Hybrid TK/LBIST Flow User’s Manual, v2014.2 7

June 2014
 List of Tables

Table 2-1. Test Point Analysis and Insertion Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Table 3-1. Scan Insertion and X-Bounding Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Table 4-1. EDT and LogicBIST IP Generation Output Files . . . . . . . . . . . . . . . . . . . . . . . . 55
Table 4-2. EDT and LogicBIST IP Generation Commands . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 5-1. Fault Simulation and Pattern Creation Commands . . . . . . . . . . . . . . . . . . . . . . . 70
Table 6-1. Pattern Generation Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table 7-1. Top-Level ICL Network Integration Commands . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 8-1. ICL Extraction and Pattern Retargeting Commands . . . . . . . . . . . . . . . . . . . . . . 94
Table A-1. LogicBIST Controller Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Table A-2. Clock Controller Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Table A-3. EDT/LogicBIST Wrapper Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table A-4. SIB Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

8 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 1
Introduction to the Hybrid TK/LBIST Flow

Using the hybrid TK/LBIST flow, you can share the EDT and the Tessent LogicBIST IP in your
design to reduce hardware overhead.
This chapter provides the high-level introduction to the hybrid TK/LBIST flow.

Hybrid TK/LBIST Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Bottom-Up Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Step 1: Test Point Generation and Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Step 2: Scan Insertion and X-Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Step 3: EDT and Tessent LogicBIST IP Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Logic Synthesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Step 4: LogicBIST Fault Simulation and Pattern Creation. . . . . . . . . . . . . . . . . . . . . . . . . 12
Step 5: Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Step 6: Top-Level ICL Network Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Step 7: ICL Extraction and Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Top-Down Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Note
In this manual, the terms “LogicBIST” and “LBIST” are used interchangeably.

Hybrid TK/LBIST Flow Overview

The hybrid TK/LBIST flow is based on Tessent Shell and uses the logicTest controller you
insert with hybrid logic to share EDT and Tessent LogicBIST IP to reduce hardware overhead.
This document describes the LogicBIST portion of the hybrid flow. For EDT-specific
information, consult the Tessent TestKompress User's Manual.

You can implement hybrid TK/LBIST with either the Bottom-Up Flow or Top-Down Flow.

Bottom-Up Flow
When implementing the hybrid flow with the bottom-up method, you analyze each core in
isolation. As soon as a core design is available, you can move on to the embedded insertion and
simulation processes for this core without having to wait for the other cores, including the top-
level core.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 9

June 2014
Introduction to the Hybrid TK/LBIST Flow
Bottom-Up Flow

Figure 1-1 shows the 5-step flow you perform on each of your cores. Note that the same steps
(1-5) are used for the top-down method—see “Top-Down Flow.”

Figure 1-1. Per-Core Steps (Bottom-Up Method) or Top-Down Method Steps

Design dofile
Netlist

Step 1: Test Point Generation and Insertion

Netlist with dofiles

Test Points

Step 2: Scan Insertion and X-Bounding

BIST-ready dofiles
Netlist

EDT/LBIST Step 3: EDT and LogicBIST IP Generation Netlist with

ICL and PDL EDT/LBIST IP

Created
manually NCPs and Test dofiles
Setup

Step 4: LogicBIST Fault Simulation and

Pattern Generation

patDB and Verilog Testbench

Graybox
TCD Files Parallel Patterns
Core Level Signature, Coverage

Step 5: Pattern Generation

Top-Level Created Serial Patterns, WGL,

ICL and PDL manually Verilog, STIL, ...

Top-Level Steps 6-7 for Bottom-Up Method (in Fig. 1-2)

Step 1: Test Point Generation and Insertion

In the first step of the flow, you use Tessent Shell to read in a gate-level non-scan Verilog netlist
of your design, and generate and insert test points.

10 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Introduction to the Hybrid TK/LBIST Flow
Bottom-Up Flow

Upon completion, you use Tessent Shell to write out both the modified design and the scan
setup dofile, both of which you use for scan insertion and X-bounding—see “Test Point
Generation and Insertion.”

Step 2: Scan Insertion and X-Bounding

In the second step of the flow, you insert scan chains into the modified design containing the
test points, and then you perform X-bounding.
Note
The recommended flow is to always insert the X-bounding logic after you perform scan
insertion.

Subsequently, the tool writes out the test procedure file and a dofile, which contains the
information you use for the EDT and Tessent LogicBIST IP generation—see “Scan Insertion
and X-Bounding.”

Step 3: EDT and Tessent LogicBIST IP Generation

During the third step of the flow, you generate the shared EDT/Tessent LogicBIST logic RTL.
One LogicBIST controller is created for all EDT/Tessent LogicBIST blocks in a core.
You can also configure the low-power scheme to control the switching activity during “shift” to
reduce power consumption.

There is no TAP controller at the core level. New core-level pins corresponding to the SIB
control signals, tck, and LBIST scan I/O are created in this step. The core-level Verilog patterns
operate these pins directly. These pins are subsequently connected to the TAP controller at the
top level of the design—see “Top-Level ICL Network Integration.”

As part of IP generation, the tool writes out the following files:

• ICL File — Consists of ICL module description for the LBIST controller and all
EDT/Tessent LogicBIST blocks tested by this controller.
• PDL File — Contains iProcs at the core level that use the ICL modules written out.
During IP generation, the generated ICL file describes only the LogicBIST and EDT modules.
The ICL file includes the core-level pin names and connectivity found from the core-level
design netlist. The extracted ICL file is used during top-level pattern generation—see “ICL
Extraction and Pattern Retargeting.” Verilog patterns can be written out in this step and
simulated to verify the test operation at the core level.

For complete information, see “EDT and LogicBIST IP Generation.” In steps 1 through 3 of the
flow, new top-level test pins are added and/or existing top-level test pins controlled internally
by the EDT/Tessent LogicBIST IP.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 11

June 2014
Introduction to the Hybrid TK/LBIST Flow
Bottom-Up Flow

Logic Synthesis
You must synthesize all the EDT/Tessent LogicBIST blocks and the common LogicBIST
controller. For this reason, the tool generates a single synthesis script. You use the synthesized
gate-level netlist output from your synthesis tool (for example, the output of the logic synthesis
step with Synopsys Design-Compiler) as input to the next step of the flow.

Step 4: LogicBIST Fault Simulation and Pattern

Creation
During the fourth step of the flow, you perform the tasks of fault simulation and saving the
parallel LogicBIST patterns.
The core level fault simulation run computes the test coverage for the core, MISR signature, and
power consumption. The following files are generated as the output of this step and are used
later in top-level ICL extraction and pattern retargeting:

• PatternDB File — Contains the pattern data and the relevant LBIST register values per
pattern such as PRPG, MISR, and low-power registers.
• Tessent Core Description file (TCD) — Contains the description of the core that is
relevant for the LogicBIST mode of operation.
For subsequent diagnosis, you can use Tessent Diagnosis to perform diagnosis with the EDT
patterns.

See “LogicBIST Fault Simulation and Pattern Creation” for complete information.

Step 5: Pattern Generation

In the fifth step of the flow, you generate core-level patterns for the bottom-up method and top-
level patterns (including a Verilog test bench) for the LogicBIST controller for the top-down
method. This step also generates the chip-level serial patterns that can be applied from the
tester.
The tool supports all formats currently supported for ATPG. See “Pattern Generation” for
complete information.

After you implement TK/LBIST on each core of your design, you must perform steps 6-7 to
bring information of your embedded structures to the top level. Figure 1-2 illustrates the
complete TK/LBIST hybrid flow when using the bottom-up method.

• On the left side — Per-Core Steps.

Steps 1-5 are repeated once for each core in your design. These are the steps that are
discussed following Figure 1-1.

12 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Introduction to the Hybrid TK/LBIST Flow
Bottom-Up Flow

• On the right — Top-Level Steps.

Steps 6-7 are performed once with the top-level netlist containing all the cores.

Figure 1-2. Complete Flow (Bottom-Up Method)

Per-Core Steps Top-Level Steps

Step 1: Test Point Generation Top-Level

and Insertion Core 1 ... Core N Interconnect
Netlist Netlist between Cores

Step 2: Scan Insertion

and X-Bounding Step 6: Top-Level ICL Network
Integration
Step 3: EDT and LogicBIST IP
Generation Top-Level
Core 1 Netlist Top-Level
TCD, patDB ICL/PDL
Core 1 (TAP, SIBs)
Step 4: LogicBIST Fault Simulation
ICL/PDL
and Pattern Creation
. Step 7: ICL Extraction
. and Pattern Retargeting
.
Pattern
Step 5: Pattern Generation Core N
Retarget
TCD, patDB
dofile
Core N
ICL/PDL Verilog Tester
Simulation Patterns
Core-Level Core-Level
TCD, patDB Netlist Patterns (WGL, STIL)
ICL/PDL

Step 6: Top-Level ICL Network Integration

In the sixth step of the flow, you use the top-level netlist that instantiates all the LogicBIST
implemented cores.
You insert IJTAG-compliant SIBs to provide access to each of the LogicBIST cores as well as
to connect these SIBs and cores to the top-level TAP controller. We recommend that you
shadow each core by a separate SIB to provide maximum flexibility for test scheduling. You
can also connect EDT control signals from the core to the top level at this time. Additionally,
you can create a Tcl script that uses Tessent Shell netlist editing features to automate this task.
See “Top-Level ICL Network Integration” for complete information.

Step 7: ICL Extraction and Pattern Retargeting

In the seventh and final step of the flow, you use the fully-integrated top-level netlist, top-level
ICL/PDL files for your IJTAG instruments, such as the TAP controller and clock controller and
the per-core LogicBIST files generated at the core level.
ICL extraction can again be used here instead of manually creating the top-level ICL describing
the SIB access network and connectivity between your instruments and the LogicBIST cores.
The final tester patterns can be written out in any of the supported formats.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 13

June 2014
Introduction to the Hybrid TK/LBIST Flow
Top-Down Flow

You must provide the pattern retargeting dofile that includes all LogicBIST cores and the
desired scheduling. See “ICL Extraction and Pattern Retargeting” for complete information.

Top-Down Flow
When implementing the hybrid flow with the top-down method, the analysis is performed on the
entire pre-DFT inserted view of your chip. Each core is analyzed within the respective context
of its parents.
For the top-down method, you use the same steps as when you implement the hybrid TK/LBIST
flow on the core level except without top-level ICL network insertion and extraction or ICL
pattern generation (steps 6 and 7).

Figure 1-1 illustrates the steps when using the top-down method. See “Bottom-Up Flow” for
more information. You define blocks for insertion and run steps 1 through 5 as follows:

• Test Point Generation and Insertion and Scan Insertion and X-Bounding — These steps
are similar to those performed using the bottom-up method.
• EDT and LogicBIST IP Generation — EDT/LogicBIST hybrid IP generation is almost
the same as the step used with the bottom-up method except that the TAP controller is
present at the top level.
• LogicBIST Fault Simulation and Pattern Creation and Pattern Generation — These steps
are similar to those performed using the bottom-up method.

14 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 2
Test Point Generation and Insertion

This chapter provides detailed information on the tasks performed during the Test Point
Generation and Insertion step of the flow.
Test Point Generation and Insertion Step Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Test Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Back-to-Back Test Generation Command Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Multi-Cycle Path and False Path Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Scannability Design Rule Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Analyzing and Inserting the Test Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Test Point Deletion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
delete_test_points Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Test Point Dofile Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Example of Performing Test Point Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Test Point Generation and Insertion Command Summary. . . . . . . . . . . . . . . . . . . . . . . 28

Hybrid TK/LBIST Flow User’s Manual, v2014.2 15

June 2014
Test Point Generation and Insertion
Test Point Generation and Insertion Step Overview

Test Point Generation and Insertion Step

Overview
In the test point generation and insertion step of the hybrid TK/LBIST flow, you generate and
insert test points into the netlist to achieve high test coverage.
During test point analysis and insertion, you add random pattern test points to certain locations
in your design. By adding these test points, you can increase the testability of the design by
improving controllability or observability.

Figure 2-1 illustrates this step within hybrid TK/LBIST flow.

Figure 2-1. Test Point Generation and Insertion

Non-scan Tessent Cell

Verilog Netlist Library

Step 1: Test Point Generation and Insertion

Netlist with dofiles

Test Points

Step 2: Scan Insertion and X-Bounding

Step 3: EDT and LogicBIST IP Generation

Step 4: LogicBIST Fault Simulation and

Pattern Creation

Step 5: Pattern Generation

Step 6: Top-Level ICL Network Integration

(only for Bottom-Up Method)

Step 7: ICL Extraction and Pattern Retargeting

(only for Bottom-Up Method)

16 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Generation and Insertion
Test Point Generation and Insertion Step Overview

Note
You generate and insert the test points as a separate step from scan insertion—you cannot
perform the two operations together.

At the conclusion of test point generation and insertion, you write out both the modified design
netlist containing the test points and a dofile containing all the necessary steps for the next step
of the flow—see “Scan Insertion and X-Bounding.”

Requirements
Performing test point generation and insertion has certain requirements.
You must adhere to the following:

• Test point insertion runs on a non-scan gate-level Verilog netlist. Your design can
contain scan cells, but not scan chains.

Note
Test point insertion also supports designs with scan chains; however, the recommended
practice is to use a non-scan netlist.

• You can read in functional SDC so the tool omits adding any test points to multi-cycle
paths or false paths—see the read_sdc command.
• The tool identifies potential scan candidates for correct controllability/observability
analysis. To ensure that eventual non-scan cells are not used as the destination for
observe points or source for control points, you should declare all the non-scan instances
during test point insertion using the add_nonscan_instances command.
• You should define black boxes using the add_black_boxes command so that test point
analysis can incorporate this information.
• If you are performing test point analysis on a pre-scan netlist that has unconnected clock
gaters, you should add the “set_clock_gating on” command to your dofile.

Test Points
The inserted test points consist of control points and observe points.
Refer to the Control Points and Observe Points sections for details. During test point analysis
and insertion, the tool inserts these test points at gate outputs—see also “User-Defined Test
Point Handling.”

Control Points
You can insert two types of control points, AND Control Points or OR Control Points.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 17

June 2014
Test Point Generation and Insertion
Test Point Generation and Insertion Step Overview

• AND Control Points

Figure 2-2. AND Control Point

• OR Control Points

Figure 2-3. OR Control Point

Control points do not change during capture cycles. The AND and OR control points are
mutually exclusive; specifically, the tool does not insert both an AND and an OR control point
on the same net.

Control Point Enable

By default, the control points are enabled using the lbist_en signal. However, this restricts usage
of the control points only during BIST mode. To have independent control, we recommend that
you use a separate enable signal for the control points.
You specify a different enable signal using the set_test_point_insertion_options command as
follows:

set_test_point_insertion_options -control_point_enable pin_path_name

This allows you to use the control points beyond just LogicBIST mode.

Control Point Clocking

The tool looks at all the flops in the fan-out cone of the test point and chooses the clock that
drives the largest number of scan flops in the fan-out cone. If no scan flops are found in the fan-
out cone, the tool chooses the clock that drives the largest number of scan flops in the fan-in
cone.

18 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Generation and Insertion
Test Point Generation and Insertion Step Overview

Once the target clock is identified, the tool again processes the fan-out cone and taps the target
clock from the clock port of the scan flop that is logically closest to the Verilog hierarchy. Once
again, if it cannot find any scan flops in the fan-out cone, it picks the closest one in the fan-in
cone.

In the event that no scan flops are in either cone, the tool uses the test clock by tapping the
source of the test clock signal (either at the primary input pin or at the source of the clock signal
defined with the add_clock -internal command).

Note
Potentially scannable flops are also considered as “scan flops” during the clock selection
analysis. Non-scan flops are ignored during the test point clock selection processing.

Observe Points
Tessent Shell inserts observe points in the form of new scan cells at gate outputs to improve the
observability of the netlist. The tool supports both a dedicated scan cell per observation point
and a scan cell shared by multiple observation points. When sharing the new scan cell among
several observation points, the tool inserts an XOR tree.
Figure 2-4 shows an example of two cones of logic connected through an XOR gate and
observed with the same observation point.

Figure 2-4. Observe Point Sharing

Observe Point Enable

By default, the tool uses the lbist_en signal for enabling the observe points. This restricts the use
of these observe points only for BIST mode. To allow usage of these test points in other test
modes, we recommend that a separate signal be used to enable the observe points. Furthermore,
you can use separate enable signals for control and observe points just to keep their controls
independent and flexible.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 19

June 2014
Test Point Generation and Insertion
Test Point Generation and Insertion Step Overview

You specify a different enable signal in one of the following ways:

• Using the add_observe_points command to specify an individual observe point

(manually added) as follows:
add_observe_points -enable enable_pin/port

• Using the set_test_point_insertion_options command to specify the default enable signal

for the automatically identified observe points:
set_test_point_insertion_options -observe_points_enable

This allows you to use the observe points beyond just LogicBIST mode.

Observe Point Clocking

The tool looks at all the flip-flops in the fan-in cone of the test point and chooses the clock that
drives the largest number of scan flip-flops in the fan-in cone. If no scan flip-flops are found in
the fan-in cone, the tool chooses the clock that drives the largest number of scan flip-flops in the
fan-out cone.
Once the target clock is identified, the tool again processes the fan-in cone and taps the target
clock from the clock port of the scan flop that is logically closest to the Verilog hierarchy. Once
again, if the tool cannot find any scan flip-flops in the fan-in cone, it chooses the closest one in
the fan-out cone.

If no scan flip-flops are in either cone, the tool uses the test clock by tapping the source of the
test clock signal (either at the primary input pin, or at the source of the clock signal defined via
the add_clock -internal command).

Note
Potentially scannable flip-flops are also considered as “scan flip-flops” during the clock
selection analysis. Non-scan flip-flops are ignored during the test point clock selection
processing.

Test Point Sharing Across Power Domains

If your design contains multiple power domains, you should not share test points across power
domains. By loading power data with the read_cpf or read_upf file, you prevent any test point
sharing across power domains.
Here is an example of a (partial) CPF file:

set_design design_top
create_power_domain -name PD1 -default
create_power_domain -name PD2 -instances {b1}
create_power_domain -name PD3 -instances {b2}

20 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Generation and Insertion
User-Defined Test Point Handling

Figure 2-5 shows an example of two blocks b1 and b2 which are in different power domains. In
this case, the test point at \b1\u1\z will never be merged with any of the test points in the \b2
block.

Figure 2-5. Test Point Sharing Across Power Domains

User-Defined Test Point Handling

You can specify user-defined test points using the add_control_points and add_observe_points
commands.
How the tool handles your user-defined test points depends on whether you have already
inserted tool-generated test points as follows:

Hybrid TK/LBIST Flow User’s Manual, v2014.2 21

June 2014
Test Point Generation and Insertion
Back-to-Back Test Generation Command Handling

• Adding Test Points Before Test Point Generation — The following command
sequence demonstrates this:
ANALYSIS> add_control_point -location OY4 -type and // Adds a user-defined control point
ANALYSIS> analyze_test_points // Performs the analysis and inserts test points
ANALYSIS> insert_test_logic
...

When you issue the analyze_test_points command, then the tool takes the user-defined
test points in account.
• Adding Test Points After Test Point Generation — The following command
sequence demonstrates this:
ANALYSIS> analyze_test_points // Performs the analysis and inserts test points
ANALYSIS> add_control_point -location OY4 -type and // Tool can reject these test points
ANALYSIS> insert_test_logic
...

If you specify user-defined test points using the add_control_points or add_observe_points

commands after analysis but prior to insertion, then the tool inserts these test points into the
design unless the test points are in the same location as a tool-generated test point.

Back-to-Back Test Generation Command

Handling
The analyze_test_points command generates test points based on the default settings or any
analysis options you specify. If you issue the analyze_test_points command a second time, no
new test points will be generated.
ANALYSIS> analyze_test_points // Performs the analysis and generates test points
ANALYSIS> analyze_test_points // No new test points are generated

If you change any of the analysis options before issuing the analyze_test_points command a
second time, the tool will generate new test points based on the current options. For example:

ANALYSIS> analyze_test_points // Performs the analysis and generates test points

ANALYSIS> set_test_point_analysis_options -total_number 2000
ANALYSIS> analyze_test_points // New test points are generated

You can use the delete_test_points command to delete all existing test points and generate new
test points with the analyze_test_points command.

ANALYSIS> delete_test_points -all // Deletes all existing test points

ANALYSIS> analyze_test_points // Generates new test points

22 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Generation and Insertion
Multi-Cycle Path and False Path Handling

If you issue any command between back-to-back analyze_test_points commands that does not
impact test point generation, the tool will report the same test points again.

Multi-Cycle Path and False Path Handling

During test point analysis and insertion, you identify multi-cycle paths and false paths in a
functional SDC file that you read into the tool using the read_sdc command. The tool does not
insert observe points or controls points on these paths.
If you want to add test points in the MCP/false paths for slow-speed tests, then do not read in the
functional SDC in the tool.

On the other hand, if you do not have a functional SDC and would like to exclude test points
from MCP/FP, then you use the following command:

set_test_point_analysis_options -exclude_cross_domain_paths on

Scannability Design Rule Checking

Prior to test point insertion, specifically when you change tool’s mode to Analysis, the tool
performs scannability checking to ensure that the tool can safely convert a sequential element to
a scan element. It is important for the tool to identify potential scan cells, therefore you need to
make sure that all the scannability checks pass.
Note
The tool identifies the non-SDC based potential X-sources during this step. However, the
analyze_xbounding command must be issued in order to complete the analysis and also to
determine the location of the bounding muxes. Refer to “Scan Insertion and X-Bounding”

During DRC, the tool performs the following two main checks for each sequential element in
the design:

• S1 — Ensures that when all defined clocks (including sets and resets) are at their off-
states, and the sequential elements remain stable and inactive.
• S2 — Ensures that for each defined clock, sequential elements can capture data when all
the other defined clocks are off.
These scanability checks determine if the tool can turn off all set and reset lines and turn on and
off all clock inputs of sequential cells from the design's primary input pins. Without this
controllability, Tessent Shell does not allow a sequential element to pass scanability checks,
which is a requirement to be considered for scan identification.

For more information, refer to Scannability Rules (S Rules) in the Tessent Shell Reference
Manual.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 23

June 2014
Test Point Generation and Insertion
Analyzing and Inserting the Test Points

Analyzing and Inserting the Test Points

The following procedure enables you to analyze and insert test points into a non-scan design
using Tessent Shell.

Prerequisites
• A non-scan gate-level Verilog netlist
• Tessent Cell Library—see the Tessent Cell Library Manual for complete information.

Procedure
1. From a shell, invoke Tessent Shell using the following syntax:
% tessent -shell

After invocation, the tool is in unspecified setup mode. You must set the context before
you can invoke the test point insertion commands.
2. Set the tool context to test point generation using the set_context command as follows:
SETUP> set_context dft -test_points -no_rtl

3. Load the non-scan gate-level Verilog netlist using the read_verilog command.
SETUP> read_verilog my_netlist.v

4. Load one or more cell libraries into the tool using the read_cell_library command.
SETUP> read_cell_library atpg.lib

5. Set additional parameters as necessary. For example, declaring non-scan instances,

black boxes, pin constraints, and clocks.
6. If required, read in the SDC file containing the multi-cycle and false path information
using the read_sdc command—see “Multi-Cycle Path and False Path Handling.”
7. If the design contains multiple power domains, use the read_cpf or read_upf command
to prevent the sharing of test points across power domains.
8. Specify the test point generation options using the set_test_point_insertion_options
command. For example:
SETUP> set_test_point_insertion_options -observe_point_share 4

9. Change the tool’s system mode to analysis using the set_system_mode command.
SETUP> set_system_mode analysis

During the transition from setup to analysis modes, the tool flattens the netlist and
performs Scannability Rules (S Rules) design rules checking. You must resolve any
DRC rule violations that result in an error before you can move to analysis mode.

24 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Generation and Insertion
Test Point Deletion

The tool identifies the non-SDC based potential X-sources during this step. Test point
analysis must also consider the location of the yet-to-be-inserted bounding muxes that
will prevent the identified X-sources from reaching any scan cells. The necessary
analysis is done automatically as part of the analyze_test_points command.
10. Set up the test point analysis options using the set_test_point_analysis_options
command. For example:
ANALYSIS> set_test_point_analysis_options -pattern_count_target 100000

In analysis mode, the tool retains the enabled commands that you set to characterize the
generation of test points.
11. Perform the test point analysis using the analyze_test_points command:
ANALYSIS> analyze_test_points

You have now generated the test points. To insert the test points, proceed to the next
step.
12. If required, report the test points for your design using the report_test_points command.
ANALYSIS> report_test_points

13. Add test points to your design, and then transition to insertion mode using the
insert_test_logic command.
ANALYSIS> insert_test_logic

14. Write out the modified design netlist containing the test points using the write_design
command as in the following example:
INSERTION> write_design -output_file my_modified_design.v

15. Write out the dofile containing all the necessary steps for scan insertion using the
write_scan_setup command as in the following example:
INSERTION> write_scan_setup -prefix lbist_scan_setup

16. You use this dofile as input for the next step—Scan Insertion and X-Bounding.

Test Point Deletion

This section explains the methods for deleting test points.
After you have issued the analyze_test_points command, you cannot reduce the number of test
points with the set_test_point_analysis_options command. However, you can delete the test
points using one of the following methods: delete_test_points Command or Test Point Dofile
Modification.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 25

June 2014
Test Point Generation and Insertion
Example of Performing Test Point Insertion

delete_test_points Command
You can delete a subset of the tool-generated test points.
Use the delete_test_points command to specify the locations that you want to remove from the
list of identified test points.

Note
Do not re-issue the analyze_test_points command if you are using this method.

You should use this method if you only have a small number of test points to delete.

Test Point Dofile Modification

If you have a large number of test points that you need to delete, you can modify the dofile.

Procedure
1. Use the write_test_point_dofile command to write out the dofile that contains the test
points. For example:
ANALYSIS> write_test_point_dofile -output_file my_test_points.dofile

2. Edit this dofile and remove the test points you do not want.
3. From within Tessent Shell, delete all of the test points using the delete_test_points
command as follows:
ANALYSIS> delete_test_points -all

4. Use the dofile command to read the modified test point dofile back into the tool. For
example:
ANALYSIS> dofile my_test_points_modified.dofile

Example of Performing Test Point Insertion

This example demonstrates how to identify and insert test points into a design.
SETUP> set_context dft -test_points -no_rtl
SETUP> read_verilog non_scan_design_name
SETUP> read_cell_library cell_library_name
SETUP> read_sdc sdc_file_name
SETUP> set_current_design
SETUP> set_test_logic -set off -reset off

26 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Generation and Insertion
Example of Performing Test Point Insertion

SETUP> set_test_logic -clock off -ram off

SETUP> set_test_point_analysis_options -total_number 10000 \
-test_coverage_target 99.5 -pattern_count_target 200000
SETUP> set_system_mode analysis
ANALYSIS> set_test_point_insertion_options -control_point pin_path_name
ANALYSIS> analyze_test_points
ANALYSIS> report_test_points
ANALYSIS> insert_test_logic
INSERTION> write_design output lbist_ready.v
INSERTION> write_scan_setup -prefix lbist
INSERTION> exit

• The example starts by loading the design and the cell library.
• Next, we load an SDC file. The SDC file defines false and multi-cycle paths. This
information will be used during test point analysis (analyze_test_points) to prevent the
insertion of test points in these regions.
• Test point analysis can be performed prior to scan insertion. In this case, the tool must
first determine which flops will be converted to scan cells. The set_test_logic command
determines if cells with S-rule DRC violations are converted to scan cells or remain non-
scan.
• The set_test_point_analysis_options command allows you to specify the maximum
number of test points that should be added to the design. The
set_test_point_insertion_options command determines the name of the new primary
input pin that will enable the test points.
• The next set of commands transitions into analysis mode, performing a variety of design
rule checks during the transition, and performs test point analysis to identify test points
that improve random pattern testability to achieve the target fault coverage.
• The final set of commands transitions to insertion mode. The internal representation of
the netlist is updated to include the target test points. The updated netlist is written out
along with a dofile and test procedure file that can be used to reload this design in the dft
-scan context.
• Typically, the test points will be connected to newly inserted non-scan flops. These flops
must be stitched into scan chains by transitioning into the dft -scan context and
following the Tessent Shell scan insertion flow.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 27

June 2014
Test Point Generation and Insertion
Example of Test Point Insertion With Custom Prefix for Inserted Logic

Note
If you do not have a non-scan flop in your library, you can instruct the tool to insert a scan
flop with the scan_enable and scan_in signals tied low such that they will be targeted for
scan chain stitching in a subsequent run. You must specify the scan cell using the
“add_cell_models -type scan_cell” command.

Example of Test Point Insertion With Custom

Prefix for Inserted Logic
To define a custom prefix that will be used during test point insertion, overriding the default
prefix ts_, use the set_insert_test_logic_options command.
The following example prefixes all inserted nets and instances in the output_lbist_ready.v
netlist with demo_:

SETUP> set_context dft -test_points -no_rtl

SETUP> read_verilog non_scan_design_name
SETUP> read_cell_library library_name
SETUP> set_current_design
SETUP> set_system_mode analysis
ANALYSIS> analyze_test_points
ANALYSIS> set_insert_test_logic_options -inserted_object_prefix demo_
ANALYSIS> insert_test_logic
ANALYSIS> write_design output_lbist_ready.v
ANALYSIS> exit

Test Point Generation and Insertion Command

Summary
Tessent Shell provides a number of commands that enable you to perform test point generation
and insertion.
Table 2-1 lists the Tessent Shell test point analysis and insertion commands.

Table 2-1. Test Point Analysis and Insertion Commands

Command Description
add_black_boxes Defines instances of Verilog modules or ATPG library
models as black boxes for ATPG and sets the constrained
value on output or bidirectional black box pins.

28 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Generation and Insertion
Test Point Generation and Insertion Command Summary

Table 2-1. Test Point Analysis and Insertion Commands

Command Description
add_control_points Adds user-defined control points.
add_nonscan_instances Marks specific sequential elements for exclusion from
the scan insertion process.
add_observe_points Adds user-defined observe points.
analyze_test_points Performs the test points analysis.
delete_test_points Deletes all or specified test points.
get_insert_test_logic_options Retrieves the current prefix that will be used when
creating test point logic.
insert_test_logic Inserts test structures you define into the netlist to
increase the design testability.
read_cell_library Loads one or more cell libraries into the tool.
read_cpf Reads in the CPF (Common Power Format) file that
loads power domain information and prevents sharing of
test points across power domains.
read_sdc Reads in the SDC file that describes the false and multi-
cycle paths that should be blocked during LogicBIST.
read_upf Reads in the UPF (Universal Power Format) file that
loads power domain information and prevents sharing of
test points across power domains.
read_verilog Reads one or more Verilog files into the specified or
default logical library.
report_notest_points Used with the -tool_identified switch, reports the notest
points added by the tool.
report_test_points Displays both user-defined and system-defined test
points.
set_context Specifies the current usage context of Tessent Shell.
set_insert_test_logic_options Specifies a prefix that overrides the default prefix “ts_”
that is used when creating the test point logic.
set_system_mode Specifies the operational state you want the tool to enter.
set_test_point_analysis_options Sets the maximum number of test points, the breakdown
in control and observe points, the target fault coverage
and the maximum number of pseudo random patterns to
be applied.
set_test_point_insertion_options Specifies how many test points to control/observe per
scan cell and how to specify the test point enable signal.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 29

June 2014
Test Point Generation and Insertion
Test Point Generation and Insertion Command Summary

Table 2-1. Test Point Analysis and Insertion Commands

Command Description
write_design Writes out the modified design netlist containing the test
points.
write_scan_setup Writes out a dofile containing all necessary steps for scan
insertion. This command also writes out a test procedure
file if you loaded during the session.
write_test_point_dofile Writes out a dofile containing the test points

30 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 3
Scan Insertion and X-Bounding

This chapter provides detailed information on the tasks performed during Scan Insertion and X-
Bounding.
Scan Insertion and X-Bounding Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Requirements for Using a Third-Party Scan Insertion Tool . . . . . . . . . . . . . . . . . . . . . . . . 33
X-Bounding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Performing Scan Insertion and X-Bounding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Example of Scan Insertion and X-Bounding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Scan Insertion and X-Bounding Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Hybrid TK/LBIST Flow User’s Manual, v2014.2 31

June 2014
Scan Insertion and X-Bounding
Scan Insertion and X-Bounding Overview

Scan Insertion and X-Bounding Overview

You can perform scan insertion and X-bounding within the hybrid TK/LBIST flow.
Figure 3-1 illustrates the flow.

Figure 3-1. Scan Insertion and X-Bounding

Step 1: Test Point Generation and Insertion

Netlist with dofiles

Test Points

Step 2: Scan Insertion and X-Bounding

BIST-ready dofiles
Netlist

Step 3: EDT and LogicBIST IP Generation

Step 4: LogicBIST Fault Simulation and

Pattern Creation

Step 5: Pattern Generation

Step 6: Top-Level ICL Network Integration

(only for Bottom-Up Method)

Step 7: ICL Extraction and Pattern Retargeting

(only for Bottom-Up Method)

Note
The recommended flow is to always insert the X-bounding logic after you perform scan
insertion.

32 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Scan Insertion and X-Bounding
Scan Insertion and X-Bounding Overview

You insert scan chains into the modified netlist that contains the test points and then perform
X-bounding using Tessent Shell (or a third-party tool). You should adhere to the following
during this step:

• Inputs — The modified design netlist with test points and the dofile you have generated
using the Tessent Shell write_scan_setup command.
• MCPs and Failing Paths — You read in SDC to identify MCP/FP and add DFT for
preventing capture of any transition on such paths.
• Cross-Domain Paths — The tool X-bounds cross-domain paths.
• X-Bounding — You must perform X-bounding. Perform this step after scan insertion.
• Outputs — A LogicBIST-ready netlist, test procedure file, and the dofile for the
existing scan chains.
After you complete the scan insertion and X-bounding, you use Tessent Shell to write out the
test procedure file and dofile for the existing design with scan chains that you use as input to the
next step of the flow, “EDT and LogicBIST IP Generation.”

Requirements for Using a Third-Party Scan

Insertion Tool
Tessent Shell must make certain assumptions about which flip-flops in the design are converted
to scan and which cells remain non-scan. If you are using a third-party scan insertion tool, then
these assumptions might not be correct.
Specifically, the primary factors in determining the conversion of non-scan flops to scan flops
are the S-rule DRC violations and the availability of a suitable scan model. In general, flops
with S-rule violations are not converted to scan cells unless you use the following command:

set_test_logic -clock on -set on -reset on

You might need to read the design into Tessent Shell and go through DRC. You can
subsequently post DRC use the report_sequential_instances command to report the exact status
for each flop in the design.

X-Bounding
After scan insertion, you must perform the X-bounding to prohibit all X generators (that is, non-
scan cells, black boxes, and primary inputs) from reaching a scan cell. The source of the x-
bounding mux could either be existing scan cells in the design or newly-inserted scan cells.
Tessent Shell performs the following operations during X-bounding:

• X sources are identified as part of DRCs, specifically E5 violations.

• All identified X sources are bounded from reaching scan cells.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 33

June 2014
Scan Insertion and X-Bounding
Scan Insertion and X-Bounding Overview

• A multiplexer is introduced to block propagation of an X.

• To increase controllability, the second input of the mux is driven by scan cell.
• Clocks for destination cells are analyzed to choose clocks for new scan cell or choose an
existing scan cell.
The following topics are discussed in detail in the following sections:

• X-Bounding Control Signals (Existing or New Scan Cells)

• Clock Selection
• Multiple Clock Domain Handling
• False and Multi-Cycle Paths Handling

X-Bounding Control Signals (Existing or New Scan Cells)

By default, the tool identifies existing scan cells with the correct clock domain and uses the
output from these flip-flops to drive the test mode input of the X-bounding multiplexer.
Details about how the tool selects the clocks are in the “Clock Selection” section.

You also can choose to drive the test mode input of the new multiplexers from new scan cells
using the -connect_to new_scan_cell switch of the set_xbounding_options command. The clock
signal that drives the new scan cell is selected using the same algorithm that applies when using
existing scan cells. The new scan cells are merged into existing chains whenever possible. The
output of the flip-flops directly drives the data input of the new flip-flops.

Clock Selection
The tool analyzes the location of each X-bounding multiplexer to identify the clocks if a new
flip-flop is chosen to drive the multiplexer. The tool looks at clocks for the controlling flip-flops
that feed into this location and also the clocks for the flip-flops that are fed from this signal.
When only a single clock domain is involved, that clock is used to drive the test points.
However, when multiple clock domains are involved, the behavior depends on the definition of
the false or multi-cycle paths. X-bounding could potentially introduce a new false path that
would not be bounded because the false path did not exist in the original netlist. Therefore,
when an SDC file is loaded, the tool uses static bounding (forcing a constant 0 or 1 via an AND
or OR gate) to avoid creating a new false path. When no false or multi-cycle paths are defined,
the tool chooses the clock domain that is most frequently used by the memory elements in the
fanout of the X-source.

34 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Scan Insertion and X-Bounding
Scan Insertion and X-Bounding Overview

Multiple Clock Domain Handling

By default, X-bounding by the tool does not guard cross-clock domain paths. However, if you
reference these paths in the SDC file (for example, set_false_path -from CLK1 -to CLK2), then
the tool adds the appropriate bounding hardware at the destination flop.
For cases when you create at-speed capture procedures that do not explicitly exercise these
paths, none of these paths need to be bounded. The following command and switch:

set_xbounding_options -exclude_cross_clock_domain_paths on

modify the tool’s behavior such that paths that meet the following criteria are not X-bounded:

1. Identifies all the clock domains that feed into the test point location.
2. Identifies all the clock domains that observe the signal from the test point.
3. If there is no overlap between the clocks identified in (1) and (2), then this is considered
a cross clock domain path that cannot be activated by pulsing only a single clock, and it
is excluded from X-bounding.

False and Multi-Cycle Paths Handling

The tool can also insert logic to block false and multi-cycle paths to inhibit these from
contributing Xs during LogicBIST as follows:
• All destination flops are identified from the SDC file you load into the tool using the
read_sdc command.
• The destination flops are replaced with holding flops to prevent capturing Xs—see
“Destination Flop Identification.”
• The holding mux has an inverter in the feedback loop to enable transition coverage for
the downstream logic. In Figure 3-2, lbist_en is the signal to control the muxes.
However, you can use a completely new enable signal to control the select line of these
muxes. This would allow enabling this logic independent of the LogicBIST run.
Figure 3-2 shows the holding muxes in black.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 35

June 2014
Scan Insertion and X-Bounding
Scan Insertion and X-Bounding Overview

Figure 3-2. Inverted Feedback Muxes

Re-circulating muxes with an inverter in the feedback path are inserted on the D input of the
destination scan cells of false and multi-cycle paths. The inversion ensures that the destination
scan cell output has a transition during broadside test to achieve higher coverage.

Destination Flop Identification

Each false/multi-cycle path statement in the SDC file is analyzed in the region identified by that
particular statement. The tool subsequently analyses the ability of signals from the marked
region to propagate to an observation point. These gates on the propagation path are marked as
being in the false or multi-cycle path effect cone.
From this information, the tool looks at the data input(s) of the each scannable flop to determine
if these are marked in any false or multi-cycle path effect cone. These gate inputs are bounded
using a mux and an inverted feedback loop.

In addition, the tool checks the set and reset ports of each flop and disables any set/reset ports
that are also marked as false or multi-cycle paths. In this case, however, a combinational gate
(either an AND gate or an OR gate) is used to force the set/reset port into the off state.

Scan Insertion and X-Bounding Limitations

Scan Insertion and X-Bounding have certain limitations.
Be aware of the following:

• If low power is used in the hybrid TK/LBIST flow, the scan chain length must be equal
to or greater than the decompressor size. The minimum decompressor size in the hybrid
flow is 31. Therefore, the scan chain length cannot be less than 31. The reason for this

36 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Scan Insertion and X-Bounding
Performing Scan Insertion and X-Bounding

requirement is that the size of the low-power register and the size of the decompressor
are the same; to initialize the low-power register, the shift length must be equal to or
greater than the decompressor size. If the tool generates a larger decompressor, say a
size of 62 bits, the required minimum shift length is 62.
• X-bounding analysis does not take into account wrapper cells identified with the
analyze_wrapper_cells command and will insert X-bounding multiplexers at the
primary input pins that feed the wrapper cells. The workaround is to perform wrapper
chain identification and insertion in a separate pass, prior to X-bounding. In addition,
you must constrain the scan enable signal for the input wrapper chains to keep these
chains in “shift mode” during the capture cycles. This pin constraint prevents insertion
of extra X-bounding multiplexers at the primary input pins that drive the wrapper cells
in functional mode.

Performing Scan Insertion and X-Bounding

Use the following procedure to perform scan insertion and X-bounding.

Prerequisites
• Design netlist with test points and dofile outputted by Tessent Shell during the “Test
Point Generation and Insertion.”

Procedure
1. From a shell, invoke Tessent Shell using the following syntax:
% tessent -shell

After invocation, the tool is in unspecified setup mode. You must set the context before
you can use the X-bounding and scan insertion commands.
2. Set the tool context to scan insertion using the set_context command as follows:
SETUP> set_context dft -scan

3. Load the non-scan gate-level Verilog netlist containing the test points using the
read_verilog command.
SETUP> read_verilog my_modified_netlist.v

4. Load one or more cell libraries into the tool using the read_cell_library command.
SETUP> read_cell_library atpg.lib

5. Using the dofile command, load the Tessent Shell tool-produced dofile you generated
during test point analysis and insertion. For example:
SETUP> dofile lbist_scan_setup.dofile

6. If required in your design flow, load the SDC file using the read_sdc command.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 37

June 2014
Scan Insertion and X-Bounding
Performing Scan Insertion and X-Bounding

SETUP> read_sdc my_sdc

The SDC file should describe false and multi-cycle paths that should be blocked during
LogicBIST.
7. Set the scan insertion options using the set_scan_insertion command.
SETUP> set_scan_insertion -ten t_enable

8. Set the X-bounding options with the set_xbounding_options command.

SETUP > set_xbounding_options

9. Change the tool’s system mode to analysis using the set_system_mode command.
SETUP> set_system_mode analysis

During the transition from setup to analysis mode, the tool performs design rule
checking and inserts the scan chains.
10. Perform the X-bounding analysis using the analyze_xbounding command.
ANALYSIS> analyze_xbounding

11. Optionally report the results of the X-bounding analysis using the report_xbounding
command.
ANALYSIS> report_xbounding

12. Perform scan insertion and X-bounding logic insertion using the insert_test_logic
command.
ANALYSIS> insert_test_logic

After insertion, the tool automatically transitions to insertion mode.

13. Write out the modified design using the write_design command. For example:
INSERTION> write_design -output design_with_scan.v

14. Write out the test procedure file and dofile using the write_atpg_setup command as
follows:
INSERTION> write_atpg_setup my_scan_setup

In this example, the tool produces the following two files that are to be used as input for the next
step of the flow:

• my_scan_setup.dofile
• my_scan_setup.testproc
Now you are ready to perform “EDT and LogicBIST IP Generation.”

38 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Scan Insertion and X-Bounding
Example of Scan Insertion and X-Bounding

Example of Scan Insertion and X-Bounding

The following example performs X-bounding analysis and scan chain insertion for a design
with previously inserted test points.
dofile scan_setup.dofile
set_system_mode analysis
set_xbounding_options -xbounding_enable my_enable1
analyze_xbounding
insert_test_logic
report_scan_chains
write_design -output scan1.v
write_atpg_setup pat1_setup.edt

• scan_setup.dofile was generated using the write_scan_setup command during the test
point analysis and insertion step.
• This dofile loads the netlist and the Tessent cell library. It also includes the necessary
commands to set up the circuit for DRC.
• The set_system_mode analysis command triggers design rule checking and transitions
into the analysis system mode.
• The set_xbounding_options command is used to specify the name of the top-level pin
that will enable the X-bounding signals.
• The analyze_xbounding command triggers the analysis and reports a summary of how
many bounding muxes were added.
• Next, the insert_test_logic command modifies the internal representation of the netlist to
include the X-bounding muxes, as well as performing scan cell replacement and
stitching. This command triggers a transition from analysis to insertion mode.
• Finally, the write_design and write_atpg_setup commands are used to write out the
modified netlist, and also to generate a setup file that should be used in subsequent steps.

Scan Insertion and X-Bounding Command

Summary
Tessent Shell enables you to perform scan insertion and X-bounding.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 39

June 2014
Scan Insertion and X-Bounding
Scan Insertion and X-Bounding Command Summary

Table 3-1 lists the Tessent Shell scan insertion and X-bounding commands.

Table 3-1. Scan Insertion and X-Bounding Commands

Command Description
analyze_xbounding Performs X-bounding analysis.
insert_test_logic Inserts the test structures you define into the netlist to increase
the design’s testability.
read_cell_library Loads one or more cell libraries into the tool.
read_sdc Reads in the SDC file that describes the false and multi-cycle
paths that should be blocked during LogicBIST.
read_verilog Reads one or more Verilog files into the specified or default
logical library.
report_sequential_instances Reports information and testability data for the sequential
instances in the design.
report_xbounding Reports the X-sources and the scan cells used in bounding.
set_context Specifies the current usage context of Tessent Shell. You must
set the context before you can enter any other commands in
Tessent Shell.
set_scan_insertion Sets the pin names of the scan control signals.
set_system_mode Specifies the operational state you want the tool to enter.
set_xbounding_options Enables X-bounding and sets X-bounding parameters.
write_atpg_setup Writes a test procedure file and the dofile for the existing scan
chains.
write_design Writes out the modified netlist.
write_scan_setup Writes out a dofile containing all necessary steps for scan
insertion.

40 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 4
EDT and LogicBIST IP Generation

This chapter provides detailed information on the tasks performed during EDT and LogicBIST
IP Generation, and contains the following sections.
EDT and LogicBIST IP Generation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Generating the EDT and LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Timing Constraints for EDT and LogicBIST IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
EDT and LogicBIST IP Generation Command Summary . . . . . . . . . . . . . . . . . . . . . . . 64

Hybrid TK/LBIST Flow User’s Manual, v2014.2 41

June 2014
EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

EDT and LogicBIST IP Generation Overview

The following illustrates EDT and LogicBIST IP generation.

Figure 4-1. EDT and LogicBIST IP Generation

Step 1: Test Point Generation and Insertion

Step 2: Scan Insertion and X-Bounding

BIST-ready dofiles
Netlist

EDT/LBIST
ICL & PDL Step 3: EDT and LogicBIST IP Generation

Netlist with
EDT/LBIST IP dofiles

Step 4: LogicBIST Fault Simulation and

Pattern Creation

Step 5: Pattern Generation

Step 6: Top-Level ICL Network Integration

(only for Bottom-Up Method)

Step 7: ICL Extraction and Pattern Retargeting

(only for Bottom-Up Method)

You use Tessent Shell to generate the shared EDT/LogicBIST RTL. Modular EDT is supported
in this step, where both shared EDT/LogicBIST IP per block and LogicBIST controller are
inserted at the same time.

When using the bottom-up method, there is no TAP controller at the core level. The new core-
level pins corresponding to the SIB control signals and TCK, and LogicBIST scan I/O are
created at this step. The core-level Verilog patterns operate these pins directly. These pins will

42 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

later be connected to the TAP controller at the top level of the design—see “Top-Level ICL
Network Integration.”

As part of IP generation, the following files are written out:

• The ICL file consists of ICL module description for the LogicBIST controller and all
EDT blocks tested by this controller.
• The PDL file contains iProcs at the core level that use the ICL modules written out.
During the IP generation step, the generated ICL file describes only the LogicBIST and EDT
modules. This extracted ICL includes the core-level pin names and connectivity found from the
core-level design netlist. The extracted ICL is used during top-level pattern generation—see
“ICL Extraction and Pattern Retargeting.” Verilog patterns can be written out in this step and
simulated to verify the test operation at the core level.

TAP Controller and LogicBIST

If you plan on using a TAP controller with the LogicBIST controller, then you must configure
your TAP to account for the following mandatory signals:
• tck
• setup_shift_scan_in
• setup_shift_scan_out
• capture_dr
• shift_dr
• update_dr
• test_logic_reset
• tap_instruction_decode
Figure 4-2 shows the TAP controller with these signals highlighted in red.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 43

June 2014
EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

Figure 4-2. TAP Controller

Note the following:

• During this step of the flow, you specify the LogicBIST pins for these TAP signals using
the set_lbist_pins command before you create the hybrid LogicBIST controller.
• You must supply the ICL/PDL for the TAP—see “Pattern Generation.”
• The tool automatically inserts a pipeline stage after the last SIB in the tool-produced ICL
network for the LogicBIST controller to account for designs where the TAP already has
a retiming flop on the TDO output pin. Consequently, you do not need to modify the ICL
to account for the retiming flops at the output.

Clock Controller Connections to the EDT/LogicBIST

IP
The clock controller interfaces only with scan_enable and shift_clock pins. You are responsible
for creating and instantiating your clock controller in the input design. The clock controller
should be pre-configured such that it is already usable for ATPG. The clock controller is
expected to route shift_clock to its clkout pin when scan_enable is1. It is expected to route the
programmable internally-generated capture clock to its clkout pin when scan_enable is 0.
In this flow, the tool controls the scan_enable/shift_clock pins such that during ATPG mode the
existing connections are used, but during LogicBIST mode they are driven by
~lbist_capture_en/lbist_shift_clock respectively.

Figure 4-3 shows the Clock Controller before the EDT/LogicBIST IP has been generated.

44 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

Figure 4-3. Clock Controller Before IP Generation

Figure 4-4 shows the clock controller connections to the BIST controller after EDT/LogicBIST
IP generation.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 45

June 2014
EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

Figure 4-4. Clock Controller After EDT/LogicBIST IP Generation

Alternatively, the clock controller could have scan_enable/shift_clock_en pins (instead of

shift_clock). In this case, the tool muxes them with ~lbist_capture_en/lbist_shift_clock_en. The
clock controller is responsible for using the lbist_shift_clock_en as the clock-gating signal to
internally generate the shift clock signal.

EDT and LogicBIST IP

An EDT block refers to an independent set of scan chains that are driven by a decompressor and
observed by a compactor. The EDT block organization can be different from the block
organization used for physical implementation. In particular, there can be multiple EDT blocks
inside a single physical block.
Figure 4-5 illustrates a high-level block view of the EDT and LogicBIST IP.

46 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

Figure 4-5. Block-Level View of the EDT/LogicBIST IP

The EDT/LogicBIST hybrid IP reduces the area overhead compared to a separate

implementation of EDT and LogicBIST IP. This is done by re-using parts of the IP for both
EDT and LogicBIST modes. This hybrid logic controls input stimuli generation and output
response comparison, and is implemented separately for each EDT block. The top-level
controller including the LogicBIST FSM is then connected to these hybrid IP inserted EDT
blocks.

For detailed description of Hybrid EDT/LogicBIST IP, refer to the following sections:

• “Shared Logic”
• “Inserted LogicBIST IP”
• “Scan Chain Masking”

Hybrid TK/LBIST Flow User’s Manual, v2014.2 47

June 2014
EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

• “New LogicBIST Control Signals”

Figure 4-6 shows the final top-level netlist after IP generation. During IP generation, the tool
inserts muxes at the shift clock and scan enable clock controller pins and drive them from the
LogicBIST controller.

The clock controller’s shift clock input is driven by:

• The LogicBIST shift clock in LogicBIST mode,

• The pre-existing EDT clock connection during EDT mode.
The clock controller’s scan enable input is driven by:

• The inverted lbist_capture_en signal in LogicBIST mode,

• The pre-existing scan enable connection during EDT mode.

Figure 4-6. Final Top-Level Netlist

During EDT mode of operation, all EDT control signals except EDT clock, meaning, update,
bypass, and low power enable are directly connected to the EDT logic without passing through
the LogicBIST controller. The scan cells are shifted using a top-level shift clock. The Shift
Clock controller chooses the EDT clock to be delivered to the EDT blocks.

48 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

During LogicBIST mode of operation, the scan cells are shifted using the shift clock output
from the LogicBIST controller. The shift clock controller chooses a gated version of the
LogicBIST clock to be delivered to the LogicBIST blocks. This gating ensures that the PRPG
and MISR are not pulsed during capture as well as the transition between shift and capture
modes.

The core scan cells receive the capture clock pulses from the clock controller logic. The
LogicBIST clock input to the PRPG and MISR is turned off during capture.

Figure 4-7 shows the clock and EDT control signals in the LogicBIST IP.

Figure 4-7. Clocking During EDT Shift Mode of Operation

Programmable Registers
Programming of the BIST registers is the same for both TAP and non-TAP cases. The BIST
controller and EDT blocks use the same control interface.
When using a TAP, these signals are generated by the TAP controller. When not using a TAP,
these signals are presented as top-level pins which will then be operated similar to the TAP
controller output signals. This is done automatically in the next step of the flow—see “Pattern
Generation” and “Programmable Registers Inside Hybrid IP.”

Hybrid TK/LBIST Flow User’s Manual, v2014.2 49

June 2014
EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

Clock Control Logic and Named Capture

Procedures
The following section describes Named Capture Procedure (NCP) for the following modes:
• EDT Mode
• LogicBIST Mode

EDT Mode
In the EDT context, you must ensure the generation of proper shift and capture clocks. For
example, the clock pin could be a design top-level pin controlled by the tester. When using a
PLL, clock control register values for functional clocks can be shifted in during scan shift. The
number of capture cycles can be controlled on a per pattern basis, either through named capture
procedure or clock_control definition. All existing EDT capabilities for controlling capture
mode clocking can be used in the shared EDT/LogicBIST architecture.

LogicBIST Mode
For LogicBIST mode, the controller generates the shift clock and capture enable signals, which
are connected to the clock control logic. The scan enable output from the LogicBIST controller
is de-asserted during capture.
Note
NCPs are always required for LogicBIST operation. Other clock control techniques like
external clocks and clock_control definition are not compatible with BIST application.

You can describe specific capture clock sequences to be applied using NCPs using the
following commands:

• add_bist_capture_range
• set_clock_controller_pins, specifically, the -capture_procedure_index switch
• set_lbist_controller_options, specifically, the -capture_procedures switch
In general, you associate the percentage of patterns for which each NCP is applied. This should
reflect the number of faults that can be detected with the specified NCP. The number of cycles
in capture should be uniform across all NCPs. You can specify the number of BIST clock cycles
for capture. When not specified, the maximum value possible for the capture counter register in
the hardware is used.

The LogicBIST controller consecutively applies the NCPs for the specified percentage of
patterns, with the cycle repeating after 256 patterns. An additional output that identifies the
index of the currently targeted NCP is available as a counter calculating the total number of

50 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

NCPs. The NCP index is generated by decoding from the least significant bits of the pattern
counter.

Again, you must ensure your design generates the correct clock sequence corresponding to the
NCP based on this index signal bits.

If you define only a single NCP, then the NCP index output is not generated. You should do this
in cases where the clock controller is initialized during test_setup to generate a particular
capture procedure. All patterns in this session will use the same capture procedure.

Programmable Capture Procedures

The registers controlling the NCP bits are programmable, which means that you do not need to
regenerate the IP if you want to change the percentage of patterns applied using a particular
NCP after initial IP generation.
You can adjust the NCP activity level for fault simulation by issuing the
set_lbist_controller_options command with the desired integer percentage values.

Note
If integer percentage values are not specified for IP generation, they must be specified for
fault simulation or an error is issued.

The NCP names and order specified during IP generation are carried forward to fault
simulation. The names specified during fault simulation are validated against those specified in
IP generation. An error is generated if there is a mismatch between the two. If the NCPs
specified during fault simulation are listed in a different order than those added during IP
generation, the order is automatically changed to match the IP generation order. If an NCP
specified during IP generation is not used during fault simulation, the NCP must be specified
with “0” as the percentage.

To illustrate, suppose that four NCPs (clkseq1, clkseq2, clkseq3, and clkseq4) are declared
without a percentage value in the IP generation dofile. When running LogicBIST fault
simulation, you decide that clkseq4 should be active 50% and the other three NCPs should be
equally distributed for the remaining 50% of the time. Your dofile would have the following:

source .../<prefix>_lbist.dofile
...
set_lbist_controller_options -capture_procedures {clkseq 17 clkseq2 17
clkseq3 16 clkseq4 50}

The set_lbist_controller_options command will be internally converted to the following

equivalent add_bist_capture_range commands:

add_bist_capture_range clkseq1 0 42 // 17%

add_bist_capture_range clkseq2 43 85 // 17%
add_bist_capture_range clkseq3 86 127 // 16%

Hybrid TK/LBIST Flow User’s Manual, v2014.2 51

June 2014
EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

add_bist_capture_range clkseq4 128 255 // 50%

These NCP counts are then stored in the Tessent Core Description (TCD) file for pattern
generation.

During pattern generation, the NCP counts stored in the TCD file are loaded into their
respective ICL registers.

Low-Power Shift
During EDT/LogicBIST IP generation, you can configure the low-power scheme to control the
switching activity during “shift” to reduce power consumption.
For a detailed description of the embedded structure inserted for this purpose, see “Low-Power
Shift Controller.”

The following Tessent Shell command sequence demonstrates creating the low-power shift
controller for LogicBIST:

//Commands to configure EDT/LogicBIST blocks

add_edt_block B1
set_edt_options …
set_lbist_controller_options …
set_lbist_power_controller_options shift enabled -min_switching_threshold 10

IJTAG Network in EDT/LogicBist IP

SIBs are a mechanism to provide flexible access to data registers they control. For the Mentor
Graphics version of a SIB, the data registers are accessible via the IJTAG network when the SIB
controlling a data register is set to 1, and the data register is bypassed when the SIB is set to 0.
The SIBs are usually clocked by TCK and use the lbist_tap_instruction signal decoded from the
JTAG LogicBIST instruction as the SIB enable signal. This is how all the SIBs inside the
LogicBIST controller and single chain mode logic are configured.
Each EDT/LogicBIST block contains four SIB registers. They provide access to the PRPG,
EDT chain mask register, MISR, and programmable NCP count registers, respectively. The
EDT SIBs and the data registers they control are both clocked by edt_clock. If the EDT SIBs
were to use TCK, the interaction between two different clocks in the IJTAG shift path would
require the use of lockup cells between these two clock domains. A SIB using TCK inside the
LogicBIST controller controls access to the EDT SIBs using edt_clock. The enable output of
this LogicBIST controller SIB is used as the input enable for the EDT SIBs.

For each specified NCP, an 8-bit register is created and inserted on the ICL network. Figure 4-8
shows where the NCP count register is inserted. These registers are loaded at runtime so that the
number of patterns applied for NCP is programmable. When an integer percentage is provided

52 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Overview

during IP generation, the NCP registers will reset to those values when sib_reset is asserted.
Otherwise, these registers are reset to equal percentages across all NCPs. For more information,
see the “Programmable Capture Procedures” section in the “EDT and LogicBIST IP
Generation” chapter.

Figure 4-8 shows the IJTAG network in a hybrid EDT/LBIST-inserted design.

Figure 4-8. SIBs Insertion and Integration of Cores

EDT and LogicBIST IP Generation Limitations

The following are not currently supported for EDT and LogicBIST IP generation:
• Writing out the EDT and LogicBIST IP in VHDL format. Currently, the RTL
description of the IP can be written out only in Verilog format.
• Defining dual compression configurations for the hybrid IP in EDT mode.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 53

June 2014
EDT and LogicBIST IP Generation
Generating the EDT and LogicBIST IP

Generating the EDT and LogicBIST IP

Use the following procedure with Tessent Shell to generate the hybrid EDT and LogicBIST IP.

Prerequisites
• You need the scan insertion dofile and BIST-ready netlist you created during Scan
Insertion and X-Bounding.

Procedure
1. From a shell, invoke Tessent Shell using the following syntax:
% tessent -shell

After invocation, the tool is in unspecified setup mode. You must set the context before
you use the IP generation commands.
2. Set the tool context to EDT/LogicBIST generation using the set_context command as
follows:
SETUP> set_context dft -edt -logic_bist

3. Load the LogicBIST-ready design netlist using the read_verilog command. For
example:
SETUP> read_verilog my_modified_design.v

4. Load one or more cell libraries into the tool using the read_cell_library command:
SETUP> read_cell_library atpg.lib

5. Set the top design using the set_current_design command. For example:
SETUP> set_current_design top_module

6. Read in the dofile you generated with Tessent Shell that contains the scan insertion and
X-bounding information using the dofile command—see “Scan Insertion and X-
Bounding”. For example:
SETUP> dofile my_setup.dofile

7. Set additional EDT/LogicBIST IP generation options depending on your design

objective using the following commands:
• set_clock_controller_pins
• set_edt_options
• set_lbist_controller_options
• set_lbist_instances
• set_lbist_pins

54 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
Generating the EDT and LogicBIST IP

• set_lbist_power_controller_options
See also “Low-Power Shift.”
8. Change the tool’s system mode to analysis using the set_system_mode command as
follows:
SETUP> set_system_mode analysis

During the transition from setup to analysis mode, the tool performs design rule
checking.
9. You can optionally report the clock controller pins, global LogicBIST controller
configuration parameters, and/or specified pins results using the following commands:
• report_clock_controller_pins
• report_lbist_configuration
• report_lbist_pins
10. Use the write_edt_files command to create the files that implement the EDT logic and
the -timing_constraints switch to write out the timing constraints. For example:
ANALYSIS> write_edt_files my_edt_logic -timing_constraints

The tool also transitions to insertion mode and inserts the EDT/LogicBIST hardware.
See “Timing Constraints for EDT and LogicBIST IP” for additional information.
You use these files as input to LogicBIST Fault Simulation and Pattern Creation.
11. Write out the modified netlist using the write_design command. For example:
INSERTION> write_design -output my_edt_logic_edt_top_rtl.v

Output Files
The following table lists files that are generated in during this step.

Table 4-1. EDT and LogicBIST IP Generation Output Files

File Contents
<prefix>_bypass_shift_sdc.tcl EDT bypass shift mode timing constraints file.
<prefix>_dc_script.scr Synopsys script for synthesizing EDT and BIST logic.
<prefix>_edt_fast_capture_sdc.tcl Capture mode timing constraints file for EDT or EDT-
prefix>_edt_slow_capture_sdc.tcl bypass mode.
<prefix>_edt_shift_sdc.tcl EDT shift mode timing constraints file.
<prefix>_edt_top_rtl.v Gate-level netlist that instantiates the EDT and BIST
logic.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 55

June 2014
EDT and LogicBIST IP Generation
Timing Constraints for EDT and LogicBIST IP

Table 4-1. EDT and LogicBIST IP Generation Output Files

File Contents
<prefix>_lbist.dofile BIST fault simulation dofile.
<prefix>_ltest.icl ICL file describing hybrid EDT/LBIST logic for EDT
and LBIST modes — to be used during EDT pattern
generation and BIST fault simulation.
<prefix>_ltest.pdl PDL file describing test_setup initialization of hybrid
EDT/LBIST logic for EDT pattern generation and BIST
fault simulation.
<prefix>_lbist.testproc BIST fault simulation test procedure — contains shift,
load_unload, and capture procedures.
<prefix>_lbist.v Per-block MISRs and top-level BIST controller.
<prefix>_lbist_sdc.tcl File containing all LogicBIST modes including LBIST
setup, shift, capture, and single chain mode.

Timing Constraints for EDT and LogicBIST IP

Tessent Shell generates timing constraints for the hybrid EDT/LogicBIST IP during IP
generation in SDC format.
The timing constraint files are written out along with the other EDT output files when you issue
the write_edt_files command as follows:

write_edt_files prefix -timing_constraints

The SDC file contains timing constraints and exceptions for all modes of operation of the IP.
SDC is generated for the following modes:

• Operate Hybrid IP in EDT Mode — EDT shift, slow and fast capture. The capture
mode constraints are the same for EDT and EDT-bypass.
• Operate Hybrid IP in EDT-Bypass Mode — Bypass shift, slow and fast capture. The
capture mode constraints are the same for EDT and EDT-bypass.
• Operate Hybrid IP in LogicBIST Mode — LogicBIST setup, shift, capture and
diagnostic modes. The diagnostic mode constraints are generated only when single
chain mode logic is synthesized in the IP.

EDT and EDT-Bypass Timing Constraints

The EDT and EDT-bypass mode timing constraints are the same as for the EDT only (non-
hybrid) IP. The constraints for all the LogicBIST modes are described in different top-level
TCL procs in the SDC file.

56 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
Timing Constraints for EDT and LogicBIST IP

The general structure (shown below for LogicBIST setup) is as follows:

proc create_lbist_clock {} …
proc set_lbist_IO_pin_delays {} …
proc set_lbist_setup_mode_constraints {} …
proc lbist_setup_mode {} { #Top level proc that includes the above sub procs corresponding
for this mode }

This SDC only describes constraints and exceptions related to the IP. This should be used
together with the constraints and exceptions for the core design that is generated during pattern
generation or fault simulation as applicable for the given mode. Sourcing the SDC files only
defines the TCL procs. The user should use a top-level PrimeTime script that reads and links the
design and execute the desired TCL procedure.

Constrains for Different Modes

The constraints for all the different modes are described in this section as follows:
• LogicBIST Setup Mode
• LogicBIST Shift Mode
• LogicBIST Capture Mode
• LogicBIST Single Chain Mode

LogicBIST Setup Mode

This mode is for seeding the BIST registers in the EDT blocks like PRPG, MISR and EDT
chain mask registers as well as those in the LogicBIST IP like vector counter, shift counter etc.
The BIST controller is clocked by tck for this mode of operation.
The TDI and TDO pins of the TAP controller are used for seeding, hence IO delays are defined
for those pins. These delays are defined with respect to virtual clocks named force_pi and
measure_po that reflect the timing described in the test procedures.

The following constraints/exceptions are specified for the LogicBIST Setup mode:

• Set LogicBIST enable TDR bit to 1. Set the BIST setup registers to “001” corresponding
to the LongSetup mode of operation for the BIST controller.
• Set false paths from EDT control signals that are not used like EDT reset and EDT
update.
• Set false paths from EDT channel input pins and to EDT channel output pins.
• Set false paths through TAP controller's LogicBIST instruction enable and test logic
reset outputs. The TAP controller paths for shift, capture and update are enabled.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 57

June 2014
EDT and LogicBIST IP Generation
Timing Constraints for EDT and LogicBIST IP

• EDT chain mask registers are active in this mode. The paths from these registers to the
design scan cells, specifically the hold paths, where the source and destination are on
different clock domains are not explicitly disabled. This works correctly because the
destination design scan cells are not clocked in this mode.
• Set variables for sequentially propagating case analysis constraints through the user
clock controller.
• Disable clock gating checks on the shift controller clock muxes. This is because only the
tck path is selected in this mode.

LogicBIST Shift Mode

This mode describes scan chain shifting. The scan cells are driven by the internally generated
LogicBIST shift clock and the PRPG/MISR are driven by the internally generated LogicBIST
clock. The BIST controller is clocked by the free running shift clock source. IO pins are not
involved in this, hence no IO pin delays are specified.
The following constraints/exceptions are specified for the LogicBIST Shift mode:

• Set LogicBIST enable TDR bit to 1.

• Constrain the internally generated LogicBIST scan enable that reaches the scan cells to
ON. There is a 4 cycle window around the time the scan enable changes during which
the design scan cells are not clocked, which allows the scan enable to be described as a
constant.
• Constrain the internally generated clock controller scan enable to ON.
• Constrain or exclude EDT pins like EDT clock, update, reset and other control signals.
• Disable all paths from the TAP controller.
• EDT chain mask registers are static throughout test, so declare all paths from these
registers as false.
• Disable all paths from SIBs inside the EDT logic. These SIBs are clocked by the faster
lbist shift clock and hence excluded in this mode.
• Set variables for sequentially propagating case analysis constraints through the user
clock controller.
• Disable clock gating checks on the shift controller clock muxes. This is because only the
free running shift clock source is selected in this mode.

LogicBIST Capture Mode

This mode describes the capture. The clocking for the scan cells is described in the Named
Capture Procedures. The BIST controller is clocked by the free running shift clock source. IO
pins are not involved in this mode, hence no IO pin delays are specified.

58 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
Timing Constraints for EDT and LogicBIST IP

The following constraints/exceptions are specified for this mode:

• Set LogicBIST enable TDR bit to 1.

• Constrain the internally generated LogicBIST scan enable that reaches the scan cells to
OFF. There is a 4 cycle window around the time the scan enable changes during which
the design scan cells are not clocked, which allows the scan enable to be described as a
constant.
• Constrain the internally generated clock controller scan enable to OFF.
• Constrain or exclude EDT pins like EDT clock, update, reset and other control signals
• Disable all paths from the TAP controller
• EDT chain mask registers are static throughout test, so declare all paths from these
registers as false.
• Set variables for sequentially propagating case analysis constraints through the user
clock controller
• Disable clock gating checks on the shift controller clock muxes. This is because only the
free running shift clock source is selected in this mode

LogicBIST Single Chain Mode

This mode describes shifting through the concatenation of the design scan cells through the
single chain mode logic, used primarily for LogicBIST diagnostics. The BIST controller and the
design scan cells are clocked by tck for this mode of operation. The TDI and TDO pins of the
TAP controller are used for seeding, hence IO delays are defined for those pins. The delays are
defined with respect to virtual clocks named force_pi and measure_po that reflect the timing
described in the test procedures.
The following constraints/exceptions are specified for the LogicBIST Single Chain mode:

• Set LogicBIST enable TDR bit to 1. Set the BIST setup registers to 100 corresponding
to the SingleChain mode of operation for the BIST controller.
• Constrain or exclude EDT pins like EDT clock, update, reset and other control signals.
• Set false paths from EDT channel input pins and to EDT channel output pins.
• Set false paths through TAP controller's LogicBIST instruction enable and test logic
reset outputs. The TAP controller paths for shift, capture and update are enabled.
• EDT chain mask registers are static throughout test, so declare all paths from these
registers as false.
• Set the single chain mode TDR bit to 1.
• Set variables for sequentially propagating case analysis constraints through the user
clock controller.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 59

June 2014
EDT and LogicBIST IP Generation
Usage Examples

• Disable clock gating checks on the shift controller clock muxes. This is because only the
tck path is selected in this mode.

Usage Examples
The following are examples for usage.

Example 1
This example shows a single EDT/LogicBIST block. The design has X-bounding, control, and
observe points controlled by the same design pin named lbist_en. This design does not use low-
power hybrid IP.
// Set context for generating hybrid EDT/LogicBIST IP
set_context dft -edt -logic_bist
// Read design and DFT library
read_verilog my_core_scan_xbound.v
read_cell_library atpg.lib
set_current_design
// Define clocks and pin constraints
add_clock 0 occ/occNX1/U7/Z -internal -pin_name NX1 // Internally generated capture
//clock
add_clock 0 occ/occNX2/U7/Z -internal -pin_name NX2 // Internally generated capture
//clock
add_clock 0 shift_clock
add_clock 0 refclk -free_running
add_input_constraint shift_clock -c0
add_input_constraint scan_en -c0
// Scan chains and test procedure file from scan insertion
add_scan_groups grp1 scan_setup.testproc
for {set i 1} {$i <= 16} {incr i} {
add_scan_chains chain$i grp1 scan_in$i scan_out$i
}
// Configure EDT logic
set_edt_options -location internal
set_edt_options -channel 2 -reset async
// Configure LogicBIST controller

60 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
Usage Examples

set_edt_options -lbist_misr_input_ratio 4
set_lbist_controller -max_shift 400 -max_capture 3 -max_pattern 10000 \
-capture {clk_once 100}
// Specify LogicBIST pins
set_lbist_pins clock refclk
set_lbist_pins scan_en scan_en
set_lbist_pins xbounding_en lbist_en
set_lbist_pins control_point_en lbist_en
set_lbist_pins observe_point_en lbist_en
// Specify clock controller pins
set_clock_controller_pins shift_clock occ/shift_clock
set_clock_controller_pins scan_en occ/scan_en
set system mode atpg
// Report user settings
report_edt_configuration
report_lbist_configuration
report_lbist_pins
report_clock_controller_pins
// Generate EDT files
write edt files created -replace

Example 2
This is a modular IP generation example. The scan chains are defined at internal pins at the
block boundary. The design has a TAP controller to which the LogicBIST controller is
connected during IP generation. Separate control registers are synthesized in the LogicBIST
controller for independently controlling x-bounding, control and observe points. There are
multiple clock controllers in the design. The design has multiple NCPs that are used in
LogicBIST test in the proportion specified.
// Set context for generating hybrid EDT/LogicBIST IP
set_context dft -edt -logic_bist
// Read BIST-ready block designs and TOP level
read_verilog TOP.v my_core_scan_xbound.v piccpu_scan_xbound.v
read_cell_library atpg.lib
set_current_design TOP
// Define clocks and RAM control signals

Hybrid TK/LBIST Flow User’s Manual, v2014.2 61

June 2014
EDT and LogicBIST IP Generation
Usage Examples

add_scan_groups grp1 TOP_scan_setup.testproc

add_clocks 0 NX1 NX2 clk ramclk
add_read_control 0 ramclk
add_write_control 0 ramclk
add clock 0 XCLK -free_running
add pin constraint scan_en c0
add pin constraint RST c0
// Configure LogicBIST controller
set_lbist_controller_options -max_shift 400 -max_capture 2 -max_pattern 256000
set_lbist_controller_options -capture {pulseC1P 60 pulseC2P 35 pulseR 5}
set_edt_options -location internal
set_lbist_instances -controller_location /dftblk
// Define LogicBIST pins
set_lbist_pins tck tck
set_lbist_pins clock XCLK
set_lbist_pins scan_en scan_en
set_lbist_pins xbounding_en lbist_en
set_lbist_pins mcp_bounding_en mcp_bound_en
set_lbist_pins control_point_en tp_ctrl_en
set_lbist_pins observe_point_en tp_obs_en
// Define TAP pins for connecting to LogicBIST controller
set_lbist_pins setup_shift_scan_in tdi
set_lbist_pins setup_shift_scan_out { tdo jtag/scanCfgReg_so }
set_lbist_pins shift_dr { - jtag/shift_dr }
set_lbist_pins capture_dr { - jtag/capture_dr }
set_lbist_pins update_dr { - jtag/update_dr }
set_lbist_pins test_logic_reset { - jtag/tlr }
set_lbist_pins tap_instruction_decode { - jtag/scanCfgReg_en }
// Define clock controller pins
set_clock_controller_pins lbist_en {cc_clk/lbist_en cc_NX1/lbist_en cc_NX2/lbist_en}
set_clock_controller_pins shift_clock_en {cc_clk/shift_clock_en cc_NX1/shift_clock_en
cc_NX2/shift_clock_en}
set_clock_controller_pins scan_en {cc_clk/scan_en cc_NX1/scan_en cc_NX2/scan_en}
set_clock_controller_pins capture_procedure_index {NCPdecoder/i[1] NCPdecoder/i[0]}

62 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 EDT and LogicBIST IP Generation
Usage Examples

// Define EDT block my_core_A of "my_core" design

add_edt_block my_core_A
set_edt_options -channel 2 -reset async
for {set i 1} {$i <= 16} {incr i} {
add_scan_chain -internal my_core_A_chain$i grp1 my_core_A/scan_in$i
my_core_A/scan_out$i
}
set_edt_power_controller shift enabled -min_switching 15
set_lbist_power_controller shift enabled -min_switching 12
set_edt_instance -block_location /dftblk
// Define EDT block my_core_B of "my_core" design
add_edt_block my_core_B
set_edt_options -channel 2 -reset async
for {set i 1} {$i <= 16} {incr i} {
add_scan_chain -internal my_core_B_chain$i grp1 my_core_B/scan_in$i
my_core_B/scan_out$i
}
set_edt_power_controller shift enabled -min_switching 15
set_lbist_power_controller shift enabled -min_switching 12
set_edt_instance -block_location /dftblk
// Define EDT block piccpu of design "piccpu"
add_edt_block piccpu
set_edt_options -channel 1 -reset async
for {set i 1} {$i <= 8} {incr i} {
add_scan_chain -internal piccpu_chain$i grp1 piccpu/edt_si$i piccpu/edt_so$i
}
set_edt_power_controller shift enabled -min_switching 25
set_lbist_power_controller shift enabled -min_switching 25
set_edt_instance -block_location /dftblk
report_lbist_configuration
report_lbist_pins
report_clock_controller_pins
report_edt_configuration -all_blocks
write_edt_files created -replace -timing_constraints

Hybrid TK/LBIST Flow User’s Manual, v2014.2 63

June 2014
EDT and LogicBIST IP Generation
EDT and LogicBIST IP Generation Command Summary

EDT and LogicBIST IP Generation Command

Summary
The Tessent Shell EDT and LogicBIST IP generation commands are listed in the following
table.

Table 4-2. EDT and LogicBIST IP Generation Commands

Command Description
read_cell_library Loads one or more cell libraries into the tool.
read_verilog Reads one or more Verilog files into the specified or
default logical library.
report_clock_controller_pins Reports the clock controller pins.
report_lbist_configuration Reports the global LogicBIST controller configuration
parameters.
report_lbist_pins Reports the pins specified using the set_lbist_pins
command.
set_clock_controller_pins Specifies the connection information for the clock
controller pins.
set_context Specifies the current usage context of Tessent Shell.
You must set the context before you can enter any
other commands in Tessent Shell.
set_current_design Specifies the top level of the design for all subsequent
commands until reset by another execution of this
command.
set_edt_options Sets options for EDT IP creation.
set_lbist_controller_options Specifies global options to configure the LogicBIST
controller.
set_lbist_instances Specifies the instance in which the LogicBIST
controller or single chain mode logic is placed.
set_lbist_pins Specifies the connection information for LogicBIST
controller pins.
set_lbist_power_controller_options Specifies creating the low-power shift controller for
LogicBIST.
set_system_mode Specifies the operational state you want the tool to
enter.
write_design Writes out the modified netlist.
write_edt_files Creates the files that implement EDT logic.

64 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 5
LogicBIST Fault Simulation and Pattern
Creation

This chapter provides detailed information on the tasks performed during LogicBIST Fault
Simulation and Pattern Creation.
LogicBIST Fault Simulation and Pattern Creation Overview . . . . . . . . . . . . . . . . . . . . 66
Low-Power Shift Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Fault Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Performing LogicBIST Fault Simulation and Pattern Creation. . . . . . . . . . . . . . . . . . . 68
Example of Core-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Fault Simulation and Pattern Creation Command Summary . . . . . . . . . . . . . . . . . . . . 70

Hybrid TK/LBIST Flow User’s Manual, v2014.2 65

June 2014
LogicBIST Fault Simulation and Pattern Creation
LogicBIST Fault Simulation and Pattern Creation Overview

LogicBIST Fault Simulation and Pattern

Creation Overview
The following figure illustrates fault simulation and pattern creation in this flow.

Figure 5-1. LogicBIST Fault Simulation and Pattern Creation

Step 1: Test Point Generation and Insertion

Step 2: Scan Insertion and X-Bounding

Step 3: EDT and LogicBIST IP Generation

Created
NCPs and dofiles
manually Test Setup

Step 4: LogicBIST Fault Simulation and

Pattern Creation

patDB and Verilog Testbench

Graybox
TCD Files Parallel Patterns
Core Level Signature, Coverage

Step 5: Pattern Generation

Step 6: Top-Level ICL Network Integration

(only for Bottom-Up Method)

Step 7: ICL Extraction and Pattern Retargeting

(only for Bottom-Up Method)

You perform fault simulation and save LogicBIST parallel patterns.

66 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 LogicBIST Fault Simulation and Pattern Creation
LogicBIST Fault Simulation and Pattern Creation Overview

Low-Power Shift Simulation

If you specified a low-power controller during EDT and LogicBIST IP Generation, then the
generated fault simulation dofile carries forward details of the generated hardware through the
following commands:
// Created_lbist.dofile: LogicBIST fault simulation dofile written out
// during IP creation
set_current_edt_block B1
set_lbist_power_controller_options shift enabled -min_switching_threshold 10

Specify the amount of switching activity desired during fault simulation:

dofile created_lbist.dofile // Was generated during IP creation

set_power_control -switching_threshold 15
set_system_mode analysis
…
run

Fault Simulation
During fault simulation with Tessent Shell, the tool generates the dofile for pattern re-targeting,
as well as PatternDB and TCD files.
Tessent Shell performs fault simulation at the core level, generates the signatures, and computes
test coverage. The tool also writes out a parallel test bench.

The core level fault simulation run computes the test coverage for the core, MISR signature, and
power consumption. Two files are generated as the output of this step:

• PatternDB — Contains the relevant LogicBIST register values per pattern like PRPG,
MISR, and low-power registers.
• Tessent Core Description (TCD) — Contains the description of the core in the
LogicBIST mode of operation.

Disabling and Enabling Control and Observe Points

During fault simulation, you can optionally disable/enable the control signals for the control
points and the observe points using the set_dft_enable_options command.
For more information, see the set_dft_enable_options command.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 67

June 2014
LogicBIST Fault Simulation and Pattern Creation
Performing LogicBIST Fault Simulation and Pattern Creation

Performing LogicBIST Fault Simulation and

Pattern Creation
Use this Tessent Shell procedure to perform fault simulation.

Prerequisites
• Use the following files that you have generated during EDT and LogicBIST IP
Generation using the write_edt_files command and during Logic Synthesis:
o my_edt_logic_edt_top_gate.v
o my_edt_logic_lbist.dofile
o my_design_edt_top_gate.v

Procedure
Use this Tessent Shell procedure to perform fault simulation:

1. From a shell, invoke Tessent Shell using the following syntax:

% tessent -shell

After invocation, the tool is in unspecified setup mode. You must set the context before
you use the fault simulation commands.
2. Set the tool context to fault simulation using the set_context command as follows:
SETUP> set_context patterns -scan

3. Load the prefix_lbist.v design netlist using the read_verilog command. For example:
SETUP> read_verilog my_edt_logic_edt_top_gate.v

4. Load one or more cell libraries into the tool using the read_cell_library command.
SETUP> read_cell_library atpg.lib

5. Set the top design using the set_current_design command as follows:

SETUP> set_current_design top_module

6. Read in the my_edt_lbist.dofile using the dofile command as follows:

SETUP> dofile my_edt_logic_lbist.dofile

7. Specify the capture procedure names with the set_lbist_controller_options command as

follows; be sure to include all of the NCPs that will be used in the LBIST mode:
SETUP> set_lbist_controller_options \
-capture_procedures {clkseq1 clkseq2 clkseq3 clkseq4}

68 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 LogicBIST Fault Simulation and Pattern Creation
Example of Core-Level Simulation

8. Change the tool’s system mode to fault using the set_system_mode command as
follows:
SETUP> set_system_mode analysis

During the transition from setup to analysis mode, the tool performs design rule
checking.
9. Add faults using the add_faults command as follows:
ANALYSIS> add_faults -all

10. Specify the number of random patterns the tool will simulate using the
set_random_patterns command as follows:
ANALYSIS> set_random_patterns 100

11. Set the pattern source to LogicBIST and execute fault simulation using the
simulate_patterns command as follows:
ANALYSIS> simulate_patterns -source bist -store_patterns all

12. Save the TCD files containing information about your core needed for the next step
Pattern Generation and ICL Extraction and Pattern Retargeting using the
write_core_description command as follows:
ANALYSIS> write_core_description core_name.tcd -replace

13. Save the PatternDB files containing information about your core needed for the next
step Pattern Generation and ICL Extraction and Pattern Retargeting using the
write_patterns command as follows:
ANALYSIS> write_patterns core_name.patdb -patdb -replace

14. Write out the parallel testbench using the write_patterns command as follows:
ANALYSIS> write_patterns lbist_patt_parallel.v -verilog -parallel \
-mode_internal -param ../data/paramfile

Now you are ready to perform Pattern Generation.

Example of Core-Level Simulation

This dofile shows an example core-level fault simulation for core alu that uses the
write_core_description and write_patterns commands to write out TCD and PatternDB files that
will be used in Pattern Generation and ICL Extraction and Pattern Retargeting.
For more information, see “Pattern Generation” and “ICL Extraction and Pattern Retargeting.”

set_context patterns -scan

set_pattern -scan

Hybrid TK/LBIST Flow User’s Manual, v2014.2 69

June 2014
LogicBIST Fault Simulation and Pattern Creation
Fault Simulation and Pattern Creation Command Summary

read_verilog alu_edt_top_gate.v
read_cell_library atpg.lib
set_current_design
dofile alu_lbist.dofile
set_lbist_controller_options -capture_procedures {clkseq1 clkseq2 clkseq3 clkseq4}
set_system_mode analysis
add_faults -all
set_random_patterns 100
simulate_patterns -source bist
write_core_description alu.tcd -replace
write_patterns alu.patdb -patdb -replace

Fault Simulation and Pattern Creation

Command Summary
The following table lists the fault simulation and pattern creation commands.

Table 5-1. Fault Simulation and Pattern Creation Commands

Command Description
add_bist_capture_range Associates the capture procedure that is used for a specific
set of patterns.
add_chain_masks Specifies the scan chains that are masked during fault
simulation and their load and unload values. Used to work
around design issues.
add_faults Adds faults to the current fault list, discards all patterns in
the current test pattern set, and sets all faults to undetected
(actual category is UC).
read_cell_library Loads one or more cell libraries into the tool.
read_sdc Reads in the SDC file that describes the false and multi-
cycle paths.
read_verilog Reads one or more Verilog files into the specified or
default logical library.
report_misr_connections Reports the MISR connections.
set_bist_debug Sets up a trace of PRPG and MISR values during a
pattern's shift cycles.

70 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 LogicBIST Fault Simulation and Pattern Creation
Fault Simulation and Pattern Creation Command Summary

Table 5-1. Fault Simulation and Pattern Creation Commands

Command Description
set_context Specifies the current usage context of Tessent Shell. You
must set the context before you can enter any other
commands in Tessent Shell.
set_current_design Specifies the top level of the design for all subsequent
commands until reset by another execution of this
command.
set_dft_enable_options Enables and/or disables the control or observe points.
set_edt_options Sets options for EDT IP creation and LogicBIST fault
simulation.
set_lbist_controller_options Specifies global options to configure the LogicBIST
controller.
set_lbist_power_controller_options Specifies creation of the low-power shift controller for
LogicBIST.
set_power_control Specifies the switching threshold in the patterns for fault
simulation.
set_random_patterns Specifies the number of random patterns the tool
simulates.
set_system_mode Specifies the operational state you want the tool to enter.
simulate_patterns Performs simulation by applying the specified pattern
source.
write_core_description Writes the description of the core for the LogicBIST mode
of operation. This includes description of the core pins,
scan chain information, and EDT/LogicBIST hardware
registers (essentially, all information to capture the core-
level LogicBIST mode operation).
write_patterns Writes out parallel patterns and PatternDB files.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 71

June 2014
LogicBIST Fault Simulation and Pattern Creation
Fault Simulation and Pattern Creation Command Summary

72 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 6
Pattern Generation

This chapter provides detailed information on the tasks performed during Pattern Generation.
Pattern Generation Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Required Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Retargeting Dofile Template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Performing Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Example of Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Pattern Generation Command Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Hybrid TK/LBIST Flow User’s Manual, v2014.2 73

June 2014
Pattern Generation
Pattern Generation Overview

Pattern Generation Overview

The following figure illustrates pattern generation.

Figure 6-1. Pattern Generation

Step 1: Test Point Generation and Insertion

Step 2: Scan Insertion and X-Bounding

EDT/LBIST Netlist with

IDL & PDL
Step 3: EDT and LogicBIST IP Generation EDT/LBIST IP

Step 4: LogicBIST Fault Simulation and

Pattern Creation

patDB and Verilog Testbench

TCD Files Parallel Patterns
Core Level Signature, Coverage

Step 5: Pattern Generation

Serial Patterns, WGL,

Verilog, STIL, ...

Step 6: Top-Level ICL Network Integration

(only for Bottom-Up Method)

Step 7: ICL Extraction and Pattern Retargeting

(only for Bottom-Up Method)

You generate the following:

• For the Bottom-Up Flow, core-level patterns.

• For the Top-Down Flow, top-level patterns (including a Verilog testbench) for the
LogicBIST controller. These are the chip-level serial patterns that can be applied from
the tester.
The tool supports all the formats currently supported for ATPG.

74 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Pattern Generation
Pattern Generation Overview

Required Input
To program the LogicBIST controller, you use Tessent Shell to retarget the patterns and create
hardware default mode testbench/vectors and pattern_range specific vectors.
This information is contained in the ICL and PDL files created during EDT and LogicBIST IP
Generation:

• ICL — The ICL file consists of ICL module description for the LogicBIST controller
and all EDT blocks tested by this controller.
• PDL — The PDL file contains iProcs at the core level that use the ICL modules written
out.

Retargeting Dofile Template

For IJTAG pattern generation, the following template pattern retargeting dofile can be used.
The arguments shown below in italics are examples, which you should replace for the given
design.
#
#Set context to ijtag pattern retargeting
set_context pattern -ijtag

#
#Read library and design
read_cell_library atpg.lib
read_verilog created_edt_top_gate.v ;#Synthesized gate level netlist with hybrid
EDT/LBIST IP

#
#Read fault simulation data
read_config_data lbist.tcd ;#Fault simulation configuration data written out
during fault simulation

#
#Read ICL files
read_icl created_ltest.icl ;#ICL description of hybrid IP written out during IP
creation

Hybrid TK/LBIST Flow User’s Manual, v2014.2 75

June 2014
Pattern Generation
Pattern Generation Overview

#Set top level module for ijtag retargeting

set_current_design top ;#Top level design name

#
#Define top-level clocks
add_clocks refclk -free_running ;#Free running clock input to PLL
add_clocks 0 tck

#
#Define pin constraints
add_input_constraints RST -c0
add_input_constraints edt_reset -c0

#
#Change to analysis mode to generate patterns
set_system_mode analysis
write_icl -o my_design.icl -replace ;#Write top-level ICL after ICL extraction

#
#Read pattern data from fault simulation
open_patdb lbist.patdb ;#Pattern data written out during fault simulation
report_open_patdb

#
#Read PDL files
source created_ltest.pdl ;#PDL for operating the hybrid IP written out during
IP creation

#
#Write regular LBIST patterns
open_pattern_set lbist_normal
iCall edt_lbist_user_iproc ;#Optional, for additional user provided initialization
iCall run_lbist_normal lbist_clock 0 31 lbist
close_pattern_set

76 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Pattern Generation
Performing Pattern Generation

write_patterns lbist_normal_pat.v -pattern_set lbist_normal -verilog -replace

#
#Write hardware default LBIST patterns
open_pattern_set lbist_hw_default
iCall edt_lbist_user_iproc ;#Optional, for additional user provided initialization
iCall run_lbist_hw_default lbist
close_pattern_set
write_patterns lbist_hw_default_pat.v -pattern_set lbist_hw_default -verilog -replace

#
#Write diagnostic LBIST patterns
open_pattern_set lbist_diag
iCall edt_lbist_user_iproc ;#Optional, for additional user provided initialization
iCall scan_unload_register lbist_clock 0 1 lbist
close_pattern_set
write_patterns lbist_diag_pat.v -pattern_set lbist_diag -verilog -replace

This dofile is a template with Tcl-style comments that you must modify with the information
specific to your design before using the dofile in Tessent Shell.

Performing Pattern Generation

Use this procedure to generate the chip-level serial patterns that can be applied from the tester.

Prerequisites
The required inputs for this step of the flow that you specify in the pattern retargeting dofile are
as follows:

• Modified design netlist.

• PDL data file, my_edt_logic_ltest.pdl, produced by the write_edt_files command.
• ICL data file, my_edt_logic_ltest.icl, produced by the write_edt_files command.
• Top-level ICL describing how the signals at the interface of the LogicBIST controller
are connected to chip-level pins.
• A PDL that describes the test setup at the chip level if there is any. For example, if there
is a TAP controller at the top level, then the tool requires an ICL and, optionally, PDL
for the TAP controller.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 77

June 2014
Pattern Generation
Example of Pattern Generation

Procedure
1. From a shell, invoke Tessent Shell using the following syntax:
% tessent -shell

After invocation, the tool is in unspecified setup mode. You must set the context before
you can invoke the pattern retargeting commands.
2. Set the tool context to IJTAG mode using the set_context command as follows:
SETUP> set_context dft patterns -ijtag

3. Execute the modified pattern retargeting dofile. For example:

SETUP> dofile ./test_retarget.dofile

Upon completion, Tessent Shell outputs the testbench/vectors for the entire pattern set,
range specific vectors, or Hardware default mode as specified in the dofile.

Results
• If you are using the Top-Down Flow, you finished all necessary steps in this flow.
• If you are using the Bottom-Up Flow, you are ready to perform the Top-Level ICL
Network Integration.

Example of Pattern Generation

In this example, the core-level ICL IJTAG dofile uses the TCD and PatternDB files to generate
a Verilog testbench for core-level pattern verification.
set_pattern -ijtag
read_verilog alu_edt_top_gate.v
read_cell_library atpg.lib
read_icl alu_ltest.icl
set_current_design
set_system_mode analysis
source alu_ltest.pdl
write_icl -o alu.icl -replace // save the extracted ICL, will be used at the top level
open_pattern_set alu_core_patt
iCall run_lbist_normal
close_pattern_set
write_patterns alu_core_patt.v -verilog -replace -serial

78 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Pattern Generation
Pattern Generation Command Summary

Pattern Generation Command Summary

The following table lists the Tessent Shell pattern generation commands.

Table 6-1. Pattern Generation Commands

Command Description
iCall Calls an iProc registered against the ICL module assiciated with
the specified effective_icl_instance_path.
read_cell_library Loads one or more cell libraries into the tool.
read_icl Reads ICL files into the internal database.
read_verilog Reads one or more Verilog files into the specified or default
logical library.
set_context Specifies the current usage context of Tessent Shell. You must
set the context before you can enter any other commands in
Tessent Shell.
set_current_design Specifies the top level of the design for all subsequent
commands until reset by another execution of this command.
write_icl Creates the files that implement the EDT logic.
write_patterns Writes out PatternDB files.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 79

June 2014
Pattern Generation
Pattern Generation Command Summary

80 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 7
Top-Level ICL Network Integration

This chapter provides detailed information on the tasks performed Top-Level ICL Network
Integration.
Note
You perform this step only when using the Bottom-Up Flow.

Chapter topics follow this sequence:

Top-Level ICL Network Integration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Performing Top-Level ICL Network Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Example of Top-Level ICL Network Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Top-Level ICL Network Integration Command Summary. . . . . . . . . . . . . . . . . . . . . . . 87

Hybrid TK/LBIST Flow User’s Manual, v2014.2 81

June 2014
Top-Level ICL Network Integration
Top-Level ICL Network Integration Overview

Top-Level ICL Network Integration Overview

The following figure illustrates this step within hybrid TK/LBIST flow.

Figure 7-1. Top-Level SIB Netlist Insertion

Step 1: Test Point Generation and Insertion

Step 2: Scan Insertion and X-Bounding

Step 3: EDT and LogicBIST IP Generation

Step 4: LogicBIST Fault Simulation and

Pattern Generation

Step 5: Pattern Generation

Top-Level
Core 1 ... Core N Interconnect
Netlist Netlist between Cores

Step 6: Top-Level ICL Network Integration

(only for Bottom-Up Method)

Top-Level
Netlist

Step 7: ICL Extraction and Pattern Generationg

(only for Bottom-Up Method)

You use the top-level netlist that instantiates all the LogicBIST implemented cores. You insert
IJTAG compliant SIBs to provide access to each of the LogicBIST cores as well as connect
these SIBs and cores to the top-level TAP controller. It is recommended to shadow each core by
a separate SIB to provide maximum flexibility for test scheduling. You can connect EDT
control signals from the core to the top level as well at this time. You also can create a
DftSpecification and use the Tessent Shell process_dft_specification functionality to automate
this task.

82 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Top-Level ICL Network Integration
Performing Top-Level ICL Network Integration

Performing Top-Level ICL Network Integration

Use this procedure to integrate top-level ICL network.

Prerequisites
The following input is required for this step of the flow:

• The netlists for all your cores created in EDT and LogicBIST IP Generation.
• Top-level netlist with instantiation of cores and interconnect between them.

Procedure
1. From a shell, invoke Tessent Shell using the following syntax:
% tessent -shell

After invocation, the tool is in unspecified setup mode. You must set the context before
you can invoke the top-level SIB network Insertion commands.
2. Set the tool context to dft mode using the set_context command as follows:
SETUP> set_context dft -no_rtl

3. Load the LogicBIST-ready design netlists using the read_verilog command. For
example:
SETUP> read_verilog top.v <core_name_1>_edt_top_gate.v \
<core_name_N>_edt_top_gate.v

4. Load the ICL description for all of the cores. The core-level ICL files were generated as
part of core-level pattern generation. Alternatively, core-level ICL can be generated
using ICL extraction from a core-level EDT/LBIST ICL description. For example:
SETUP> read_icl {core_name_1_ltest.icl core_name_N_ltest.icl}

5. Load one or more cell libraries into the tool using the read_cell_library command. For
example:
SETUP> read_cell_library atpg.lib

6. Set the top design using the set_current_design command. For example:
SETUP> set_current_design top

7. Implement an optional TCL proc named “process_dft_specification.post_insertion” that

will be executed after processing the DftSpecification and before writing out the top-
level IJTAG network-inserted design. This proc can be used to connect the EDT signals
from the cores to top-level design pins. For example:

Hybrid TK/LBIST Flow User’s Manual, v2014.2 83

June 2014
Top-Level ICL Network Integration
Example of Top-Level ICL Network Integration

SETUP> proc process_dft_specification.post_insertion {root wrapper} {

create_port edt_clock
create_connection edt_clock [get_pins *_edt_i/edt_clock]
…
}

8. Load the top-level IJTAG network description in DftSpecification format. For example:
SETUP> read_config_data top.dft_spec

9. Validate and implement the IJTAG network using the process_dft_specification

command. This command generates the RTL description for the IJTAG network
components and the top-level IJTAG network-inserted design.
SETUP> process_dft_specification

Now you are ready to perform ICL Extraction and Pattern Retargeting.

Example of Top-Level ICL Network Integration

The example in the following figure describes a design that has two cores, alu and cpu. The alu
core has two EDT blocks named B1 and B2. Two instances of the alu core are in the final top-
level design (/w2/A and /w2/B) and a single instance of the cpu core (/c1).
The example shows the Tessent Shell integration dofile for generating the IJTAG network and
connecting the core-level EDT signals to the top level. The
process_dft_specification.post_insertion TCL procedure connects the core-level EDT pins to
the top level of the design. The example demonstrates the creation of shared top-level pins for
all of the cores corresponding to the EDT control signals, such as edt_clock, edt_update, and
edt_bypass. The example also shows the creation of dedicated top-level pins for channel inputs
and outputs for each of the cores.

Figure 7-2. Top-Level ICL Network Integration Dofile Example

set_context dft -no_rtl

read_verilog top.v alu_edt_top_gate.v cpu_edt_top_gate.v
read_cell_library atpg.lib
read_icl {alu.icl cpu.icl}
set_current_design top

//TCL proc to connect EDT signals from block to top pins

proc process_dft_specification.post_insertion {root args} {
foreach i {alu1_edt_channels_in1 alu1_edt_channels_in2
alu2_edt_channels_in1 alu2_edt_channels_in2
cpu_edt_channels_in1

84 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Top-Level ICL Network Integration
Example of Top-Level ICL Network Integration

edt_clock edt_reset edt_update edt_bypass

edt_single_bypass_chain} {
create_port -direction input $i
}
foreach o {alu1_edt_channels_out1 alu1_edt_channels_out2
alu2_edt_channels_out1 alu2_edt_channels_out2
cpu_edt_channels_out1} {
create_port -direction output $o
}
create_connection alu1_edt_channels_in1 w2/A/B1_edt_channels_in1
create_connection alu1_edt_channels_in2 w2/A/B2_edt_channels_in1
create_connection alu2_edt_channels_in1 w2/B/B1_edt_channels_in1
create_connection alu2_edt_channels_in2 w2/B/B2_edt_channels_in1
create_connection cpu_edt_channels_in1 c1/edt_channels_in1
create_connection alu1_edt_channels_out1 w2/A/B1_edt_channels_out1
create_connection alu1_edt_channels_out2 w2/A/B2_edt_channels_out1
create_connection alu2_edt_channels_out1 w2/B/B1_edt_channels_out1
create_connection alu2_edt_channels_out2 w2/B/B2_edt_channels_out1
create_connection cpu_edt_channels_out1 c1/edt_channels_out1
foreach i {edt_clock edt_reset edt_update edt_bypass
edt_single_bypass_chain} {
create_connection $i w2/A/$i
create_connection $i w2/B/$i
create_connection $i c1/$i
}
}

//Insert IJTAG network using DFT specification

read_config_data top.dft_spec
process_dft_specification

Figure 7-3 shows the DftSpecification that is referenced in the dofile in Figure 7-2. The
HostScanInterface/Interface wrapper specifies the top-level TAP controller design pins for the
IJTAG interface signals. Three SIBs are to be inserted, each of which controls a core whose

Hybrid TK/LBIST Flow User’s Manual, v2014.2 85

June 2014
Top-Level ICL Network Integration
Example of Top-Level ICL Network Integration

instance path name is specified in the DesignInstance wrapper. The SIBs are inserted one level
above the core instance as specified in the parent_instance property for SIBs w2_A and w2_B.
The SIB for core cpu (/c1) is inserted at the top level. The naming of the SIB instances is
controlled using the leaf_instance_name property. The enable, control signal, and scan IO pin
names (the IJTAG network interface at the core boundary) are taken from the ICL description of
the cores in the alu.icl and cpu.icl files.

Figure 7-3. DftSpecification Example

DftSpecification(top, 3sibs_tap) {
IjtagNetwork {
HostScanInterface(3sibs_tap) {
Interface {
reset_polarity: active_high;
tck: tck;
reset: jtag/tlr;
select: jtag/lbist_inst;
capture_en: jtag/capture_dr;
shift_en: jtag/shift_dr;
update_en: jtag/update_dr;
scan_in: tdi;
scan_out: jtag/lbist_reg_out;
}
Sib(c1) {
leaf_instance_name: piccpu_access_sib;
DesignInstance(/c1) {}
}
Sib(w2_B) {
parent_instance: /w2;
leaf_instance_name: m8051_B_access_sib;
DesignInstance(/w2/B) {}
}
Sib(w2_A) {
parent_instance: /w2;
leaf_instance_name: m8051_A_access_sib;
DesignInstance(/w2/A) {}
}
}
}
}

The RTL and ICL description of the generated IJTAG instruments is written out in the
tessent_outdir/instruments/top_3sibs_tap_ijtag.instrument directory. The top-level IJTAG
network inserted design is written out as
tessent_outdir/dft_inserted_designs/top_3sibs_tap.dft_inserted_design/top.vg. The final top-
level netlist can be obtained by combining the top.vg file along with the gate-level synthesized
netlists of the IJTAG instruments. The ICL files generated in the Figure 7-3 example can be
used for downstream steps that use IJTAG, such as top-level LBIST pattern retargeting.

Note
For more information about ICL insertion using the DftSpecification, refer to the “ICL
Network Insertion” chapter of the Tessent IJTAG User’s Manual.

86 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Top-Level ICL Network Integration
Top-Level ICL Network Integration Command Summary

Top-Level ICL Network Integration Command

Summary
The following table lists the Tessent Shell commands used for the top-level SIB network
insertion.

Table 7-1. Top-Level ICL Network Integration Commands

Command Description
create_connections Connects, ports, pins, port objects.
create_instance Instantiates an instance of a module mod_spec inside a design
module of a current design.
create_port Creates a port on a specified design module.
process_dft_specification Validates and processes the content contained in a
DftSpecification wrapper.
read_cell_library Loads one or more cell libraries into the tool.
read_config_data Loads a configuration data file into the Tessent Shell
environment.
read_verilog Reads one or more Verilog files into the specified or default
logical library.
set_context Specifies the current usage context of Tessent Shell. You must
set the context before you can enter any other commands in
Tessent Shell.
set_current_design Specifies the top level of the design for all subsequent command
until reset of another execution of this command.
write_design Writes the current design to the specified file in Verilog netlist
format.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 87

June 2014
Top-Level ICL Network Integration
Top-Level ICL Network Integration Command Summary

88 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 8
ICL Extraction and Pattern Retargeting

This chapter provides detailed information on the tasks performed during ICL Extraction and
Pattern Retargeting.
Note
You perform this step only when using the Bottom-Up Flow.

ICL Extraction and Pattern Retargeting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Performing ICL Extraction and Pattern Retargeting . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
ICL Extraction and Pattern Retargeting Command Summary . . . . . . . . . . . . . . . . . . . 94

Hybrid TK/LBIST Flow User’s Manual, v2014.2 89

June 2014
ICL Extraction and Pattern Retargeting
ICL Extraction and Pattern Retargeting Overview

ICL Extraction and Pattern Retargeting

Overview
The following figure illustrates the ICL extraction and pattern retargeting step.

Figure 8-1. ICL Extraction and Pattern Retargeting

Step 1: Test Point Generation and Insertion

Step 2: Scan Insertion and X-Bounding

Step 3: EDT and LogicBIST IP Generation

Step 4: LogicBIST Fault Simulation and

Pattern Generation

Step 5: Pattern Generation

Step 6: Top-Level ICL Network Integration

(only for Bottom-Up Method)

Core 1
TCD, patDB Top-Level
Netlist Top-Level
Core 1 ICL/PDL
ICL/PDL
(TAP, SIBs)
.
. Step 7: ICL Extraction and Pattern Retargeting
(only for Bottom-Up Method)
. Pattern
Core N Retargeting
TCD, patDB dofile
Core N
ICL/PDL

In this step of the flow, you use the fully integrated top-level netlist, top-level ICL/PDL files for
your IJTAG instruments, such as the TAP controller and clock controller and the per-core
LogicBIST files generated at the core level. ICL extraction can again be used here instead of
manually creating the top-level ICL describing the SIB access network and connectivity

90 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 ICL Extraction and Pattern Retargeting
Performing ICL Extraction and Pattern Retargeting

between your instruments and the LogicBIST cores. The final tester patterns can be written out
in any of the supported formats.

You must provide the pattern retarget dofile which includes all LogicBIST cores and the desired
scheduling.

Performing ICL Extraction and Pattern

Retargeting
Use this procedure to extract ICL and retarget patterns.

Prerequisites
The required inputs for this step of the flow are as follows:

• PDL and ICL files for each core in your design created during EDT and LogicBIST IP
Generation.
• PatternDB and TCD files for each core in your design generated during Pattern
Generation.
• Top-level PDL and ICL files that include information about the TAP and SIBs.
• Pattern Retargeting dofile. Refer to Example 1.

Procedure
1. From a shell, invoke Tessent Shell using the following syntax:
% tessent -shell

After invocation, the tool is in unspecified setup mode. You must set the context before
you can invoke the pattern retargeting commands.
2. Set the tool context to IJTAG mode using the set_context command as follows:
SETUP> set_context patterns -ijtag

3. Execute the pattern retargeting dofile that reads all the ICL and PDL files and specifies
test scheduling. For example:
SETUP> dofile ./test_retarget.dofile

4. Write a current pattern set to a file in a specified format using the write_patterns
command as follows:
SETUP> write_patterns my_patterns -verilog -parallel -mode_internal -replace

Hybrid TK/LBIST Flow User’s Manual, v2014.2 91

June 2014
ICL Extraction and Pattern Retargeting
Example 1

Example 1
This example merges all the core patterns to be run in parallel.
// Set context for pattern retargeting
set_context patterns -ijtag
// Read output design from top-level ICL network integration step
read_verilog top_lbist_integrated.v
read_cell_library atpg.lib
// Read TCD for the cores
read_config_data piccpu.tcd
read_config_data my_core.tcd
// Read ICL for cores extracted during block level LogicBIST pattern generation
read_icl {alu.icl cpu.icl}
// Read user provided ICL for top-level components
read_icl {top_sib.icl jtag_controller.icl}
// Set current design and report ICL matched modules
set_current_design top
report_module_matching -icl
// Read core level PDL generated during IP creation
source cpu_ltest.pdl
source alu_ltest.pdl
// Define top-level clocks and pin constraints
add_clocks 0 refclk -free_running
add_clocks 0 tck
add_input_constraints RST -c0
add_input_constraints edt_reset -c0
// Change to analysis mode and perform ICL extraction
set_system_mode analysis
write_icl -o top_extracted.icl -replace
// Open pattern-DB for cores
open_patdb my_core.patdb
open_patdb piccpu.patdb
// Report user settings
report_clocks

92 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 ICL Extraction and Pattern Retargeting
Example 2

report_input_constraints
report_open_patdb
// Merge all core patterns to be run in parallel
open_pattern_set top_lbist_patt
iMerge -begin
iCall cpu.run_lbist_normal lbist_clock 0 99
iCall alu1.run_lbist_normal lbist_clock 0 99
iCall alu2.run_lbist_normal lbist_clock 0 99
iMerge -end
close_pattern_set
// Save patterns in verilog simulation and tester formats
write_patterns top_lbist_patt.v -verilog -pattern_set top_lbist_patt -replace
write_patterns top_lbist_patt.stil -stil -pattern_set top_lbist_patt -replace

Example 2
This example shows the pattern merging commands required for running 100 patterns of all
cores sequentially. The initial setup is the same as the previous full example.
open_pattern_set sequential
iCall cpu.run_lbist_normal lbist_clock 0 99
iCall alu1.run_lbist_normal lbist_clock 0 99
iCall alu2.run_lbist_normal lbist_clock 0 99
close_pattern_set
write_patterns cseq_patt.v -pattern_set sequential -verilog -replace

Example 3
This example shows the pattern merging commands required for running 100 patterns of cpu in
parallel with 50 patterns of both alu cores in series.
iProcsForModule top
iProc alu_wrap2_sequential {} {
iTake alu2
iCall alu1.run_lbist_normal lbist_clock 0 49
iRelease alu2
iCall alu2.run_lbist_normal lbist_clock 0 49

Hybrid TK/LBIST Flow User’s Manual, v2014.2 93

June 2014
ICL Extraction and Pattern Retargeting
ICL Extraction and Pattern Retargeting Command Summary

}
open_pattern_set complex
iMerge -begin
iCall cpu.run_lbist_normal lbist_clock 0 99
iCall alu_wrap2_sequential
iMerge -end
close_pattern_set
write_patterns complex_patt.v -pattern_set complex -verilog -replace

ICL Extraction and Pattern Retargeting

Command Summary
The following table lists the Tessent Shell commands for ICL extraction and pattern retargeting.

Table 8-1. ICL Extraction and Pattern Retargeting Commands

Command Description
iCall Calls an iProc registered against the ICL module associated
with the specified effective_icl_instance_path.
iMerge Retargets the included PDL commands to be executed in
parallel.
read_cell_library Loads one or more cell libraries into the tool.
read_icl Loads one or more ICL files into the tool.
read_verilog Reads one or more Verilog files into the specified or default
logical library.
set_context Specifies the current usage context of Tessent Shell. You must
set the context before you can enter any other commands in
Tessent Shell.
write_patterns Writes a current pattern set to a file in a specified format.

94 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Chapter 9
Hybrid TK/LBIST Embedded Structures

This chapter discusses the embedded structures in the hybrid TK/LBIST flow.
EDT/LogicBIST IP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Hybrid EDT/LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Shared Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Inserted LogicBIST IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Scan Chain Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
New LogicBIST Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Programmable Registers Inside Hybrid IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Low-Power Shift Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

EDT/LogicBIST IP Overview
The hybrid TK/LBIST flow utilizes the following during generating and embedding the
EDT/LogicBIST IP into your design.
• EDT and LogicBIST blocks (blocks and ELT cores)
• A decompressor
• Low-Power Shift controller
• LogicBIST controller
• EDT controller
• EDT compactor
• MISR
• Bypass logic

Hybrid EDT/LogicBIST IP
The EDT/LogicBIST hybrid IP reduces the area overhead compared to a separate
implementation of EDT and LogicBIST IP. This is done by re-using parts of the IP for both
EDT and LogicBIST modes. This hybrid logic controls input stimuli generation and output
response comparison, and is implemented separately for each EDT block. The top-level
controller including the LogicBIST FSM is then connected to these hybrid IP inserted EDT
blocks.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 95

June 2014
Hybrid TK/LBIST Embedded Structures
Hybrid EDT/LogicBIST IP

Shared Logic
The EDT/LogicBIST hybrid IP is shared as follows:
• The EDT decompressor is re-configured as the PRPG by blocking the channel inputs
during LogicBIST mode.
• Lockup cells (those placed in between the decompressor and the phase shifter) are re-
used as hold cells when low-power LogicBIST is implemented.
• Biasing gates used when synthesizing EDT low-power hardware is shared with chain
masking.
• The phase shifter network is used as is for driving scan chains from the PRPG.
• The spatial compactor XOR network is re-used for compacting scan chain outputs into
MISR inputs.
• Lockup cells required between the EDT/LogicBIST IP and the design scan cells are
shared between both modes.

Inserted LogicBIST IP
The following LogicBIST IP is inserted during the IP generation step:
• The MISR is instantiated inside the EDT logic.
• All the LogicBIST seeding registers are concatenated into scan chains.
• Segment Insertion Bit (SIB) bits are inserted to control independent access to the
following:
o Chain masking register.
o MISR.
o PRPG with optional low-power LogicBIST control registers.

Scan Chain Masking

The scan chain masking is on a per-chain basis. This per-chain scan masking is controlled by
loading the chain masking register and is applicable for all patterns in the test set. Masking is
available for both scan chain inputs and output. This is in addition to the per-patterns output
masking performed by the EDT logic (either 1-or-all or Xpress compactors).
Per-pattern output masking performed by EDT logic is only for EDT mode and not for
LogicBIST mode.

96 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Hybrid TK/LBIST Embedded Structures
Hybrid EDT/LogicBIST IP

New LogicBIST Control Signals

The new LogicBIST mode control signals are added to the EDT IP when using the hybrid
hardware.
The lbist_en control signal determines whether the hybrid EDT operates in EDT mode
(lbist_en=0) or LogicBIST mode (lbist_en=1). There are several other LogicBIST control
signals like lbist_reset, lbist_prpg_en, and lbist_misr_en added to the Hybrid IP, which are
driven by the common LogicBIST controller. These control signals have no impact during EDT
mode of operation, and they are driven appropriately during LogicBIST mode by the
LogicBIST controller.

Clocking
The following figure presents a timing diagram for EDT/LogicBIST IP.

Figure 9-1. Timing Diagram for LogicBIST

The input clock to the LogicBIST controller is a free-running clock, which could be a fast PLL
output clock. To allow for the control signals to change between shift and capture, 8 empty
(pause) cycles are introduced in between transitions, which helps with timing closure of the test
logic.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 97

June 2014
Hybrid TK/LBIST Embedded Structures
Hybrid EDT/LogicBIST IP

• SE is a scan enable signal that goes to all the scan flops in the design. It transitions half-
way through the pause states.
• shift_clock_en is a gating signal that could be gated with the free-running input clock to
generate the shift-clock for the scan cells. This gating logic can either be implemented
by the tool (when using set_clock_controller_pins shift_clock), or you can generate it as
part of your clocking logic (when using set_clock_controller_pins shift_clock_en).
• The capture enable signal indicates the start of the capture cycle. This is intended as a
trigger for the logic that generates programmable capture sequences. This signal is
connected to the scan enable pin of your clock controller.
• The capture clock signal is shown here for illustration purposes only; this signal is
generated inside your clock controller.
• The BIST clock signal is supplied to all hybrid EDT/LogicBIST blocks as well as used
internally by the BIST controller. This clock is pulsed during shift and OFF during
capture. It also has a pulse during capture pause state to operate the low-power BIST
logic in the hybrid IP as well as to reset certain registers for each pattern in the BIST
controller.
You specify the clock controller signals using the set_clock_controller_pins command.

As stated previously, the LogicBIST clock is typically a free-running clock, but the EDT clock
should be controllable during test as it is pulsed during load_unload but held at off-state during
capture. When the test clock is a top-level clock, it can be shared for both EDT and LogicBIST
modes. When an internal clock, such as a free-running output of a PLL, is to be used for
LogicBIST, then separate clock sources are required for EDT and LogicBIST modes, where the
EDT mode clock is still controllable during test. An example of such a configuration is when
shifting during LogicBIST is to be done at a higher speed than during EDT mode. TCK is used
for seeding of specific values in the LogicBIST registers.

When internally generated functional clocks are used in the design, a top-level shift clock is
required for shifting in EDT mode. Typically, a clock controller is used to generate the exact
sequence of capture clocks and also to switch between shift-mode and capture-mode clocks.
The clock controller takes a free-running clock, shift clock, and scan enable as inputs.

Programmable Registers Inside Hybrid IP

The following registers inside the per-block hybrid IP are programmable:
• PRPG
• Low-power control registers (toggle, hold, switching, and mask shift)
• Chain mask register
• MISR
The following registers inside the top-level BIST controller are programmable:

98 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Hybrid TK/LBIST Embedded Structures
Hybrid EDT/LogicBIST IP

• Capture phase size

• Shift clock select
• Scan length counter (byte counter)
• Pattern counter (vector counter)
• BIST enable signal registers

Low-Power Shift Controller

The following figure shows the overall architecture of the low-power shift controller. The low-
power scheme to control the switching activity during “shift” to reduce power consumption.
The existing LFSM lockup cells are replaced by a hold register (denoted by Hi) which load
select signal is controlled by the low-power control logic. By controlling when these hold
registers update versus when they hold previous cycle values, the overall switching at the scan
chain inputs can be controlled.

Figure 9-2. Low-Power Controller

The performance of the Low-Power BIST controller depends on the following factors:

• The switching code (SC)

• The Hold value (HV)
• The Toggle value (TV)

Hybrid TK/LBIST Flow User’s Manual, v2014.2 99

June 2014
Hybrid TK/LBIST Embedded Structures
Hybrid EDT/LogicBIST IP

The SC, HV, and TV values are automatically calculated by the tool based on the switching
threshold you set using the set_power_control command during fault simulation.

The 4-bit switching code might assume one of 15 different binary values ranging from 0001 up
to 1111. The last value can be alternatively used to disable the control register and enter the
poorly pseudo-random test pattern generation (unless you activate the Hold mode). All codes
are used to enable certain combinations of AND gates forming biasing logic, and, hence, to
produce 1s with probabilities 0.5 (0001), 0.25 (0010), 0.125 (0100), 0.0625 (1000), plus their
combinations obtained due to an additional OR gate. The resultant 0s and 1s are shifted into the
mask shift register, and, subsequently, they are reloaded to the mask hold register at the
beginning of a test pattern to enable/disable the hold latches placed between the ring generator
and its phase shifter.

The duration of how long the entire generator remains in the Hold mode with all latches
temporarily disabled regardless of the hold register content.

In the Toggle mode (its duration is determined by TV), the latches enabled through the control
register can pass test data moving from the ring generator to the scan chains. In order to switch
between these two modes, a weighted pseudo-random signal is produced by a module Encoder
H/T based on the content of different stages of the ring generator.

100 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Appendix A
Interface Pins

This appendix discusses the interface pins in the hybrid TK/LBIST flow.
Interface Pin Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
LogicBIST Controller Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Clock Controller Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
EDT/LogicBIST Wrapper Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Segment Insertion Bit Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Interface Pin Names

The section contains a series of tables that contain the interface pin names for the following
hardware.
• LogicBIST Controller Pins
• Clock Controller Pins
• EDT/LogicBIST Wrapper Pins
• Segment Insertion Bit Signals

LogicBIST Controller Pins

The following table lists the pin names on the LogicBIST controller.

Table A-1. LogicBIST Controller Pins

Pin Name Type Description
capture_dr: sib_capture_en Input capture_dr output pin from the TAP
controller.
clock: shift_clock_src Input LogicBIST clock pins.
control_point_en: control_point_en Output Control point enable pins.
x_bounding_en: x_bounding_en Output X-bounding enable pins.
mcp_bounding_en: mcp_bounding_en Output MCP bounding enable pins.
observe_point_en: observe_point_en Output Observe point enable pins.
scan_en: scan_en_in Input Scan enable pin and, optionally, the
internal pin corresponding to the pad
input.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 101

June 2014
Interface Pins
Interface Pin Names

Table A-1. LogicBIST Controller Pins

Pin Name Type Description
scan_en: scan_en_out Output Scan enable pin and, optionally, the
internal pin corresponding to the pad
output.
setup_shift_scan_in: lbist_scan_in Input Seeding register input connection pin.
setup_shift_scan_out: lbist_scan_out Output Seeding register output connection pin.
shift_dr: sib_shift_en Input shift_dr output from the TAP
controller.
tap_instruction_decode: sib_en Input Instruction decoder output connection.
tck: tck Input JTAG TCK input.
test_en: test_en_in Input Test enable pins.
test_en: test_en_out Output Test enable pins.
test_logic_reset: sib_reset Input test_logic_reset output connection from
the TAP controller.
update_dr: sib_update_en Input update_dr output from the TAP
controller.

Clock Controller Pins

The following table lists the pin names on the clock controller for connecting to your clock
controller in the design.

Table A-2. Clock Controller Pins

Pin Name Type Description
capture_procedure_index: ncp Output NCP signal that identifies the NCP used
for the current pattern.
capture_phase Output Indicates Capture BIST controller FSM
is in capture state.
lbist_en: lbist_en Output LogicBIST enable pins.
scan_en: shift_phase Output Indicates BIST controller FSM is in
shift state.
shift_clock_en: shift_clock_en Output Clock controller shift clock enable pins.
shift_clock: clk_ctrl_shift_clk_in Input Clock controller shift clock pins.
shift_clock: clk_ctrl_shift_clk_out Output Clock controller shift clock pins.
clk_ctrl_scan_en_in Input Clock controller scan enable pins.

102 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Interface Pins
Interface Pin Names

Table A-2. Clock Controller Pins

Pin Name Type Description
clk_ctrl_scan_en_out Output Clock controller scan enable pins.

EDT/LogicBIST Wrapper Pins

The following table lists the pin names for the EDT/LogicBIST wrapper.

Table A-3. EDT/LogicBIST Wrapper Pins

Pin Name Type Description
edt_clock Input Clock for shared EDT/BIST IP.
lbist_en Input Active high enable signal that indicates
BIST mode of operation.
lbist_misr_en Input Active high enable signal that allows
MISR to compress input.
lbist_prpg_en Input Active high enable signal that allows
decompressor to run as PRPG.
lbist_reset Input Synchronous reset signal from the
LogicBIST controller.
lbist_scan_in Input Shift register input for LogicBIST
register seeding.
lbist_scan_out Output Shift register output for LogicBIST
register seeding.

Segment Insertion Bit Signals

The following table lists the 1687-style signals for controlling the SIBs inside the shared
EDT/LogicBIST IP.

Table A-4. SIB Pins

Pin Name Type Description
sib_capture_en Input Active high signal that indicates
TAP is in capture-DR state.
sib_en Input Active high enable SIB enable
signal, connected to decoded
LogicBIST instruction from TAP
controller.
sib_reset Input Active high signal that indicates
TAP is in test logic reset state.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 103

June 2014
Interface Pins
Interface Pin Names

Table A-4. SIB Pins

Pin Name Type Description
sib_shift_en Input Active high signal that indicates
TAP is in shift-DR state.
sib_update_en Input Active high signal that indicates
TAP is in update-DR state.
tck Input 1149.1 test clock input.

104 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Appendix B
File Examples

This appendix provides various examples for the hybrid Tk/LBIST flow.
Synthesis Script Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Timing Script Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
ICL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
PDL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Synthesis Script Example

The following example excerpt shows the tool-produced script for synthesizing the
EDT/LogicBIST logic.
#************************************************************************
# Synopsys Design Compiler synthesis script for created_edt.v
# Tessent TestKompress version: 2013.1-snapshot_2013.01.29_06.01
# Date: Tue Jan 29 11:21:40 2013
#************************************************************************

# Bus naming style for Verilog

set bus_naming_style {%s[%d]}
set hdlin_ff_always_async_set_reset true

# Read input design files

read_file -f verilog created_edt.v
read_file -f verilog created_lbist.v

# Synthesize EDT IP
current_design my_core_edt

# Check design for inconsistencies

check_design

# Timing specification
create_clock -period 10 -waveform {0 5} edt_clock

# Avoid clock buffering during synthesis. However, remember

# to perform clock tree synthesis later for edt_clock
set_clock_transition 0.0 edt_clock
set_dont_touch_network edt_clock

# Avoid reset signal buffering during synthesis. However, remember

# to perform reset tree synthesis later for edt_reset
set_drive 0 edt_reset

Hybrid TK/LBIST Flow User’s Manual, v2014.2 105

June 2014
File Examples
Timing Script Example

set_max_fanout 1000 edt_reset

# Avoid assign statements in the synthesized netlist.

set_fix_multiple_port_nets -feedthroughs -outputs -buffer_constants

# Compile design
uniquify
compile -map_effort medium

# Report design results for EDT IP

report_area > created_dc_script_report.out
report_constraint -all_violators -verbose >> created_dc_script_report.out
report_timing -path full -delay max >> created_dc_script_report.out
report_reference >> created_dc_script_report.out

write -f verilog -hierarchy -o created_my_core_edt_gate.v

# Synthesize single chain mode logic

current_design my_core_single_chain_mode_logic
...

Timing Script Example

The following example excerpt shows a tool-produced timing script.
#************************************************************************
# Timing constraints for EDT/LBIST logic in module my_core during LBIST
# mode
# Tessent TestKompress version: 2013.1-snapshot_2013.01.29_06.01
# Date: Tue Jan 29 11:21:41 2013
#************************************************************************

# The following variables can be set to customize this script before

# sourcing this file:
# lbist_clock_latency_min [default=0]
# lbist_clock_latency_max [default=0]
# lbist_clock_uncertainty_setup [default=0]
# lbist_clock_uncertainty_hold [default=0]
#
# tck_clock_latency_min [default=0]
# tck_clock_latency_max [default=0]
# tck_clock_uncertainty_setup [default=0]
# tck_clock_uncertainty_hold [default=0]
#
# lbist_pins_input_delay [default=0]
# lbist_pins_output_delay [default=0]
#
# reg_suffix [default=_reg]
#
# reg_output [default=Q]
#

# Create lbist clock

proc create_lbist_clock {} {
create_clock -period 40 -waveform {20 30} refclk

106 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 File Examples
ICL Example

global lbist_clock_latency_min lbist_clock_latency_max

lbist_clock_uncertainty_setup lbist_clock_uncertainty_hold
set cmin [expr {[info exists lbist_clock_latency_min] ?
$lbist_clock_latency_min : 0}]
set cmax [expr {[info exists lbist_clock_latency_max] ?
$lbist_clock_latency_max : 0}]
set csetup [expr {[info exists lbist_clock_uncertainty_setup] ?
$lbist_clock_uncertainty_setup : 0}]
set chold [expr {[info exists lbist_clock_uncertainty_hold] ?
$lbist_clock_uncertainty_hold : 0}]

set all_lbist_clocks [list refclk]

set_clock_latency -min $cmin $all_lbist_clocks
set_clock_latency -max $cmax $all_lbist_clocks
set_clock_uncertainty -setup $csetup $all_lbist_clocks
set_clock_uncertainty -hold $chold $all_lbist_clocks
}
...

ICL Example
The following example shows an ICL output written by the tool.
//***********************************************************************
// ICL script for module my_core
//
// Tessent TestKompress version: 2013.1-snapshot_2013.01.29_06.01
// Tue Jan 29 06:11:31 GMT 2013
// Date: 01/29/13 11:21:40
//***********************************************************************

Module my_core_lbist { // {{{

TCKPort tck;
ClockPort edt_clock;
ClockPort shift_clock_src;
ToClockPort lbist_clock { Source shiftClkSelected_MUX;}
ScanInPort from_edt_scan_out;
ScanInPort lbist_scan_in;
ScanOutPort lbist_scan_out { Source lbist_scan_out_ff; }
DataOutPort lbist_en { Source bist_en; }
ResetPort sib_reset;
SelectPort sib_en;
CaptureEnPort sib_capture_en;
ShiftEnPort sib_shift_en;
UpdateEnPort sib_update_en;
ToSelectPort edt_sib_en { Source
my_core_lbist_edt_sib_i.to_enable; }

ScanInterface host {
Port lbist_scan_in;
Port lbist_scan_out;
}
ScanInterface client {
Port from_edt_scan_out;
Port lbist_scan_out;

Hybrid TK/LBIST Flow User’s Manual, v2014.2 107

June 2014
File Examples
PDL Example

Port edt_sib_en;
}

Alias lbist_ctrl_sib = my_core_lbist_sib_bist_registers_i.sib;

Alias lbist_ctrl_signals_sib = my_core_lbist_sib_control_registers_i.sib;
Alias bist_done = bist_en { RefEnum YesNo;}

Instance my_core_lbist_edt_sib_i Of my_core_lbist_sib {

InputPort reset = sib_reset;
InputPort enable = sib_en;
InputPort scan_in = lbist_scan_in;
InputPort capture_en = sib_capture_en;
InputPort shift_en = sib_shift_en;
InputPort update_en = sib_update_en;
InputPort tck = tck;
InputPort from_scan_out = from_edt_scan_out;
}

//
// Bist registers
//
ScanRegister capture_phase_size[1:0] {
ScanInSource my_core_lbist_edt_sib_i.scan_out;
}
ScanRegister shift_clock_select[1:0] {
ScanInSource capture_phase_size[0];
ResetValue 2'b01;
}
...

PDL Example
The following example shows an PDL output written by the tool.
#************************************************************************
# PDL script for LogicBIST IP module my_core
#
# Tessent TestKompress version: 2013.1-snapshot_2013.01.29_06.01
# Tue Jan 29 06:11:31 GMT 2013
# Date: 01/29/13 11:21:40
#************************************************************************

iProcsForModule my_core

# [start] : run_lbist_normal {{{

iProc run_lbist_normal { {clock_select lbist_clock} {begin_pattern 0}
{end_pattern 31} {mode_name unwrapped} } {
if { [string tolower $clock_select] == "tck" } {
set shift_clock_select 0b10 ; # TCK
} elseif { [string tolower $clock_select] == "lbist_clock" } {
set shift_clock_select 0b01 ; # shift_clock_src
} elseif { [string tolower $clock_select] == "edt_clock" } {
set shift_clock_select 0b11 ; # edt_clock
} else {
return -code error "ERROR: Unrecognized value ($clock_select) for
clock_select. Allowed values are TCK, lbist_clock and edt_clock."

108 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 File Examples
PDL Example

array set lbist_data [get_logic_bist_pattern_data -design_name my_core

-mode_name $mode_name -begin_pattern $begin_pattern -end_pattern
$end_patte
rn]

# Define some TCL variables for the values we want to load on the setup
chain
set chain_mask(my_core)
$lbist_data(edt_decompressor_chain_mask,init_value)
set chain_mask_load_en(my_core)
$lbist_data(edt_decompressor_chain_mask,load_en)
set prpg_seed(my_core) $lbist_data(edt_decompressor,seed)
set misr_seed(my_core_misr) $lbist_data(misr,seed)
set misr_sig(my_core_misr) $lbist_data(misr,expected)

set capture_phase_size $lbist_data(capture_width_counter,init_value)

set byte_cnt_max $lbist_data(shift_byte_counter_reg,init_value)
set pattern_length [expr ($byte_cnt_max+1)*8]
set pattern_cnt [expr $end_pattern - $begin_pattern + 1 + 1] ;
# +1->for pattern range +1-> for the flush pattern

# When calculating the # of run cycles a capture_phase_size of 0 still

results in a transition through the CAPTURE state but capture_en does not
toggle
set capture_phase_size_eq [scan [regsub {^0x} $capture_phase_size {}]
%x]
if { $capture_phase_size == 0 } {
set capture_phase_size_eq 1
}

# shift Init
shiftAndCapturePause capturePhase lastPattern
# / \ / \ /
\ / \ / \
set run_cycles [ expr ($pattern_length * $pattern_cnt) + 5 + 8 + 3 + (8
* 2 * $pattern_cnt) + ($capture_phase_size_eq * $pattern_cnt) + 8 + 3 ]

set capture_phase_size [format %X $capture_phase_size]

set pattern_cnt_hex [format %X $pattern_cnt]

set capture_phase_size "0x$capture_phase_size"

set pattern_cnt_hex "0x$pattern_cnt_hex"

#########
# Setup #
#########

iNote "Setting up controller my_core_lbist";

iNote " Number of patterns : [expr $pattern_cnt - 1]";
iNote " Pattern Length : $pattern_length";
iNote " Shift Clk Select : $shift_clock_select";
...

Hybrid TK/LBIST Flow User’s Manual, v2014.2 109

June 2014
File Examples
PDL Example

110 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Appendix C
ECO Implementation in the Hybrid TK/LBIST
Flow

When implementing an ECO in the hybrid TK/LBIST flow, certain considerations should be
taken into account.
Consider the following:

• As part of the IP creation step, the tool makes sure that every scan chain starts with a
leading edge (LE) flip-flop and ends with a trailing edge (TE) flip-flop. The retiming
flip-flops are exposed as part of the scan chains. You must make sure that the clocking
of the boundary flip-flops never changes; if you need to add a flip-flop into the design,
you must add it in the middle of the chain, not at the beginning or end.
The same is true for deleting a flip-flop. Only remove a scan cell that is in the middle of
a chain. Do not remove a scan cell that is at the boundary because it controls the
retiming latches that have been added.
• During IP creation, the tool generates a shift counter that is used during LogicBIST
mode. By default, the tool adds seven more clock cycles to the number of shift cycles.
This allows additional flip-flops to be added later through an ECO. Note that this is
across all scan chains, so many flip-flops can be added in ECO mode if you wish.
However, you should not exceed seven per chain.
• You should specify the size of the pattern counter. Although not directly related to the
ECO process, you should specify the hardware in such a way that you can double the
number of LogicTest patterns that you think will be necessary during IP generation.
• Handle timing violations after placement and routing as follows:

Note
Make sure you declare only the paths giving timing violations that are discovered late. Do
not provide the entire SDC or the tool will insert muxes for FP/MCPs that are already
bounded.

a. Use the “set_xbounding_options -xbounding_enable <pin_name>” command to

declare the existing enable pin that the tool should use to drive the X-bounding mux.
b. Use the “set_system_mode analysis” command.
c. Use the “add_nonscan_instances -all” command to remove any non-scan cells from
consideration that the tool sees as scannable. At this point, the netlist is completely
scanned, so any non-scan cells should remain as is.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 111

June 2014
ECO Implementation in the Hybrid TK/LBIST Flow

d. Use the analyze_xbounding command to determine where the muxes should be

inserted. While this command analyzes whether any X-sources have been missed,
none should have been at this stage.
e. Use the report_xbounding command to show where the muxes will be inserted to
block those paths.
f. Either insert the muxes yourself as part of the ECO or use the insert_test_logic
command to let the tool insert them.

112 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Appendix D
Test Coverage Reporting During Test Point
Analysis

This appendix provides information about test coverage during test point analysis.
Test point analysis uses a fault population of all possible collapsed stuck-at faults. The test
coverage is calculated by assessing, for each fault, the probability that the fault will be detected
by a set of random patterns as specified by the -pattern_count_target option of the
set_test_point_analysis_options command.

Test Coverage Terminology

This section describes the common terms associated with test coverage.
• Total Number of Faults — The sum total of all possible stuck-at faults.
• Testable Faults — Faults that can be detected by externally applied patterns.
• Logic BIST Testable Faults — Testable Faults that can be detected by Logic BIST
patterns. Testable Faults that are not “Logic Bist Testable” are either faults that are
“Blocked by xbounding” or Uncontrollable/Unobservable faults.
• Estimated Test Coverage — The (estimated) coverage of the “Testable Faults.”
• Estimated Maximum Test Coverage — The upper limit of the test coverage that might
be achieved if enough test points were inserted.
• Estimated Relevant Test Coverage — The (estimated) coverage of the “Logic Bist
Testable” faults.

Incremental Relevant Test Coverage Report

The Incremental Relevant Test Coverage Report shows the progress that the tool makes while
selecting test points. This report is updated after every 50 test points. The report shows the total
number of test points that have been selected (TPs), and the breakdown in number of control
points (CP) and observe points (OP), as well as the relevant test coverage for that number of test
points (TC).

Hybrid TK/LBIST Flow User’s Manual, v2014.2 113

June 2014
Test Coverage Reporting During Test Point Analysis
False Paths and Test Coverage

False Paths and Test Coverage

A false path is considered an X-source and is bound when it reaches a scan flop. Therefore, false
paths can increase the number of faults reported as “Blocked by xbounding.”
The tool does not insert a test point on a false path. This may or may not impact the coverage
after test point analysis. The tool tries to find other locations for test points that may not be at
the most optimal locations. This would result in a smaller increase in the test coverage, and the
tool may insert more test points, if necessary, to reach the requested target coverage.

Fault Classes and Fault Analysis

Test point analysis does not perform fault analysis in the same way as is done for ATPG. Test
point analysis does not classify individual faults or use fault classes. Rather, test point analysis
calculates the probability that each fault is detected by a set of random patterns, and from these
probabilities, calculates a test coverage estimate.

“Blocked by xbounding” Faults

An X-source will be bound by an X-bounding mux. The faults on gates that are blocked by the
X-bounding mux, as well as the faults at the “blocked” input of the X-bounding mux cannot be
detected by Logic BIST patterns and are reported as “Blocked by xbounding.”

Uncontrollable/Unobservable Faults
Logic gates that are constant due to constraints do not toggle during Logic BIST. Therefore,
many faults on these gates cannot be detected because the gate cannot be controlled to the
opposite value. These constant gates may also block fault propagation. Faults that cannot be
observed because they are blocked by gates that are constant are reported as
“Uncontrollable/Unobservable.”

Example Test Report

The following is a snippet of a log file showing the test coverage reporting before and after
selecting test points.
// Test Coverage Report before Test Point Analysis
// -----------------------------------------------
// Target number of random patterns 50000
//
// Total Number of Faults 15681
// Testable Faults 15167 ( 96.72%)
// Logic Bist Testable 14994 ( 95.62%)
// Blocked by xbounding 80 ( 0.51%)
// Uncontrollable/Unobservable 93 ( 0.59%)
//

114 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Coverage Reporting During Test Point Analysis
Example Test Report

// Estimated Maximum Test Coverage 98.86%

// Estimated Test Coverage (pre test points) 95.00%
// Estimated Relevant Test Coverage (pre test points) 95.42%
//
//
// Incremental Relevant Test Coverage Report
// -----------------------------------------
// TPs 50 = 21 (CP) + 29 (OP), TC 98.93
// TPs 100 = 42 (CP) + 58 (OP), TC 98.94
// TPs 150 = 62 (CP) + 88 (OP), TC 98.94
// TPs 200 = 73 (CP) + 127 (OP), TC 98.95
// TPs 250 = 81 (CP) + 169 (OP), TC 98.96
// TPs 300 = 81 (CP) + 219 (OP), TC 98.96
// TPs 350 = 86 (CP) + 264 (OP), TC 98.97
// TPs 400 = 89 (CP) + 311 (OP), TC 98.98
// TPs 450 = 95 (CP) + 355 (OP), TC 98.99
// TPs 500 = 104 (CP) + 396 (OP), TC 98.99
//
// Test point analysis completed: target estimated test coverage has been
achieved.
// Inserted Test Points 541
// Control Points 104
// Observe Points 437
//
//
// Test Coverage Report after Test Point Analysis
// ----------------------------------------------
// Target number of random patterns 50000
//
// Total Number of Faults 16678
// Testable Faults 16164 ( 96.92%)
// Logic Bist Testable 15991 ( 95.88%)
// Blocked by xbounding 80 ( 0.48%)
// Uncontrollable/Unobservable 93 ( 0.56%)
//
// Estimated Test Coverage (post test points) 98.08%
// Estimated Relevant Test Coverage (post test points) 99.00%
Note
The number of “Testable Faults” and the number of “Logic Bist Testable” faults is larger
after test point insertion as these numbers include the (testable) faults at the new test point
logic.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 115

June 2014
Test Coverage Reporting During Test Point Analysis
Example Test Report

116 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Appendix E
PrimeTime Script for Preventing Test Points
on Critical Paths

The script “tessent_write_no_tpi_paths.tcl” is a tcl script that reads a list of critical paths
extracted by PrimeTime and marks them as not valid test point locations.
One way to minimize problems during timing closure is to identify critical paths prior to test
point analysis and insertion. This approach depends on accurately identifying the critical paths,
and this typically requires placement and global routing information. The provided PrimeTime
script can be used to extract a list of critical paths based on the current PrimeTime environment
(preferably with placement information) and generate Tessent Shell commands that mark these
paths with the appropriate attributes to avoid inserting test points on them.

Using the PrimeTime Script

Description
The “tessent_write_no_tpi_paths.tcl” script translates a list of critical paths extracted by
PrimeTime into a list of set_attribute_value commands that mark all the pins on the critical
paths with the appropriate attributes.
You would typically do this before Step 1: Test Point Generation and Insertion of the Hybrid
TK/LBIST Flow.

Usage
tessent_write_no_tpi_paths $paths filename
Arguments
• $paths
Environmental variable that points to the critical paths extracted by PrimeTime.
• filename
Specifies the file name for the Tessent Shell dofile generated by the script.
Location
The script is located at
<Tessent_Tree_Path>/share/TestPoints/tessent_write_no_tpi_paths.tcl
Example
Below is an example of how to use this script.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 117

June 2014
PrimeTime Script for Preventing Test Points on Critical Paths
Using the PrimeTime Script

Step 1: From PrimeTime:

set paths [get_timing_path -delay_type max -max_paths 10 -nworst 1 \
-slack_lesser_than 4]
tessent_write_no_tpi_paths $paths critical_paths.dofile

First, use the PrimeTime “get_timing_path” command to extract the critical paths. This
command requires a number of important parameters described below which should be tuned
for your design.
Next, invoke the “tessent_write_no_tpi_paths” script to read in the critical paths extracted by
PrimeTime and write out a Tessent Shell dofile.
Step 2: From Tessent Shell:
dofile critical_paths.dofile

The dofile adds appropriate attributes to all the pins on the critical paths to prevent test points
from being placed there.

Parameters for “get_timing_paths” command

• -delay_type max
Specify “-delay_type max” to target setup violations (not hold violations).
• -max_paths number
The parameter “-max_paths number” specifies the maximum number of paths that will be
reported per domain. For example, if your design has two clock domains (clk1 and clk2),
and there are no false-path statements, you might have four domains (clk1, clk2, clk1->clk2,
and clk2->clk1).
• -nworst
The –nworst parameter avoids listing many “similar” paths. For example, if there are many
relatively long paths between <src> and <dest>, then setting “-nworst 1” means only the
path with the least slack will be reported. Set “-nworst 9999” to avoid adding test points to
any path that does not have enough slack to absorb it.
• -slack_lesser_than number
The “-slack_less_than number” parameter controls which paths get reported. Tune this
parameter based on the slack in your design.

118 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Appendix F
Test Point Analysis for Target Faults

This appendix describes how to perform test point analysis for a set of target faults for atpg.
An example of a set of target faults is the faults that are left undetected (AU) after performing
atpg. When atpg has completed you can write out the faults with the “write_faults” command.
Next, in the dft -testpoints context you read this fault set with the “read_faults” command and
perform test point analysis (“analyze_test_points”). Test point analysis will only consider the
undetected faults in the fault population and generate test points specifically for those faults.
After inserting the test points in the netlist you run atpg again. Because of the test points the
atpg will likely be able to generate patterns for many of the previously undetected faults.

By default, test point analysis uses a fault population of all possible stuck-at faults. In analysis
mode you can create a set of target faults with the commands “add_faults”, “delete_faults”
and/or “read_faults”. When you set up a fault set for use by the analyze_test_points command,
then that fault set is used to report the test coverage. Specifically, only the set of undetected
faults with fault class AU, UC, UO, PT or PU are used to calculate the test coverage. The test
coverage is calculated by assessing, for each fault, the probability that the fault will be detected
by a set of random patterns as specified by the -pattern_count_target option of the
“set_test_point_analysis_options” command. A high test coverage is an indication that atpg will
more likely be able to find a test pattern for most of the faults. But since the test coverage is
based on the probabilities that faults will be detected by a set of random patterns, there is no
direct correlation between the test coverage and the number of faults for which atpg will be able
to find a test pattern.

Only stuck-at fault sets will be supported for test point analysis. Faults in a fault list that is read
with the “read_faults” command will be interpreted as stuck-at faults, if possible. When the
fault set contains faults that cannot be interpreted as stuck-at faults (such as bridging faults or
UDFM faults) then an error will be given. The “set_fault_type” command is not supported in
the “dft -testpoints” context. The default fault type in this context is “stuck”.

The fault set that you create in the analysis system mode of the “dft -test_points” context will
not be modified by the “analyze_test_points” command. Specifically, this command will not
modify the class of any of the faults in the fault set. The fault set will be cleared when you
transition out of the analysis system mode. That is, when the “insert_test_logic” command is
executed then the system mode is transitioned to insertion mode and the fault set is cleared.
Also, if you transition back to the setup system mode from the analysis mode the fault set is
cleared. The commands “report_faults” and “write_faults” can be used to print out the target
fault set before transitioning out of analysis mode.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 119

June 2014
Test Point Analysis for Target Faults

Example
In the following example, the faults in the fault file “targetFault.list” are read in and the fault
class for each of these faults is retained. The command analyze_test_points identifies test points
for improving the testability of the undetected faults in the fault set and tries to achieve 100%
coverage of these faults with a maximum of 700 test points.
set_system_mode analysis
read_faults targetFault.list -retain
set_test_point_analysis_options -total 700 -test_coverage_target 100
analyze_test_points

Note that because the fault class of each fault in the file is retained, only undetected faults will
be targeted by test point analysis. Faults that have been detected already are ignored by test
point analysis.

The following is a snippet from the log file of a run with targeted faults:

// Test Coverage Report before Test Point Analysis

// -----------------------------------------------
// Target number of random patterns 1000
//
// Total Number of Targeted Faults 10682
// Testable Faults 10682 (100.00%)
// Logic Bist Testable 9995 ( 93.57%)
// Blocked by xbounding 0 ( 0.00%)
// Uncontrollable/Unobservable 687 ( 6.43%)
//
// Estimated Maximum Test Coverage 93.57%
// Estimated Test Coverage (pre test points) 36.31%
// Estimated Relevant Test Coverage (pre test points) 38.81%
//
//
// Inserted 6 observe points for unobserved gates.
//
// (cut)
//
// Test point analysis completed: maximum number of test points has been
reached.
// Inserted Test Points 700
// Control Points 347
// Observe Points 353
//
//
// Test Coverage Report after Test Point Analysis
// ----------------------------------------------
// Target number of random patterns 1000
//
// Total Number of Faults 10682
// Testable Faults 10682 ( 100.00%)
// Logic Bist Testable 10169 ( 95.20%)
// Blocked by xbounding 0 ( 0.00%)
// Uncontrollable/Unobservable 422 ( 3.95%)
//

120 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Test Point Analysis for Target Faults

// Estimated Test Coverage (post test points) 95.12%

// Estimated Relevant Test Coverage (post test points) 99.91%
Note
The Test Coverage Report only includes the target faults and not other faults such as
detected faults (DI, DS). Also note that the “before” and “after” test coverage reports
show that the (random pattern) “Estimated Test Coverage” has dramatically been
improved by inserting test points (from 35.88% to 94.04%).

Note
The number of “Uncontrollable/Unobservable” faults (422) in the report after test point
analysis is lower than the number of these faults before test point analysis (687). This is
due to the “6 observe points for unobserved gates”. These 6 observe points are not
counted in the total of 700 test points, but are over and above the 353 observe points that
together with 347 control points make up the total of 700 test points.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 121

June 2014
Test Point Analysis for Target Faults

122 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Appendix G
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.

Hybrid TK/LBIST Flow User’s Manual, v2014.2 123

June 2014
Getting Help
Mentor Graphics Support

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

124 Hybrid TK/LBIST Flow User’s Manual, v2014.2

June 2014
 Third-Party Information
For information about third-party software included with this release of Tessent products, refer to the Third-Party Software for
Tessent Products.
 End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula

IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMER’S COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.

END-USER LICENSE AGREEMENT (“Agreement”)

This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively “Products”)
between the company acquiring the Products (“Customer”), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (“Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties’ entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.

1. ORDERS, FEES AND PAYMENT.

1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any additional
or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order management
system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and physically signed
by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month or
the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes or
other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a valid
certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all applicable
taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all payments free
and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by Customer
hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or make
payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event of
default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision of
both a primary and an alternate e-mail address.

2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation 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 Customer’s
internal business purposes; (c) for the term of the license; and (d) on the computer hardware and at the site authorized by Mentor
Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer may have Software temporarily used by an employee for
telecommuting purposes from locations other than a Customer office, such as the employee’s residence, an airport or hotel, provided
that such employee’s primary place of employment is the site where the Software is authorized for use. Mentor Graphics’ standard
policies and programs, which vary depending on Software, license fees paid or services purchased, apply to the following: (a)
relocation of Software; (b) use of Software, which may be limited, for example, to execution of a single session by a single user on the
authorized hardware or for a restricted period of time (such limitations may be technically implemented through the use of
authorization codes or similar devices); and (c) support services provided, including eligibility to receive telephone support, updates,
modifications, and revisions. For the avoidance of doubt, if Customer provides any feedback or requests any change or enhancement to
Products, whether in the course of receiving support or consulting services, evaluating Products, performing beta testing or otherwise,
any inventions, product improvements, modifications or developments made by Mentor Graphics (at Mentor Graphics’ sole discretion)
will be the exclusive property of Mentor Graphics.

3. 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
 linked into a composite program as an integral part of Customer’s compiled computer program, provided that Customer distributes
these files only in conjunction with Customer’s 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
Customer’s 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 Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
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
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 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 Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. 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 Customer’s employees or on-site contractors,
excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in any manner
except to support this authorized use.
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 Customer’s 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 Customer’s requirements or that operation of Products will be uninterrupted or error free. The warranty
period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must notify Mentor
 Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty applies only to the
initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a) Software updates or
(b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty shall not be valid if
Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in compliance with this
Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE REMEDY SHALL BE, AT
MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF THE PRODUCTS TO
MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE PRODUCTS THAT DO NOT MEET THIS
LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B)
PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF WHICH ARE PROVIDED “AS IS.”
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.

8. LIMITATION OF LIABILITY. 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 CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR
TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.

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 Customer’s obligation to pay for Products shipped or licenses granted prior to the
termination, which amounts shall be payable immediately upon the date of termination.
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 Customer’s possession, including all copies and documentation, and
certify in writing to Mentor Graphics within ten business days of the termination date that Customer no longer possesses any of
the affected Products or copies of Software in any form.

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
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 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 Customer’s place of business is located. The United Nations
Convention on Contracts for the International Sale of Goods does not apply to this Agreement.

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