Et Flows

Encounter Test: Flows
Product Version 15.12

October 2015
2008-2015 Cadence Design Systems, Inc. All rights reserved.
Portions IBM Corporation, the Trustees of Indiana University, University of Notre Dame, the Ohio State
University, Larry Wall. Used by permission.
Printed in the United States of America.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Product Encounter Test and Diagnostics contains technology licensed from, and copyrighted by:
1. IBM Corporation, and is 1994-2002, IBM Corporation. All rights reserved. IBM is a Trademark of
International Business Machine Corporation;.
2. The Trustees of Indiana University and is 2001-2002, the Trustees of Indiana University. All rights
reserved.
3. The University of Notre Dame and is 1998-2001, the University of Notre Dame. All rights reserved.
4. The Ohio State University and is 1994-1998, the Ohio State University. All rights reserved.
5. Perl Copyright 1987-2002, Larry Wall
Associated third party license terms for this product version may be found in the README.txt file at
downloads.cadence.com.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or
registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are
used with permission.
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this document
are attributed to Cadence with the appropriate symbol. For queries regarding Cadences trademarks,
contact the corporate legal department at the address shown above or call 800.862.4522. [insert
trademark names of third party licensee, if any]. All other trademarks are the property
of their respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and
contains trade secrets and proprietary information owned by Cadence. Unauthorized reproduction or
distribution of this publication, or any portion of it, may result in civil and criminal penalties. Except as
specified in this permission statement, this publication may not be copied, reproduced, modified, published,
uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence.
Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to
print one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence and its
customer.
2. The publication may not be modified in any way.
3. Any authorized copy of the publication or portion thereof must include all original copyright,
trademark, and other proprietary notices and this permission statement.
4. The information contained in this document cannot be used in the development of like products or
software, whether for internal or external use, and shall not be used for the benefit of any other party,
whether or not for consideration.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does
not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or
usefulness of the information contained in this document. Cadence does not warrant that use of such
information will not infringe any third party rights, nor does Cadence assume any liability for damages or
costs of any kind that may result from use of such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth
in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Encounter Test Documentation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Getting Help for Encounter Test and Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Extended Message Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Contacting Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Encounter Test And Diagnostics Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Using Encounter Test Contrib Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
What We Changed for This Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Revisions for Version 15.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1
LBIST Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
LBIST Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Top-Down Test Synthesis Flow with Insertion of JTAG-Driven LBIST Logic . . . . . . . 16
Top-Down Test Synthesis Flow with Insertion of JTAG-Driven LBIST and 1500 Logic 21
Top-Down Test Synthesis Flow with Insertion of Direct-Access LBIST Logic . . . . . . 26
Encounter Test Flow for JTAG-Driven LBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Encounter Test Flow for Direct-Access LBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Example of Encounter Test JTAG-Driven LBIST Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Build Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Build Parent (JTAG) Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Report Parent (JTAG) Test Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Build Child (LBIST) Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Verify Child (LBIST) Test Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Build Faultmodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Read LBIST Test Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Create LBIST Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
October 2015 3 Product Version 15.12

1999-2015 All Rights Reserved.
Write LBIST Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Commit LBIST Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Debugging LBIST Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Signature Mismatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2
OPCG Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Processing OPCG Logic Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Processing Standard, Cadence Inserted OPCG Logic Designs . . . . . . . . . . . . . . . . 65
Processing Custom OPCG Logic Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Unique Encounter Test Tasks for OPCG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Creating OPCG Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Creating an OPCG Pin Assignment File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Building Test Mode Initialization Sequence Input File . . . . . . . . . . . . . . . . . . . . . . . . 74
OPCG Test Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3
Low Power Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Managing Power Consumption During Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Preparing a Netlist for Low Power Test Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Encounter Test Low Power Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Building the Low Power Logic Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Building a Low Power Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Analyzing Low Power Fault Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Generating and Analyzing Low Power Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4
RAM Sequential Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Use model flow selecting faults on the perimeter of all memories on the design . . . 101
Selecting specific memory modules for RAM sequential test by module name . . . . 102

Selecting specific memory modules for RAM sequential test by instance name . . . 102
5
Hierarchical Test Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Core Processing Methodology Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Chip Processing Methodology Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Example of Out-of-Context Core Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Create Tests for Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Prepare for Core Test Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Chip Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Requirements and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6
On-Product XOR Compression Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
XOR Compression Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
XOR Compression Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
XOR Compression Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7
SmartScan Compression Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Compression Serial and Parallel Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
SmartScan Testmodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Performing ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Converting Parallel Interface Patterns to Serialized Patterns . . . . . . . . . . . . . . . . . . 137
Compression with Serial Only Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Debugging Miscompares in SmartScan Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
SmartScan Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Using OPCG with SmartScan Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Using External Pipelines with SmartScan Compression . . . . . . . . . . . . . . . . . . . . . . . . 149

Use Model for SmartScan with External Pipelines . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Requirements and Limitations for External Pipelines . . . . . . . . . . . . . . . . . . . . . . . . 155
8
Generating IEEE 1687 (IJTAG) Compliant Macro Tests . . . . 157
IJTAG IEEE 1687 Macro Test Generation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Building Encounter Test Model and Testmode(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Reading ICL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Migrating PDL Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Processing Tester Controlled Clocks Asynchronous to TCK . . . . . . . . . . . . . . . . . . 188
Processing Tester Controlled Clocks Correlated to TCK . . . . . . . . . . . . . . . . . . . . . 190
Handling Scan Chains Spread Across Multiple Macros . . . . . . . . . . . . . . . . . . . . . . 191
Assumptions and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Preface
Typographic and Syntax Conventions

The Encounter Test library set uses the following typographic and syntax conventions.
Text that you type, such as commands, filenames, and dialog values, appears in Courier
type.
Example: Type build_model -h to display help for the command.
Variables appear in Courier italic type.
Example: Use TB_SPACE_SCRIPT=input_filename to specify the name of the
script that determines where Encounter Test binary files are stored.
Optional arguments are enclosed in brackets.
Example: [simulation=gp|hsscan]
User interface elements, such as field names, button names, menus, menu commands,
and items in clickable list boxes, appear in Helvetica italic type.
Example: Select File - Delete - Model and fill in the information about the model.

Preface
Encounter Test Documentation Roadmap

The following figure depicts a recommended flow for traversing the documentation structure.
Getting
Started Overview and
New User
Quickstart
Models
Testmodes
Guides
Test Structures
Faults
ATPG
Test Vectors
Diagnostics
Flow PMBIST Pattern

PMBIST Analysis ET Flows Generation
Commands GUI Expert

Reference Messages Test Pattern Formats
Documents
Extension Language Glossary

Preface
Getting Help for Encounter Test and Diagnostics

Use the following methods to obtain help information:
1. From the <installation_dir>/tools/bin directory, type cdnshelp and press
Enter. The installed Cadence documentation set is displayed.
2. To view a book, double-click the desired product book collection and double-click the
desired book title in the lower pane to open the book.
Click the Help or ? buttons on Encounter Test forms to navigate to help for the form and its
related topics.
Refer to the following in the Encounter Test: Reference: GUI for additional details:
Help Pull-down describes the Help selections for the Encounter Test main window.
View Schematic Help Pull-down describes the Help selections for the Encounter Test
View Schematic window.
Extended Message Help

All Encounter Test numbered messages, their accompanying explanations and user
responses, are documented in the Encounter Test: Reference: Messages.
Display Interactive extended help information for a message by entering one of the following
commands either directly on the command line or in the GUI Command Input field:
msgHelp <message_prefix-error_number1> <message_prefix-
error_number1> ...
For example,
msgHelp TSV-001 TSV-314
displays interactive help information for messages TSV-001 and TSV-314.
help <message_prefix-error_number1> displays interactive help for the
specified message.
The GUI Session Log is also available to view message text and extended help. Refer to
Using the Session Log to View Message Help in the Encounter Test: Reference: GUI for
details

Preface
Contacting Customer Service

Use the following methods to get help for your Cadence product.
Cadence Online Customer Support
Cadence online customer support offers answers to your most common technical
questions. It lets you search more than 40,000 FAQs, notifications, software updates,
and technical solutions documents that give step-by-step instructions on how to solve
known problems. It also gives you product-specific e-mail notifications, software updates,
service request tracking, up-to-date release information, full site search capabilities,
software update ordering, and much more.
Go to http://www.cadence.com/support/pages/default.aspx for more information on
Cadence Online Customer Support.
Cadence Customer Response Center (CRC)
A qualified Applications Engineer is ready to answer all of your technical questions on
the use of this product through the Cadence Customer Response Center (CRC). Contact
the CRC through Cadence Online Support. Go to http://support.cadence.com and click
the Contact Customer Support link to view contact information for your region.
IBM Field Design Center Customers
Contact IBM EDA Customer Services at 1-802-769-6753, FAX 1-802-769-7226. From
outside the United States call 001-1-802-769-6753, FAX 001-1-802-769-7226. The e-
mail address is edahelp@us.ibm.com.
Encounter Test And Diagnostics Licenses

Refer to Encounter Test and Diagnostics Product License Configuration in Encounter Test:
Release:Whats New for details on product license structure and requirements.
Using Encounter Test Contrib Scripts

The files and Perl scripts shipped in the <ET installation path>/etc/tb/contrib
directory of the Encounter Test product installation are not considered as "licensed
materials". These files are provided AS IS and there is no express, implied, or statutory
obligation of support or maintenance of such files by Cadence. These scripts should be
considered as samples that you can customize to create functions to meet your specific
requirements.

Preface
What We Changed for This Edition
Revisions for Version 15.12

Added a chapter on Generating IEEE 1687 (IJTAG) Compliant Macro Tests.

There are no significant modifications specific to this version of the manual.

Added section Read Power Intent on page 91.
Moved the following chapters from Encounter Test: Guide 2: Testmodes:
On-Product XOR Compression Flow on page 121
SmartScan Compression Flow on page 131

Preface

1
LBIST Flow
This chapter covers the following topics:

Introduction
LBIST Flows
Example of Encounter Test JTAG-Driven LBIST Flow
Debugging LBIST Structures
Introduction
Logic built-in self-test (LBIST) is inserted into a design to generate patterns for self-testing.
LBIST allows for field/system testing without the need for automated test equipment (ATE)
and at times it is used during wafer/burn-in testing. Figure 1-1 shows a typical ASIC with
LBIST logic (in yellow) and other test components. RTL Compiler provides an automated way
to insert LBIST logic, while Encounter Test provides support to generate the patterns and
observe the responses.

LBIST Flow
Figure 1-1 Chip with LBIST and Other Test Components
The LBIST solution that is supported (shown in Figure 1-2) is based on a STUMPS (Self Test
Using MISR and Parallel SRPG) architecture and (optionally) supports run-time programming
via JTAG. The inserted LBIST logic uses:
A pseudo-random pattern generator (PRPG), also referred to as Shift Register
Sequence Generator (SRSG), to generate input patterns that are applied to the scan
channels.
A multiple input signature register (MISR) to obtain the response to these test input
patterns. An incorrect MISR output indicates a defect in the chip.

LBIST Flow
Figure 1-2 LBIST Architecture
For more information on the architecture and features of the current LBIST solution inserted
by RTL Compiler, refer to the chapter Inserting Logic Built-In-Self-Test Logic in the
Design For Test in Encounter RTL Compiler Guide.
LBIST Flows
The following LBIST flows are currently supported for RC DFT and Encounter Test:
JTAG-Driven LBIST
This includes OPCG and testing of MBIST logic
JTAG-Driven LBIST with 1500 Logic
Direct Access Controlled LBIST
This does not have OPCG support

LBIST Flow
Top-Down Test Synthesis Flow with Insertion of JTAG-Driven LBIST Logic

Figure 1-3 highlights the tasks you need to add to the top-down test synthesis flow to
automatically insert the LBIST logic.

LBIST Flow
Figure 1-3 Top-Down Test Synthesis Flow with JTAG-Driven LBIST Insertion
START Task added or

changed for LBIST
Read Libraries, Design, and SDC Constraints
Task added for DFT
Define DFT Control Signals
Optional Task
Synthesize to Generic Logic
Add RUNBIST and SETBIST instructions
Insert Boundary Scan Logic
Add OPCGLOAD if doing OPCG
Insert OPCG Logic
Run Advanced DFT Rule Checker

X-source identification and fixing is
required
Fix DFT Violations
Insert MBIST Logic
Synthesize Design and Map to Scan
Add ATPG-Related Testability Logic
Connect Scan Chains
Compress Scan Chains

LBIST logic instruction uses compression
Insert LBIST channels and interfaces with JTAG logic
Export to Encounter Test
Refer to Encounter Test Flow in Figure 1-6
Recommended Flow
1. Read Libraries, Design, and SDC Constraints

LBIST Flow
a. Read the libraries.

- set_attribute library library_list /
b. Read in the design (RTL or gate-level netlist).

- read_hdl design
elaborate
or
- read_hdl -struct mapped_netlist
c. Read in an SDC file to define the timing constraints for the functional design.
2. Define DFT Control Signals - Specify the DFT setup to define the (full scan) test signals,
test clocks, and mark the objects that do not need to be mapped to scan.
a. Define your test signals (shift enable and test mode).

- define_dft shift_enable ....
- define_dft test_mode ... (design dependent)
b. Define your full scan test clocks.

- define_dft test_clock ...
c. Mark any objects--such as a pre-instantiated JTAG macro--that must not be mapped

to scan.
3. Synthesize to Generic Logic.
a. synthesize -to_generic
4. Insert Boundary Scan Logic.
a. Define the JTAG instructions: RUNBIST and/or SETBIST.

- define_dft jtag_instruction_register -name string ...
- define_dft jtag_instruction -name SETBIST -opcode 001 -
register SETBIST -length 1
- define_dft jtag_instruction -name RUNBIST -opcode 010 -
register RUNBIST -length 1
Note: If OPCG logic is to be inserted, you also define the OPCGLOAD instruction.

LBIST Flow
- define_dft jtag_instruction -name OPCGLOAD -opcode 011 -

register OPCGLOAD -length 1
b. insert_dft boundary_scan ...

Note: For more information, see Inserting Boundary-Scan Logic in Design For
Test in Encounter RTL Compiler Guide.
5. Insert OPCG Logic (Optional)
a. Enable the insertion of OPCG domain blocking logic for inter-domain paths:
- set_attribute dft_opcg_domain_blocking true /
b. Insert the OPCG logic.

- insert_dft opcg ....
6. Run Advanced DFT Rule Checker - To find DFT rule violations and x-source violations.
a. check_dft_rules -advanced
7. Fix DFT Rule Violations If there are any X-source violations, they must be fixed
a. fix_dft_violations
8. Insert MBIST logic (Optional)
a. insert_dft mbist ...

Note: For more information, see Inserting Memory Built-in-Self-Test Logic in Design
For Test in Encounter RTL Compiler Guide.
9. Synthesize Design and Map to Scan
a. synthesize -to_mapped
Note: Only required if you started from RTL.
10. Add ATPG-Related Testability Logic (Optional) - Insert shadow logic for blackboxes and
RRFA test points for improved test coverage.
a. insert_dft shadow_logic ...
b. insert_dft rrfa_test_points ...

Note: Refer to Inserting DFT Shadow Logic and Using Encounter Test to Automatically
Select and Insert Test Points in Design For Test in Encounter RTL Compiler Guide
for more information.
11. Connect Scan Chains

LBIST Flow
a. Connect the fullscan scan chains and generate the full scan chain reports.
- connect_scan_chains [-preview] ...
- report dft_chains
b. (Only if OPCG) Connect the OPCG macro segments into the full scan chains, and
build the OPCG side-scan chains. Report the full scan and side scan chains.
- connect_opcg_segments [-preview] ...
- report dft_chains [-opcg_side_scan]
c. (Only if OPCG) If you enabled OPCG domain blocking, insert toggle muxes to
increase ATPG effectiveness.
- set_opcg_equivalent ...
- replace_opcg_scan -edge_mode ...
Note: For more information, see Inserting On-Product Clock Generation Logic in
Design For Test in Encounter RTL Compiler Guide.
12. Compress Scan Chains -- Insert the scan chain compression logic and generate the
compression chain report.
a. compress_scan_chains [-preview] ...
b. report dft_chains
13. Insert LBIST
a. insert_dft logic_bist ...

14. Export to Encounter Test
a. write_et_lbist -library ...
b. write_et_bsv -library
c. write_et_atpg -library
Note: Refer to Generating Files for LBIST Pattern Generation and Simulation in
Design For Test in Encounter RTL Compiler Guide for more information.

LBIST Flow
Top-Down Test Synthesis Flow with Insertion of JTAG-Driven LBIST and

1500 Logic

LBIST Flow
Figure 1-4 Top-Down Test Synthesis Flow with JTAG-Driven LBIST and 1500 Insertion
START Task added or

changed for LBIST
Task added for DFT
Optional Task
Add RUNBIST and SETBIST instructions
Insert JTAG Macro
Add OPCGLOAD if doing OPCG
Insert OPCG Logic

required
Fix DFT Violations
Insert MBIST Logic
Insert 1500 or Isolation Logic Isolation to ensure no X-sources from PI
Connect Scan Chains
LBIST logic instruction uses compression

Insert LBIST channels and interfaces with JTAG logic

LBIST Flow
Recommended Flow

- set_attribute library library_list /

- read_hdl design
elaborate
or



to scan.
4. Insert JTAG Macro
a. Define the JTAG instructions: RUNBIST and/or SETBIST.

- define_dft jtag_instruction_register -name string ...
- define_dft jtag_instruction -name SETBIST -opcode 001 -
register SETBIST -length 1
- define_dft jtag_instruction -name RUNBIST -opcode 010 -
register RUNBIST -length 1

LBIST Flow
Note: If OPCG logic is to be inserted, you also define the OPCGLOAD instruction.
- define_dft jtag_instruction -name OPCGLOAD -opcode
011 - register OPCGLOAD -length 1
b. insert_dft jtag_macro ...

Note: For more information, see Working with a JTAG Macro in Design For Test
in Encounter RTL Compiler Guide.
5. Insert OPCG Logic (Optional)
a. Enable the insertion of OPCG domain blocking logic for inter-domain paths:
- set_attribute dft_opcg_domain_blocking true /
b. Insert the OPCG logic.

- insert_dft opcg ....
6. Run Advanced DFT Rule Checker - to find DFT rule violations and X-source violations.

Note: For more information, see Inserting Built-in-Self-Test Logic in Design For
10. Insert 1500 or Isolation Logic
a. Insert the wrapper mode decode block.

- insert_dft wrapper_mode_decode_block ....
b. Insert the wrapper cell

- insert_dft wrapper_cell ....

LBIST Flow
Note: For more information, see Inserting Core-Wrapper Logic in Design For Test

Note: Refer to Inserting DFT Shadow Logic and Using Encounter Test to
Automatically Select and Insert Test Points in Design For Test in Encounter RTL
Compiler Guide for more information.
12. Connect Scan Chains
a. Connect the fullscan scan chains and generate the full scan chain reports.
- connect_scan_chains [-preview] ...
- report dft_chains
b. (Only if OPCG) Connect the OPCG macro segments into the full scan chains, and
build the OPCG side-scan chains. Report the full scan and side scan chains.
- connect_opcg_segments [-preview] ...
- report dft_chains [-opcg_side_scan]
c. (Only if OPCG) If you enabled OPCG domain blocking, insert toggle muxes to
increase ATPG effectiveness.
- set_opcg_equivalent ...
- replace_opcg_scan -edge_mode ...
Note: For more information, see Inserting On-Product Clock Generation Logic in
Design For Test in Encounter RTL Compiler Guide
14. Insert LBIST

LBIST Flow
a. insert_dft logic_bist ....

b. write_et_bsv -library
c. write_et_atpg -library
Note: Refer to Generating Files for LBIST Pattern Generation and Simulation
in Design For Test in Encounter RTL Compiler Guide for more information.
Top-Down Test Synthesis Flow with Insertion of Direct-Access LBIST

Logic

LBIST Flow
Figure 1-5 Inserting Direct Access LBIST logic
START Task added or

changed for LBIST
Task added for DFT
Optional Task

required
Fix DFT Violations
Insert MBIST Logic
Insert 1500 or Isolation Logic Isolation to ensure no X-sources from PI
Connect Scan Chains
Insert LBIST Add direct access LBIST

LBIST Flow
Recommended Flow

- set_attribute library library_list

- read_hdl design
elaborate
or



to scan.
4. Run Advanced DFT Rule Checker - to find DFT rule violations and x-source violations.

LBIST Flow

Note: For more information, see Inserting Built-in-Self-Test Logic in Design For
8. Insert 1500 or Isolation Logic
a. Insert the wrapper mode decode block.

- insert_dft wrapper_mode_decode_block ....
b. Insert the wrapper cell

- insert_dft wrapper_cell ....
Note: For more information, see Inserting Core-Wrapper Logic in Design For Test

Note: Refer to Inserting DFT Shadow Logic and Using Encounter Test to
Automatically Select and Insert Test Points in Design For Test in Encounter RTL
Compiler Guide for more information.
10. Connect Scan Chains -- Connect the fullscan scan chains and generate the full scan
chain reports.
a. connect_scan_chains [-preview] ...
12. Insert LBIST

LBIST Flow
a. insert_dft logic_bist direct_access

-direct_test_mode test_signal -direct_reset port
-direct_logic_bist_enable port ...

Note: Refer to Generating Files for LBIST Pattern Generation and Simulation
in Design For Test in Encounter RTL Compiler Guide for more information.
Encounter Test Flow for JTAG-Driven LBIST

The following figure shows a typical processing flow for running Logic Built-In Self Test on a
design with JTAG-Driven LBIST. The process for inserting JTAG-Driven LBIST with RTL-
Compiler is shown previously (see Figure 1-4 or 1-5).
If the design had LBIST inserted by RTL-Compiler, the last step of the process generates a
set of directories and scripts that automate the Encounter Test flow. The flows for running
BSV (1149 boundary scan verification), ATPG, and LBIST are contained in three separate
directories with a run script for each flow that starts with Build Model. This simplifies the
process, and you can simply run the scripts in the following order to complete the Encounter
Test processing:
1. atpg_lbist_jtag_workdir/runet.atpg (creates scanchain and logic test vectors)
2. bsv_lbist_jtag_workdir/runet.bsv (generates patterns to verify the 1149.1 TAP,
instructions, and test data registers)
3. lbist_jtag_workdir/run_lbist_RUNBIST or run_lbist_SETBIST (simulates
the self test and generates signatures)
If working with a large design, you may want to combine scripts to avoid duplication of steps
and, if you are using LBIST for manufacturing test, take advantage of cross-mode fault
markoff (as shown in Figure 1-6).
Note: If your design has JTAG-Driven LBIST that is not inserted by RTL-Compiler, it must
meet the same requirements as the LBIST inserted with RC (see Inserting LBIST Logic for
more information).

LBIST Flow
Tip
The LBIST RAK on the Customer Online Support web site (http://
support.cadence.com) includes a Lab on JTAG-Driven LBIST. If this methodology is
new to you it is highly recommended that you try out the RAK. The RAK uses the
RC-DFT methodology for Encounter Test rather than the consolidated one, but the
steps are basically the same.

LBIST Flow
Figure 1-6 Encounter Test JTAG-Driven Logic Built-In Self Test Processing Flow
Build Encounter Test Model Task added or changed for LBIST
Build 1149 Testmode and Verify 1149.1 Optional Task

Boundary Logic
Write Test Vectors for 1149 and TB_EXTEST_CAP_UPDT Testmode is

TB_EXTEST_CAP_UPDT Testmode built by the verify_11491_boundary com-
Build Parent (JTAG) Testmode
Report Parent (JTAG) Test Structures Fix any problems with JTAG structures
before continuing
Build Child (LBIST) Testmode
Analyze and fix any severe warnings

Verify Child (LBIST) Test Structures before continuing
Build ATPG Testmodes (FULLSCAN, If you are creating your own script, these
COMPRESSION,COMPRESSION DECOMP) testmodes and the child (LBIST) testmode
can be built simultaneously
Verify ATPG Testmodes Test Structures Analyze and fix any severe warnings
before continuing
Build Faultmodel
Read LBIST Test Sequence
Create LBIST Tests
Write LBIST Vectors
Commit LBIST Tests If LBIST is done for manufacturing test
Create Tests, Write Vectors, and Commit Tests

for ATPG Testmodes
Simulate Vectors with ncverilog

LBIST Flow
Recommended Flow
1. Build an Encounter Test model.
- build_model cell=top_module_name
designsource=<verilog_netlist_location>
techlibs=<technology_library_location> blackbox=yes
blackboxoutputs=z
Setting blackboxoutputs to z keeps them from being X-sources.
Refer to Performing Build Model in the Encounter Test: Guide 1: Models for more
information.
2. Build BSV Testmode and Verify 1149.1 Boundary Logic
- build_testmode testmode=1149 bsdlinput=<bsdlname>
bsdlpkgpath=<location of 2001 bsdl package files>
assignfile=<assignfilename>
- verify_11491_boundary testmode=1149 bsdlinput=<bsdlname>
bsdlpkgpath=<location of 2001 bsdl package files>
Refer to Verify 1149.1 Boundary Scan in Encounter Test: Guide 3: Test Structures
for additional information.
3. Write Test Vectors for 1149 and TB_EXTEST_CAP_UPDT Testmodes - writes out
Verilog test vectors for Verilog simulation.
- write_vectors testmode=1149 inexperiment=11491expt
scanformat=serial
- write_vectors testmode=TB_EXTEST_CAP_UPDT
inexperiment=11491expt scanformat=serial
Note: TB_EXTEST_CAP_UPDT testmode is created automatically by
verify_11491_boundary for the iopinmapping checks.
Refer to Writing Verilog in Encounter Test: Guide 6: Test Vectors for more
information.
4. Build Parent (JTAG) Testmode.
- build_testmode testmode=MODE_JTAG_RUNBIST
modedefpath=<location of mode definition file>
seqdef=<location of file with mode initialization sequence>
Note:

LBIST Flow
If you are not using RC-DFT, the testmode name may be something different but it
should follow the example provided by RC-DFT.
The RC-DFT testmode name when using SETBIST is MODE_JTAG_SETBIST.
All input files associated with RUNBIST processing contain the string RUNBIST.
All input files associated with SETBIST processing contain the string SETBIST.
RC-DFT puts a mode definition file in the WORKDIR with the same name as the
testmode. If the name of the mode definition file is different than the testmode, then
the modedef keyword also must be specified to identify the mode definition file.
RC-DFT puts a sequence definition file with the mode initialization sequence in the
WORKDIR with the name TBDseqPatt.JTAG_RUNBIST or
TBDseqPatt.JTAG_SETBIST.
RC-DFT puts an assignfile in the WORKDIR with the name
assignfile.JTAG.RUNBIST or assignfile.JTAG.SETBIST. The assignfile
defines the JTAG pin functions (TMS, TRST, TCK, TDI, TDO) and the clocks (PI and
OPCG) to be used for LBIST.
Refer to Multiple Test Modes in Encounter Test: Guide 2: Testmodes for additional
information.
5. Report Parent (JTAG) Test Structures
- report_test_structures testmode=MODE_JTAG_RUNBIST
reportscanchain=all
The scanchain from TDI to TDO should be both controllable and observable.
6. Build Child (LBIST) Testmode
- build_testmode testmode=MODE_LBIST_RUNBIST modedef=MODE_LBIST
modedefpath=<location of mode definition file>
seqdef=<location of file with mode initialization sequence>
Note:
If you are not using RC-DFT, the testmode name may be something different but it
should follow the example provided by RC-DFT.
The RC-DFT testmode name when using SETBIST is MODE_LBIST_SETBIST.
RC-DFT puts the mode definition file in the WORKDIR with the name shown in the
sample command. If you are using SETBIST, the name of the mode definition file is

LBIST Flow
the same; there is no difference in the mode definition file between RUNBIST and
SETBIST for this testmode.
RC-DFT puts a sequence definition file with the mode initialization sequence in the
WORKDIR with the name TBDseqPatt.LBIST_RUNBIST or
TBDseqPatt.LBIST_SETBIST. Note that the Begin_Test_Mode statement in
the mode initialization sequence for this testmode must point to the correct name for
the parent testmode.
RC-DFT puts an assignfile in the WORKDIR with the name
assignfile.LBIST.RUNBIST or assignfile.LBIST.SETBIST. The
assignfile defines the clocks and identifies the PRPG and MISR.
7. Verify Child (LBIST) Test Structures
- verify_test_structures testmode=MODE_LBIST_RUNBIST
For SETBIST the testmode=MODE_LBIST_SETBIST.
Non conformance to these guidelines may result in poor test coverage or invalid test
data. If you receive any severe warnings analyze them to understand the condition and
fix the issue. It is especially important to fix any X-source issues. Refer to Verify Test
Structures in the Encounter Test: Guide 3: Test Structures.
8. Build ATPG test modes
- build_testmode testmode=FULLSCAN
- build_testmode testmode=COMPRESSION
- build_testmode testmode=COMPRESSION_DECOMP
9. Verify ATPG Testmodes Test Structures
- verify_test_structures testmode=FULLSCAN
- verify_test_structures testmode=COMPRESSION
- verify_test_structures testmode=COMPRESSION_DECOMP
Refer to Performing Verify Test Structures in the Encounter Test: Guide 3: Test
Structures for more information
10. Build a Fault model
- build_faultmodel
This step is not required unless you are planning to fault grade the lbist sequences or run
ATPG.

LBIST Flow
Refer to the Building a Fault Model in the Encounter Test: Guide 4: Faults for more
information.
11. Read LBIST Test Sequences
- read_sequence_definition testmode=MODE_LBIST_RUNBIST
importfile=<file containing the test sequence>
LBIST requires a sequence to be read in and simulated.
RC-DFT generates the sequence in file TestSequence.seq.
If you are writing your own test sequence, the following is a Universal Test Sequence that
can be used as a template.
See Coding Test Sequences in Encounter Test: Guide 5: ATPG for more information.
The following example of the RC-DFT generated sequence uses OPCG (PPI's) for the
LBIST sequence:
TBDpatt_Format (mode=node, model_entity_form=name);
[Define_Sequence Universal_Test (test);
[ Pattern ; # Set Test Constraints to post-scan value
Event Stim_PPI ():
"int_SE"=0
"int_capture"=1 ; ] Pattern ;
[ Pattern ; Event Pulse_PPI ():"scancaptck"=+; ] Pattern ;
[ Pattern ; Event Channel_Scan (); ] Pattern ;
] Define_Sequence Universal_Test;
12. Create LBIST Tests

- create_lbist_tests testmode=MODE_LBIST_RUNBIST
experiment=lbist_test_RUNBIST...
Refer to Create Logic Built-in Self Test (LBIST) Tests in Encounter Test: Guide 5:
ATPG for complete information.
13. Write Vectors
- write_vectors testmode=MODE_LBIST_RUNBIST
inexperiment=lbist_test_RUNBIST...
Refer to Writing and Reporting Test Data in Encounter Test: Guide 6: Test Vectors
for complete information.
14. Commit Tests
- commit_tests testmode=MODE_LBIST_RUNBIST
inexperiment=lbist_test

LBIST Flow
Run this step if you are using LBIST for manufacturing tests; otherwise commit_tests
is not done.
Note: commit_tests is not part of the flow in the scripts generated by RC-DFT.
The master fault status is updated so faults marked off from the LBIST simulation will not
be tested in subsequent test generation runs.
For complete information, refer to Utilities and Test Vector Data in Encounter Test:
Guide 6: Test Vectors.
15. Create Tests, Write Vectors, and Commit Tests for ATPG Testmodes
- create_scanchain_tests testmode=COMPRESSION
experiment=chip_compression
- create_logic_tests testmode=COMPRESSION
experiment=chip_compression append=yes
- write_vectors testmode=COMPRESSION
inexperiment=chip_compression
- commit_tests testmode=COMPRESSION
- create_logic_tests testmode=COMPRESSION_DECOMP
- write_vectors testmode=COMPRESSION_DECOMP
- commit_tests testmode=COMPRESSION_DECOMP
- create_logic_tests testmode=FULLSCAN
- write_vectors testmode=FULLSCAN inexperiment=chip_compression
The commit_tests for each testmode updates the master fault status so the test
generation for the next testmode starts at that fault status (faults already tested in one
testmode will not be re-tested in the next testmode).
16. Simulate Vectors with ncsim or other Verilog Simulator
- ncverilog +TESTFILE1=<verilog_file_from write_vectors>
This is done for each set of vectors that was written during this flow.

LBIST Flow
Encounter Test Flow for Direct-Access LBIST
Figure 1-7 Encounter Test Direct-Access Logic Built-In Self Test Processing Flow
Build Encounter Test Model Task added or changed for LBIST
Build (LBIST_DIRECT) Testmode Optional Task

Verify (LBIST_DIRECT) Test Structures
before continuing
Build ATPG Testmodes (FULLSCAN, If you are creating your own script, these
testmodes and the child (LBIST_DIRECT)
COMPRESSION,COMPRESSION DECOMP) testmode can be built simultaneously
Verify ATPG Testmodes Test Structures
before continuing
Build Faultmodel
Read LBIST Test Sequences
Create LBIST Tests to Generate Signature
Commit LBIST Tests If LBIST is done for manufacturing test
Identify Signature Comparison Value
Edit Verilog to Include Signature
Build NCSIM Testmode
Read Vectors for NCSIM
Write Vectors for NCSIM
Create Tests, Write Vectors, and Commit Tests

for ATPG Testmodes
Simulate Vectors with ncverilog

LBIST Flow
Recommended Flow
1. Build Encounter Test model.
- build_model cell=top_module_name
designsource=<verilog_netlist_location>
techlibs=<technology_library_location> blackbox=yes
blackboxoutputs=z
Setting blackboxoutputs to z keeps them from being X-sources.
information.
2. Build (LBIST_DIRECT) Testmode.
- build_testmode TESTMODE=MODE_LBIST_DIRECT
assignfile=assignfile.MODE_LBIST_DIRECT seqdef=<workdir>/
TBDseqPatt.MODE_LBIST_DIRECT modedef=MODE_LBIST
modedefpath=<workdir>
Since direct-access LBIST does not read out a signature, there is no need to have a
parent testmode where the values can be scanned out. Therefore, no parent testmode
is defined.
3. Verify (LBIST_DIRECT) Test Structures
- verify_test_structures testmode=MODE_LBIST_DIRECT
Refer to Verify Test Structures in the Encounter Test: Guide 3: Test Structures.
4. Build ATPG Testmodes (optional)
- build_testmode testmode=FULLSCAN
- build_testmode testmode=COMPRESSION
- build_testmode testmode=COMPRESSION_DECOMP
5. Verify ATPG Testmodes Test Structures
- verify_test_structures testmode=FULLSCAN
- verify_test_structures testmode=COMPRESSION
- verify_test_structures testmode=COMPRESSION_DECOMP
Refer to Performing Verify Test Structures in the Encounter Test: Guide 3: Test
Structures for more information.
6. Build a fault model for the design.

LBIST Flow
- build_faultmodel
Refer to the Building a Fault Model in the Encounter Test: Guide 4: Faults for more
information.
7. Read LBIST Test Sequences
- read_sequence_definition testmode=MODE_LBIST_DIRECT
importfile=<workdir>/TestSequence.seq
To use user-defined clock sequences, read the test sequence definitions.
See Coding Test Sequences in Encounter Test: Guide 5: ATPG for an explanation of
how to manually create test (clock) sequences.
8. Create LBIST Tests
- create_lbist_tests testmode=MODE_LBIST_DIRECT
experiment=lbist_test_direct testsequence=Universal_Test
prpginitchannel=yes forceparallelsim=yes . . .
If you are using LBIST for manufacturing tests, it is recommended that you use fault
simulation, which is the default for this command. Otherwise, you may want to specify
keyword gmonly=yes to do good machine simulation instead.
Refer to Create Logic Built-in Self Test (LBIST) Tests in Encounter Test: Guide 5:
ATPG for complete information.
9. Commit Tests (optional)
This task is run only if you are using LBIST for Manufacturing tests.
- commit_tests testmode=MODE_LBIST_DIRECT
inexperiment=lbist_test_direct
10. Identify Signature Comparison Value
Use report_vectors to generate the ASCII format of the vectors and find the
signature. There is no official command to find this data and re-format it to the required
format for updating the Verilog. However, there is a contrib script,
IdentifyMISRCompareValue.pl, that can be used for this purpose. Contrib scripts
can be used directly or copied to your own space and modified for customized
requirement. To use this contrib script:
- report_vectors testmode=MODE_LBIST_DIRECT
experiment=lbist_test_direct outputfile=STDOUT
| IdentifyMISRCompareValue.pl > <workdir>/MISR_RESULTS.log

LBIST Flow
For complete information, refer to Utilities and Test Vector Data in Encounter Test:
Guide 6: Test Vectors.
11. Edit Verilog to Include Signature
Use your favorite editor to edit the input netlist. You will insert the signature generated
from create_lbist_tests into the netlist so the signature is stored in the design
when it is simulated by ncverilog.
- Find the last occurrence of .misr_compare in the file.
- Comment out the existing definition for .misr_compare
- Include the .misr_compare value, shown as the Final Signature value in the
MISR_RESULTS.log file, in place of the definition you commented out.
12. Build NCSIM Testmode
- build_testmode testmode=NCSIM modedef=FULLSCAN
assignfile=<workdir>/assignfile.NCSIM
This is a testmode used to allow RC-generated patterns to be converted to the Verilog
format required for functional simulation.
13. Read Vectors for NCSIM
- read_vectors testmode=NCSIM importfile=TBDpatt.NCSIM
experiment=read
These patterns created by RC DFT allow verification of the signature you edited into the
netlist in the previous step.
14. Write Vectors for NCSIM
- write_vectors testmode=NCSIM inexperiment=read
includemodeinit=no
This writes out the patterns in Verilog format. The testmode initialization for NCSIM does
not matter for these patterns so there is no need to write it out.
For complete information, see Writing and Reporting Test Data in Encounter Test:
Guide 6: Test Vectors for complete information.
15. Create Tests, Write Vectors, and Commit Tests for ATPG Testmodes
- create_scanchain_tests testmode=COMPRESSION
- create_logic_tests testmode=COMPRESSION
experiment=chip_compression append=yes

LBIST Flow
- write_vectors testmode=COMPRESSION
- commit_tests testmode=COMPRESSION
- create_logic_tests testmode=COMPRESSION_DECOMP
- write_vectors testmode=COMPRESSION_DECOMP
- commit_tests testmode=COMPRESSION_DECOMP
- create_logic_tests testmode=FULLSCAN
- write_vectors testmode=FULLSCAN inexperiment=chip_compression
The commit_tests for each testmode updates the master fault status so the test
generation for the next testmode starts at that fault status (faults already tested in one
testmode will not be re-tested in the next testmode).
16. Simulate Vectors with ncsim or other Verilog Simulator
- ncverilog +TESTFILE1=<verilog_file_from write_vectors>
This is done for each set of vectors that was written during this flow.
Example of Encounter Test JTAG-Driven LBIST Flow

This section shows just the steps of the process that are specifically for LBIST using the JTAG
interface and OPCG to control the LBIST environment. The flow section shows where other
steps are included when you are running multiple test methodologies for the design; such as
performing boundary scan verification of the JTAG or performing ATPG to top off the coverage
for manufacturing test.
Build Model
There is nothing unique about building the model for LBIST. The LBIST structures are
represented in the netlist and technology libraries. You only need to run the command and
ensure that the log reflects that the model was built successfully.

LBIST Flow
Command:
build_model cell=DLX_TOP blackbox=yes blackboxoutputs=z industrycompatible=yes
designsource=./DLX_TOP.et_netlist.v.gating_pgmclk_shiftdr_exit1_v2 techlib=./
techlibs/include_libraries.v,home_rcap_nightly_lib_sim/
tsmc25.v,home_rcap_nightly_lib_sim/tpz013g3.v,home_rcap_nightly_lib_sim/tsmc13.v
teiperiod=__rcETdft_
This command is the default generated by RC DFT and does the following:
Allows blackboxes to be included in the model and sets their outputs to z rather than x.
Requests the model to be built to allow for an industry compatible faultmodel. See
Example 11: Improving Fault Model Compatibility with Other ATPG Tools in Encounter
Test: Guide 1: Models and Build Fault Model Examples for Cell Boundary Fault Model
in Encounter Test: Guide 4: Faults for more information on industry compatible, cell
boundary, faultmodels.
Points to the location of the design source, the verilog netlist output from RC-DFT
Points to the technology libraries used to define the test view of each library cell
Identifies a unique string to use in place of a period in a name. Encounter Test uses
periods to delimit hierarchy. If the name of a module includes a period (for example,
abc.def), then a character string is used to represent the period so that it is confused
as a level of hierarchy by the applications. The default character sting is _p_ but RC-DFT
uses __rcETdft_ to ensure it will not conflict with any other string in the model.
Result
When the run completes, ensure you see the "Circuit Statistics" in the log. Since the LBIST
structure (PRPG, MISR, and Channels) are all comprised of flops/latches, there is no
indication of these structures in this report; but you should see the number of flops/latches is
large enough to include these structures.
Ensure the end of the log; above the message summary, shows Flat Model Build Completed.
If you do not see this message, or if it shows as failed, look for ERROR or Severe WARNING
messages to determine the problem.
Look at the message summary at the end of the log. If there are any WARNING messages
that you do not understand, look up the message help and ensure there is no problem that
needs to be corrected.
For more information see Encounter Test: Guide 1: Models.

LBIST Flow
Build Parent (JTAG) Testmode

For this example, the Parent testmode is MODE_JTAG_RUNBIST. This testmode initializes the
design and makes the Test Data Register (JTAG TDR) scannable so it can be used to observe
the MISR through the TDO.
Command
build_testmode testmode=MODE_JTAG_RUNBIST modedef=MODE_JTAG_RUNBIST modedefpath=.
assignfile=./assignfile.JTAG.RUNBIST seqdef=./TBDseqPatt.JTAG_RUNBIST
The inputs for this command are:

The name you want for the testmode (MODE_JTAG_RUNBIST)
The mode definition file to identify the type of testmode being requested. In this case, the
name of the mode definition file and the name of the testmode are the same so the
modedef keyword does not need to be included on the command line but we included it
anyway. A sample of this mode definition file is shown in Figure 1-8.
The location of the mode definition file. This can be a path; a set of colon separated
directories. In this case, the mode definition file was in the same directory as the current
one when the command was executed, therefore, only a dot was added.
The assignfile identifies test functions of the JTAG pins, and the OPCG oscillator and
internal cutpoints / PPI's (pseudo-PI's). A sample assignfile is shown in Figure 1-9.
Clocks not needed for LBIST can be tied constant as they would be in the functional
mode of the design. Note that due to a restriction, currently all cutpoints needed in the
child testmode also need to be defined in the parent testmode and in the exact same
order.
The name of the file containing the testmode initialization and custom scan protocol
sequences. The mode initialization sequence does the following:
Setup default values for the JTAG pins
Wait for PLL(s) to lock
Once the PLL(s) are locked, let ET know to Pulse the PPI clock n times
Move the TAP to the Test-Logic-Reset State
Pulse the PPI so ET knows the internally generated clock is pulsed n times
Deassert the JTAG TRST but still remain in Test-Logic-Reset State
Move the TAP to Run-Test-Idle State

LBIST Flow
When you code your own mode initialization sequence for an 1149.1 testmode, you also
must code a custom scan protocol as the application cannot determine the correct scan
sequence for you. The scan protocol for this testmode will include two scan sections, one
each for LBIST and OPCG. The one for LBIST will be used to scan unload the MISR in
the child testmode. The one for OPCG will be used to program the OPCG. Refer to
Encounter Test: Reference: Test Pattern Formats for complete information on the
syntax for coding these sequences.
As a default tester description rule is used, there is no need to include the tdrpath.
Figure 1-8 Sample Parent (JTAG) Testmode Mode Definition
Tester_Description_Rule = dummy.tdr;/* use default tester description rule */

scan type = 1149.1
instruction=RUNBIST /* RUNBIST or SETBIST */
tap_tg_state = rti /* run-test-idle */
boundary = no /* no reduced pin count test */
in = PI /* input signals are from Primary Inputs */
out = PO ; /* output signals are to Primary Outputs */
Figure 1-9 Sample Parent (JTAG) Testmode Assign File
Result
You should see that there are two scan chains identified as "controllable and observable" in
the TTM-357 message. In this example, the OPCG scan chain was 14 bits and the LBIST
scan chain was 456 bits. If you do not see a TTM-357 message, or if the message only reports
one scan chain, there is a problem. See previous messages in the log. If you do not see any
problem, move on to the next step.

LBIST Flow
Report Parent (JTAG) Test Structures
Command
report_test_structures testmode=MODE_JTAG_RUNBIST reportscanchain=all
This command will report the details of the scan chains. You should have one complete scan
chain from TDI to TDO for each of the two scan sections. Therefore, you will see two complete
scan chains. If the scanchain is not complete, you may want to run
verify_test_structures testmode=MODE_JTAG_RUNBIST to enable the interactive
analysis of the broken scan chain(s).
Build Child (LBIST) Testmode

For this example, the child (or target) testmode is MODE_LBIST_RUNBIST. This is the
testmode that will be used to create LBIST tests. The testmode starts with the state from the
parent testmode initialization and establishes the LBIST structures so they are ready to be
used for LBIST simulation.
Command
build_testmode testmode=MODE_LBIST_RUNBIST modedef=MODE_LBIST_RUNBIST
modedefpath=. assignfile=./assignfile.LBIST.RUNBIST seqdef=./
TBDseqPatt.LBIST_RUNBIST
The inputs for this command are:

The name you want for the testmode (MODE_LBIST_RUNBIST).
The mode definition file to identify the type of testmode being requested. In this case, the
name of the mode definition file and the name of the testmode are the same so the
modedef keyword does not need to be included on the command line but we included it
anyway. A sample of this mode definition file is shown in Figure 1-10.
The location of the mode definition file. This can be a path; a set of colon separated
directories. In this case, the mode definition file was in the same directory as the current
directory when the command was executed, therefore, only a dot has been added.
The assignfile keyword identifies test functions of the LBIST pins, and the OPCG
oscillator and internal cutpoints / PPI's (pseudo-PI's). It also identifies the PRPGs and
MISRs. A sample assignfile is shown in Figure 1-11. Note that due to a restriction,
currently all cutpoints needed in the child testmode also need to be defined in the parent
testmode and in the exact same order.

LBIST Flow
The name of the file containing the testmode initialization and custom scan protocol
sequences. A sample of the mode initialization sequence is shown in Figure 1-12. Note
that the mode initialization sequence for this mode starts with the initialization of the
parent testmode. A sample of the custom scan sequence is shown in Figure 1-13. Refer
to Encounter Test: Reference: Test Pattern Formats for additional information on
sequence definition statements and syntax.
A default tester description rule is used so tdrpath need not be included.
Figure 1-10 Sample LBIST (Child) Testmode Mode Definition
Tester_Description_Rule = dummy.tdr;
scan type = gsd /* Standard scan design */
boundary=internal /* Internal boundary; reduced pin count test using JTAG */
in = on_board /* input signals are from on_board PRPG */
out = on_board; /* output signals are to on_board MISR */
/* Only logic signature tests or scan chain tests are allowed in this testmode */
/* The tests may be either static or dynamic, but dynamic tests are intended */
test_types dynamic logic signatures only shift_register;
/* Static and dynamic faults are to be included for this testmode */

faults static,dynamic;

LBIST Flow
Figure 1-11 Sample LBIST (Child) Testmode Assign File

LBIST Flow
Figure 1-12 Sample LBIST (Child) Testmode Initialization Sequence

LBIST Flow
Figure 1-13 Sample LBIST (Child) Testmode Scan Sequence
Result
You should see that your STUMPs channels are all identified as "controllable and observable"
in the TTM-357 message. If you do not see a TTM-357 message, or if the message does not
report the right number of scan chains, there is a problem. Check previous messages in the
log. If you do not see any problem, move to the next step that will provide additional
information about issues with the test structures.

LBIST Flow
Verify Child (LBIST) Test Structures
Command
report_test_structures testmode=MODE_LBIST_RUNBIST reportscanchain=all
reportprpgmisr=all
This command reports all the bits in the PRPGs and MISRs and all the bits in each scan chain
(the STUMPs channels). The report starts with a summary of the number of PRPGs, MISRs
and Scan Chains.
Command
verify_test_structures testmode=MODE_LBIST_RUNBIST
This command requests the default checks for the specified testmode; in this case, the default
checks for LBIST. These include the checks for clocking, scan chains, and X-sources. If the
results from build_testmode did not look correct, the messages from
verify_test_structures will usually give you more information about the problem.
Use interactive analysis to analyze any messages you do not understand. See Analyzing Test
Structure Problems in the Design in Encounter Test: Guide 3: Test Structures for
information on analyzing TSV messages that are generated by
verify_test_structures.
Results
If you have severe messages from verify_test_structures, ensure you understand

what they mean. Correct all the issues that could be a problem for your design:
Some problems may be corrected with changes to test mode input files (changes to
custom sequences or assign file settings).
Other problems may require a change to the netlist which requires going back to RC-DFT
or any other method you used to create the input.
Once you have corrected any problems and have a good testmode, you are ready to continue
to the next steps.
Build Faultmodel
If you are using LBIST for manufacturing test, or want to fault grade the LBIST for another
reason, you need to build the faultmodel. If you just want to simulate the LBIST and generate
the signatures without fault grading, then this step is not needed for LBIST.

LBIST Flow
Command
build_faultmodel
Results
At the end of the log, you see the global fault statistics and the fault statistics for each
testmode that is defined. At this point, there is no fault coverage since no test generation or
fault simulation has been done.
The global statistics are repeated to the right of the testmode statistics for each testmode,
these were eliminated from the example shown in Figure 1-14 below.
See Encounter Test: Guide 4: Faults for more information about faults, fault coverage, and
cross-mode markoff.

LBIST Flow
Figure 1-14 Sample Build Fault Model Log - Fault Statistics
Global Statistics
-- ATCov -- ---------- Global Faults -------------------

Global Total Tested Possibly Redundant Untested
Total Static 0.00 103852 0 0 0 103852
Collapsed Static 0.00 68016 0 0 0 68016
Total Dynamic 0.00 102333 0 0 0 102333
Collapsed Dynamic 0.00 82137 0 0 0 82137
Testmode Statistics: MODE_JTAG_RUNBIST

---- ATCov ---- ------------- Testmode Faults ------------
Testmode Global Total Tested Possibly Redundant Untested
Total Static 0.00 0.00 97143 0 0 0 97143

Collapsed Static 0.00 0.00 63932 0 0 0 63932
Total Dynamic 0.00 0.00 92363 0 0 0 92363

Collapsed Dynamic 0.00 0.00 74315 0 0 0 74315
Testmode Statistics: MODE_LBIST_RUNBIST
---- ATCov ---- ------------- Testmode Faults ------------

Testmode Global Total Tested Possibly Redundant Untested
Total Static 0.00 0.00 85936 0 0 0 85936

Collapsed Static 0.00 0.00 54307 0 0 0 54307
Total Dynamic 0.00 0.00 77898 0 0 0 77898

Collapsed Dynamic 0.00 0.00 59873 0 0 0 59873
INFO (TFM-704): Maximum Global Test Coverage Statistics:
%Active #Faults #Active #Inactive

Total Static 98.20 103907 102036 1871
Collapsed Static 98.06 68069 66747 1322
Total Dynamic 94.34 102333 96545 5788

Collapsed Dynamic 93.70 82137 76962 5175
Read LBIST Test Sequences

This step reads the test sequences you are going to simulate to generate signatures into the
Encounter Test database. You can read them in with a separate command, as shown here,
or by specifying sequencefile=<name of the file containing the

LBIST Flow
sequence> on the create_lbist_tests command line. The same application is used

to process the sequence in either case.
Command
read_sequence_definition testmode=MODE_LBIST_RUNBIST importfile=./
TestSequence.seq
importfile is the name of the file that contains the sequence to be processed. Figure 1-15
shows an example of the test sequence generated by RC-DFT that can be used as a template
if you are coding your own sequences. Notice that this is a dynamic (delay test) sequence
(see Pattern 1.2).
Figure 1-15 Sample LBIST Test Sequence

[ Define_Sequence Universal_Test (test);
[ Pattern 1.1 (pattern_type = static);
# Set Test Constraints to post-scan values
Event 1.1.1 Stim_PPI ():
"int_SE"=0
"int_capture"=1 ; ] Pattern ;
[ Pattern 1.2 (pattern_type = dynamic);

# First clock pulse
Event 1.2.1 Pulse_PPI ():
"i_core_sys_clk_domain.ppi"=-
"test_clk_domain.ppi"=- ;
# Second clock pulse
Event 1.2.1 Pulse_PPI ():
"i_core_sys_clk_domain.ppi"=-
"test_clk_domain.ppi"=- ; ] Pattern ;

Event 1.2.1 Pulse_PPI (): "scancaptck"=+ ; ] Pattern ;
[ Pattern 1.9; Event Channel_Scan (); ] Pattern 1.9;

] Define_Sequence Universal_Test ;
Create LBIST Tests

Depending on your goal for LBIST, you may or may not want to do fault simulation. Fault
simulation takes longer so if you are not going to use the result, it is better to simulate without
the faults (use good machine only simulation).

LBIST Flow
Command
create_lbist_tests testmode=MODE_LBIST_RUNBIST experiment=fault_par testsr=yes
testsequence=Universal_Test testvectorformat=dynamic simdynamic=yes
prpginitchannel=yes gmonly=no detectthresholdstatic=0 detectthresholddynamic=0
detectInterval=32 signatureInterval=32 maxseqpatterns=6400 maxpatterns=6400
forceparallelsim=yes reportmisrmastersignatures=yes
reportprpgmastersignatures=yes
The settings for this command are:

Name of the testmode to be processed is the LBIST testmode.
Experiment is a name you specify; it is used to name the results of this experiment
Indicate whether the LBIST scan chain (shift register) test is to be generated and
simulated. This example does not generate the scan chain test (testsr=no).
In general, it is recommended to execute scan chain tests in the LBIST hardware
(available in the LBIST macro inserted by RTL Compiler) and mark-off the scan faults
apriori using the command prepare_apriori_faults instead of using keyword
testsr=yes.
Name the test sequence to be used for generating the logic test signatures. Notice that
this is the name of the sequence and not the name of the file that was read into the
database in the previous test. Notice in Figure 1-15, the Define_Sequence Static_Test
(test); the name after Define_Sequence is the name of the test sequence.
Setting testvectorformat=dynamic would have been the default because the mode
definition called for dynamic tests. See the test_types statement in Figure 1-10.
The example initializes the STUMPs channels from the PRPGs; by default, the MISRs
will be blocked from updating while this is done.
gmonly=no is specified to do fault simulation; this is the default for the command. If you
want to do only good machine simulation, specify gmonly=yes.
The detection threshold for both static and dynamic are set to 0, which means the
simulation will not terminate due to detecting too few faults.
The detection interval is how often the application checks to see if the detection threshold
has been reached. So, every 32 patterns, it will check to see if there are fewer faults
detected than specified in the threshold.
The signature interval indicates that the signature is to be calculated every 32 patterns.
maxseqpatterns indicates that 6400 patterns are to be generated for each test sequence
specified. The maxpatterns indicates that 6400 patterns are to be generated for the
experiment. As there is only one testsequence specified, either keyword by itself would
have been sufficient; but if there were multiple testsequences, you might, for example,

LBIST Flow
want to specify maxseqpatterns=3200 and maxpatterns=6400 so that each

sequence would be used for half of the total number of patterns.
create_lbist_tests determines whether parallel simulation can be done by default
and will use parallel simulation if possible. If the sequence analysis portion of the code
determines that parallel simulation should not be done, you can force it with
forceparallelsim=yes. However, if your sequence does not match the criteria for
parallel simulation, you may get a message indicating that extraprpgcycles and/or
extramisrcycles need to be specified. If you get that message, you need to rerun with
those keywords specified.
There are several reports that can be printed in the log. We selected to report the MISR and
PRPG signatures. The initial values in the MISR and PRPG (cycle 0) and the signatures every
detect interval (every 32 cycles) are printed.
Results
At the end of the log, you see the final LBIST statistics as shown in Figure 1-16. You see in
this experiment, the scan chain test was simulated (32 cycles) and the static and dynamic
coverage is shown. The logic tests (using Static_Test sequence) was simulated (6400
cycles) and the resulting static and dynamic coverage is shown. These results are totaled to
show that there were 6432 patterns generated, of those 1999 were effective (resulted in faults
being tested) and the final coverage is 96.78% static and 85.43% dynamic. The number of
faults detected is shown in the parentheses.
Throughout the log you see indications of the signature after the scan at the end of every 32
cycles. These look like what is shown in Figure 1-17.

LBIST Flow
Figure 1-16 Sample LBIST Statistics from Create LBIST Tests
-----------------------------------------------------------------------
LBIST Statistics
-----------------------------------------------------------------------
Scan Chain Test Results

Patterns simulated : 32
Effective patterns : 32
Static fault coverage (DC) : 33.7554%
Dynamic fault coverage (AC) : 31.1215%
Logic Test Results

Patterns simulated : 6400
Effective patterns : 1967
Result Summary
Total patterns simulated : 6432
Total effective patterns : 1999
Simple faults : 150220 ( 83672 dc + 66548 ac )

Pattern faults : 0 ( 0 dc + 0 ac )
Total faults : 150220 ( 83672 dc + 66548 ac )
Figure 1-17 Sample LBIST Signatures from Create LBIST Tests
Cycle <0> Product MISR <1> After-Scan Signature (master) : 0000000000000000

Cycle <0> Product PRPG <1> After-Scan Signature (master) : bb7ffffffffff000
Cycle <32> Product MISR <1> After-Scan Signature (master) : b4b29a352ab09000
Cycle <32> Product MISR <2> After-Scan Signature (master) : 7f983b6ad457f000
Cycle <32> Product MISR <3> After-Scan Signature (master) : 2e7b7483aef07000
Cycle <32> Product MISR <4> After-Scan Signature (master) : 156f8642
Cycle <32> Product PRPG <1> After-Scan Signature (master) : 64d8841dc2f53000
. . .
Cycle <6400> Product MISR <1> After-Scan Signature (master) : 15c5705e5f46a800
Cycle <6400> Product MISR <2> After-Scan Signature (master) : 92ffbabd505ef000
Cycle <6400> Product MISR <3> After-Scan Signature (master) : 4e4d2b90df902000
Cycle <6400> Product MISR <4> After-Scan Signature (master) : 1d22cd9a
Cycle <6400> Product PRPG <1> After-Scan Signature (master) : c281f78735cbf000

LBIST Flow
Write LBIST Vectors
Command
write_vectors testmode=MODE_LBIST_RUNBIST inexperiment=fault_par
combinesections=all
inexperiment is the experiment name you specified on the create_lbist_tests

command line. Keyword combinesections needs to be specified with value all for all
LBIST designs. This way, all vectors are written in the same pattern file and simulated at one
go so that all different patterns of an experiment can be accumulated into a single final MISR
signature. Note that the keyword testrange has been disabled in LBIST designs to prevent
writing out invalid pattern ranges.
Results
The resulting verilog vectors are stored in the testresults/verilog directory. For this
experiment, there were three files:
VER.MODE_LBIST_RUNBIST.fault_par.mainsim.v - the mainsim file contains
structural information and the task definitions.
VER.MODE_LBIST_RUNBIST.fault_par.data.verilog - this is the vector file for
the LBIST tests.
cycleMap.MODE_LBIST_RUNBIST.fault_par - this is the cycle map file (Creating
cycle Map for Output Vectors in Encounter Test: Guide 6: Test Vectors for a
description of the content of this file.)
See Verilog Pattern Data Format in Encounter Test: Reference: Test Pattern Formats for
complete information about the Verilog output. Note, in particular, the information in section
LBIST Test Types.
Commit LBIST Tests

There is no need to commit the LBIST tests unless you are using them for manufacturing test,
in which case you will want to commit them before running ATPG so that ATPG will not have
to generate tests for the faults that are already marked off by the LBIST simulation.
Command
commit_tests testmode=MODE_LBIST_RUNBIST inexperiment=fault_par

LBIST Flow
inexperiment is the experiment name you specified on the create_lbist_tests

command line.
If you have Severe Warnings from verify_test_structures that you are ignoring
because you know the operation of the design is correct, you will need to specify force=yes
on the commit_tests command line to have the tests committed.
Results
Commit concatenates the vectors from the experiment to the end of the master vectors for
the testmode; if there are no master vectors yet, it creates the master from this experiment.
If the vectors have fault status associated with them, as they do in this example, it marks the
master faultStatus with the results from this experiment.
In the log, commit_tests prints the fault statistics before and after the patterns are
committed so you can see the effect of committing this set of patterns on the fault coverage.
It reports the global and testmode statistics for Total Static and Total Dynamic in the same
format as shown in the log from build_faultmodel (see Figure 1-18).
The log also reports the statistics for the master test vectors after the experiment has been
committed. The statistics from this example are shown in Figure 1-18. Note that only one
experiment was committed in this example. The two test sections are the one for the scan
chain test and the one for the logic test. The init sequence is the mode initialization sequence
from build_testmode that is included at the beginning of each set of tests. The setup
sequence is where MISRs were blocked and channels were initialized from the PRPGs which
is done before each test (scan and logic).
The tester loops and test procedures are constructs in the patterns; there is a tester loop for
each test section and there is a test procedure for each sequence (init and test). See
Encounter Test: Reference: Test Pattern Formats for more information about the Encounter
Test vector format (TBDpatt).
Figure 1-18 Sample LBIST Committed Master Test Vector File Statistics
INFO (TBD-809): Master test vector file statistics: [end TBD_809]

experiments = 1
test sections = 2
tester loops = 2
test procedures = 4
test sequence = 2
init sequencess = 2
setup sequences = 2

LBIST Flow
Debugging LBIST Structures

To ensure correct implementation of LBIST, it is a common practice to simulate the LBIST
controller and verify that the control signals for scanning and clocking are produced in the
proper sequence. However, if the LBIST controller has been automatically inserted by
Encounter RTL Compiler, you may consider this to be unnecessary. Regardless of the origin
of the LBIST controller design and its level of integrity, other things may go wrong in the LBIST
process. For example, some system clocks may be incorrectly generated or incorrectly wired
to their associated memory elements.
Encounter Test's Verify Test Structures tool is designed to identify many such design
problems so they can be eliminated before proceeding to test generation. Even so, it is
advisable to use your logic simulator of choice to simulate the LBIST operation on your design
for at least a few test iterations (patterns) and compare the resulting signature with the
signature produced by Encounter Test's Logic Built-In Self Test generation tool for the same
number of test iterations. This simulation, along with the checking offered by Encounter Test
tools, provides high confidence that the signature is correct and that the test coverage
obtained from Encounter Test's fault simulator (if used) is valid.
When the signatures from a functional logic simulator and Encounter Test's LBIST tool do not
match, the reason will not be apparent. It can be tedious and technically challenging to
identify the corrective action required. The problem may be in the LBIST logic, its
interconnection with the user logic, or in the Encounter Test controls. The purpose of this
section is to explain the use of signature debug features provided with Encounter Test's Logic
Built-In Self Test generation tool.
Signature Mismatch
It is not necessary to run the full number of test iterations to attain a high confidence that your
LBIST design is implemented properly and Encounter Test is processing it correctly. In fact,
the functional logic simulation run, against which you will compare Encounter Test's
signature, might be prohibitively expensive if you were to compare the final signatures after
several thousand test iterations. It is recommended that you run a few hundred or a few
thousand test iterations, or whatever amount is feasible with your functional logic simulator.
Submit a Logic Built-In Self Test generation run, specifying the chosen number of test
iterations (called patterns in the control parameters for the tool). You will need to obtain the
MISR signatures; this can be done in any of three ways:
1. Request scope data from the test generation run: simulation=gp
watchpatterns=range watchnets=misrnetlist where range is one of the valid
watchpatterns options and misrnetlist is any valid watchnets option that
includes all the MISR positions.

LBIST Flow
2. Specify reportmisrsignatures=yes in the test generation run, or

3. After the test generation run, export the test data and look at the TBDpatt file.
In the first method, you will use View Vectors to look at the test generation results as signal
waveforms. Refer to Test Data Display in the Encounter Test: Reference: GUI for details
on viewing signal waveforms. This may seem the most natural if you are used to this common
technique for debugging logic. However, you may find it more convenient to have the MISR
states in the form of bit strings when comparing the results with your functional logic
simulator.
In both cases, MISR signatures are produced at every detection interval. Signatures
are printed in hexadecimal, and are read from left to right. The leftmost bit in the signature is
the state of MISR register position 1. (The direction of the MISR shift is from low- to high-
numbered bits with feedback from the high-numbered bit(s) to the low-numbered bits.)
Signatures are padded on the right with zeroes to a four-byte boundary, so there are trailing
zeroes in most signatures which should be ignored.
The MISR latch values found in the signatures are manually compared with the results of the
functional logic simulator, often by reading a timing chart.
Debugging Tips for LBIST Signature Mismatches
The following procedure is suggested to investigate signature mismatch problems.
The reportlatches keyword is useful in signature debugging. The keyword prints

signature and latch information to the tbdata/signatureDebug file for the specified range
of test iterations. This file can be used for debugging signature miscompares between
Encounter Test and other simulation tools. The data in the file is written in a way that is easily
parsed and processed by a scripting language. The keyword has following definition:
Syntax: [reportlatches=<integerRange>]
Where: integerRange is (n:m,n:,:m,:,n)
There is no default.
Specify a range using integers as follows:

n:m - specifies test iteration sequences n (start of range) through m (end of range)
n: - specifies test iteration sequences starting at n through maxseqpatterns (maximum
range)
:m - specifies test iteration sequences starting at 1 through m

LBIST Flow
: - specifies test iteration sequences starting at 1 through maxseqpatterns

n - reports all channel and MISR latch values for each scan cycle in the specified
iteration

2
OPCG Flow

Introduction
Processing OPCG Logic Designs
Unique Encounter Test Tasks for OPCG
Introduction
On Product Clock Generation (OPCG) refers to complex logic that generates or modifies
clock signals internal to the product. This logic generally is not able to be accurately defined
using the gate level primitives that are required for test generation and fault simulation.
The goal for Encounter Test processing is to identify the internal clock signals and hide the
clock generation logic. The nets at the output of the clock generation logic are symbolically
cut so the logic feeding them becomes inactive. The "cut" nets are called cutpoints. The
cutpoints are connected to inputs that the test generators/simulators can control called
pseudo primary inputs (PPIs). Multiple cutpoints can be connected to a single PPI if the
behavior of those internal signals is the same or simply out of phase with one another. See
additional information in the TestMode section.

OPCG Flow
Figure 2-1 OPCG Logic
Figure 2-1 depicts the basic concept. The oscillator and go signal are defined for the tester
and the PLL and clock generation logic on the design generate the clock signal on the output
of the clock generator. The cutpoint removes all that logic from consideration by Encounter
Test test generation and simulation. A pseudo primary input (PPI) is defined as a clock and
connected to the cutpoint net. Test generation and simulation will treat the PPI as a primary
input to test the downstream logic.
The on-product clock generation (OPCG) feature in Encounter Test allows you to generate at-
speed tests using the OPCG circuitry built into the design. This is required where the tester
cannot generate the clocks at the desired speeds. Encounter Test implements OPCG by
defining cutpoints and assigning pseudo primary inputs (PPIs) to the internal clock domains.
The test generator then uses those internal PPIs as the launch and capture clocks in the
design. Encounter Test supports custom OPCG logic that you define and for which you must
provide all the information on how the clocking sequences are produced and their definition.
It also supports a standard set of OPCG logic that can be inserted by Encounter RTL
Compiler and for which sequences can be automatically generated.

OPCG Flow
Processing OPCG Logic Designs
Processing Standard, Cadence Inserted OPCG Logic Designs

When Cadence-defined OPCG logic is inserted using Encounter RTL Compiler, most of the
complex input for Encounter Test is automatically generated, thus easing the process of
generating OPCG tests.
RTL Compiler creates the pin assign file that defines the cutpoints and the OPCG logic to
Encounter Test; you still need to create the mode initialization sequence to correctly program
any PLLs that will be used for OPCG testing.
The RTL Compiler also generates a run script that automates the various steps of Encounter
Test to produce the test vectors.
Creating Test Vectors Using RC Run Script
When using the OPCG logic inserted by RTL Compiler, you can provide the mode
initialization sequence as input to the write_et_atpg command in RC. This generates an
RC run script named runet.atpg, which automates the various steps of Encounter Test to
produce the test patterns. The script processes the OPCG and non-OPCG test modes. For
the OPCG test modes, it runs the prepare_opcg_test_sequences command that
automatically generates intradomain delay tests to be used by ATPG. It can also generate
static ATPG tests, if desired. You can modify the script to generate inter-domain tests if you
have included delay counters in the OPCG logic.
The following figure depicts the tasks required to create the test patterns using the RC run
script:

OPCG Flow
Figure 2-2 Creating True-time Vectors Using RC Run Script
Insert the OPCG logic using RC Refer to Inserting On-Product Clock

Generation Logic in the Design for Test in
Encounter RTL Compiler Guide
Code PLL mode initialization sequence This initializes the PLLs and starts the
using RC template reference oscillators to be used for the test.
Use RC command define_dft opcg_mode to define This specifies the PLL Mode Initialization
the OPCG Mode sequence.
This generates all files needed to run Encounter

Use RC command write_et_atpg to generate files Test and also generates the run script,
for ATPG and Simulation runet.atpg
Optionally modify the run script, runet.atpg to For example, if you inserted delay counters in
customize it for the desired output OPCG domains and want to apply interdomain
tests, add interdomain=yes to the invocation of
the prepare_opcg_test_sequences
command line in the script
Run the runet.atpg script to generate tests with

Encounter Test
Creating Test Patterns without RC Run Script
The following figure depicts the tasks required to generate test sequences using Cadence
inserted, standard OPCG logic without using the run script generated by RTL Compiler:

OPCG Flow
Figure 2-3 Creating True-time Patterns using RTL Compiler Inserted OPCG Logic
Refer to the flow covered in the preceding

Insert OPCG Logic with RC and run all RC section
tasks to generate files for ATPG and
simulation
Run build_testmode command Use the pin assign file and

modeinitialization from RTL Compiler
Run create_scanchain_delay_tests command
Run commit_tests command
This creates valid test clocking

sequences and the setup sequences that
Run prepare_opcg_test_sequences command
correctly program the OPCG logic to
produce such tests. You can request
intradomain (default), inter - domain and
static test sequences
Run create_logic_delay_tests command using the
test sequences from the previous task
Run commit_tests command to get fault accounting

credit accumulated for all committed tests
Specify any static ATPG test sequences

generated previously. These should top
Run create_logic_tests command off the static fault coverage by targeting
those static faults not detected by the
generated delay tests.
Run write_vectors command

OPCG Flow
Processing Custom OPCG Logic Designs

For custom OPCG logic, you need to design the OPCG logic, define it to Encounter Test when
building the test mode and provide a custom test mode initialization sequence that will
program any PLLs in use and start any reference oscillators. You will also need to define the
test sequences that can be applied by the OPCG logic. The test sequences include all activity
(pulses) at the domain clock root PPIs as well as activity at the real primary inputs that cause
the PPIs to behave that way (for example, changing the value of a trigger signal primary input
pin that launches the OPCG activity). When the OPCG logic is programmable, test
sequences may be defined that include the use of a setup sequence. A setup sequence
defines how to load the programming logic into the OPCG state elements prior to using the
programming to produce the desired sequence of internal domain clock pulses. If the OPCG
programming bits are static once they are loaded, the programming is applied through the
setup sequence only once for a set of test sequences to be applied to the device. If the OPCG
programming bits are part of the normal scan chains, they must be reloaded as part of the
scan_load data for each test.
The following figure shows the tasks required to use custom OPCG logic within a design.

OPCG Flow
Figure 2-4 Creating True-time Vectors using Custom OPCG Logic
Include custom OPCG logic

Run build_model command
This is done by defining cutpoints and

Define an OPCG assignment file PPIs and/or using the OPCG statement in
the mode definition file or pin assign file
This sets the design to the correct starting

state, programs any PLLs to be used and,
Define an OPCG test mode initialization starts any reference oscillators that are used
sequence in Encounter Test TBDseqPatt format to run the PPLs. It is recommended that
PLLs be run until they lock before exiting the
mode initialization sequence
Specify the assign file defined and the

Run build_testmode command mode initialization file defined previously
Run create_scanchain_delay_tests command
Run commit_tests command
Any defined test sequence should

Define OPCG test sequences specify the setup sequence it uses to
program the OPCG logic to produce the
sequence of PPI pulses shown in the
test sequence.
This reads your custom OPCG test

Run read_sequence_definition command sequences into the tbdata and verifies
that they are syntactically correct.

OPCG Flow
Run create_logic_delay_tests command using Specify the list of test sequences to be

the test sequence from the previous task used for targeting faults.
Run commit_tests command to get fault accounting

credit accumulated for all committed tests
Specify any static ATPG test sequences

generated previously. These should top
Run create_logic_tests command off the static fault coverage by targeting
those static faults not detected by the
generated delay tests.
Run write_vectors command
OPCG logic usually requires a special initialization sequence and sometimes requires special
test sequences for issuing functional capture clocks during application of the ATPG patterns.
This example creates special test sequences for initializing the chip and for launching the
functional capture clock.
Note that as each design is unique, customized designs require different settings and
sequences.
Two functional clock pulses are issued from the OPCG logic. The first clock launches the
transition and the second clock captures the logic output in a downstream flip-flop.
The pin assignment file defines the following:

Clock, scan enable, and other control pins. These are the standard set of pins that must
be controlled during application of the ATPG patterns.
An internal cutpoint and associated reference name, and also assigns the appropriate
test function to this PPI.
The input reference oscillator pin and an enable pin for the on-chip PLL.
In addition, there should be an OPCG statement in either the mode definition file or the pin
assign file. The OPCG statement block allows specifying the PLLs to be used, the reference
clocks that are used to drive them, and the programming registers that are available to
program them. It also allows specifying each OPCG clock domain, the PLL output that drives

OPCG Flow
the domain, and programming registers that are available for the domain. Refer to OPCG in
the Encounter Test: Guide 2: Testmodes for more information on the OPCG statement
syntax.
The initialization sequence defines the launch-capture timing within the OPCG logic and waits
10,000 cycles for the PLL to lock.
The test application sequence defines the sequence of events required to get the OPCG logic
to issue the desired launch and capture clock pulses.
Unique Encounter Test Tasks for OPCG
Creating OPCG Testmode
OPC vs. Inactive Logic
When you define cut points, Encounter Test treats those nets as though they were primary
inputs. Thus, as far as Encounter Test programs are concerned, the logic that actually feeds
cut point nets is inactive. While Encounter Test treats this logic as inactive and unobservable,
it is, in truth, observable. This logic is therefore placed in a category called OPC logic (for
On-Product Clock or Control). OPC logic is defined as any inactive logic that is in the back
trace from a cut point, plus any TG constraint logic that is fed only by primary inputs that fall
within the classification of OPC logic. The relationship of OPC logic and inactive logic is
shown in Figure Figure 2-5 on page 72.

OPCG Flow
Figure 2-5 OPC and Inactive Logic in a Simple Design with a Cut Point
In Figure 2-5, the net connecting blocks K and N is identified as a cut point. There are two
constraint blocks which by their nature are left dangling. So the nodes labeled A, B, C, F, H,
I, and M are treated as inactive by Encounter Test. Nodes A, B, C, F, H, and I are identified
as OPC logic. Note that if the cut point did not exist, then only the constraint blocks H and M
would have been inactive, and there would be no OPC logic.
Use the following procedure to configure an OPCG test mode and perform ATPG.
1. Identifying cut point locations and how they are grouped into PPIs.
2. Specify the Go signals, which are required for OPCG logic. They are allowed to be
specified on PIs and PPIs.
Note: The Go signal represents the external or internal event that starts the OPCG
clocking.
3. Create a customized mode initialization sequence to ensure that PLLs are properly
initialized and locked on the input oscillators. Refer to Mode Initialization Sequences
(Advanced) in Encounter Test: Guide 2: Testmodes for more information.
4. Define test sequences, each with an associated setup sequence. The setup sequence
must include a Load_OPCG_Controls event that specifies values to be loaded into any
or all of the defined OPCG registers.
Note: Step #4 is optional for PLL registers.
Refer to OPCG testmode definition syntax in Encounter Test: Guide 2: Testmodes.

OPCG Flow
Creating an OPCG Pin Assignment File

This section describes control pins and how they affect the operation of a design.
Understanding the TBDpatt data in this example requires knowledge of how the design
operates.
build_testmode assignfile=<this file name> testmode=FULLSCAN_TIMED
In the OPCG pin assignment file, you will see the scan control and clock information:
-SCA system clock that is inactive in logic 0 state
+TIAn input signal that must always be at logic 1
+TCAn input signal that must be at logic 1 when the functional capture clock is applied.
In other words, when creating test patterns, ATPG must assume that this input is always
at logic 1.
-SEA scan enable signal that is 0 during scan shift mode
SIx and SOxThe scan in and scan out ports
-ESA clock used for scan only
.......
For this OPCG example, you will also see the following:
cutpoint - The clock output of the OPCG logic. This cutpoint has been named as
PLL_CLK and the "+" sign means there is no inversion.
PPI - The cutpoint is now treated as a real input pin. You can assign any test function to
it. For the sample design it is a clock with a safe state of 0 (-SC).
PLL_IN - IF the OPCG logic has an internal PLL then almost always there is a reference
input oscillator. The sample OPCG has an internal PLL and the input reference signal is
flagged as an oscillator here. Logic 0 is its safe state.
PLL_EN - If the design has an enable signal for the PLL, you can flag this input with the
GO test function. A "+" sign designates that logic 1 is when the PLL is enabled. Note that
if you do not flag this, there is no error but if you do not specify how to control it, Encounter
Test generates errors.
When AT_SPEED=0 as in the example, the scan shift clock (scan_clk) coming from the tester
is selected and is therefore flagged with -SE. For at-speed purposes the functional launch and
capture clocks come from the OPCG, therefore, AT_SPEED=1 is required. That is why
AT_SPEED is also flagged with +TC.

OPCG Flow
In the sample design the OD0 and OD1 pins enable selecting four different launch-capture
times. The design may or may not allow configuring different clock speeds.
cutpoints DTMF_INST.CLK_GEN_I.AT_SPEED_CLK +PLL_CLK;
assign PPI=PLL_CLK test_function= -SC;
assign pin=AT_SPEED test_function= -SE +TC;
assign pin=test_mode test_function= +TI;
assign pin=OD0 test_function= +TI;
assign pin=OD1 test_function= -TI;
assign pin=reset test_function= -SC;
assign pin=spi_fs test_function= -SC;
assign pin=scan_en test_function= +SE;
assign pin=scan_clk test_function= -ES;
assign pin=scan_in[0] test_function= SI0;
assign pin=scan_out[0] test_function= SO0;
assign pin=scan_in[1] test_function= SI1;
assign pin=scan_out[1] test_function= SO1;
assign pin=PLL_IN test_function= -OSC;
assign pin=PLL_EN test_function= +GO;
Building Test Mode Initialization Sequence Input File

The TBDpatt initialization sequence is required to initialize the OPCG logic. Another reason
to have an initialization sequence is if the design has IEEE 1149.1 (JTAG Boundary) logic that
must be initialized so it does not interfere with the application of the scan based test patterns.
Build the test mode using the following command:
build_testmode seqpath=<path> seqdef=<this file name>testmode=FULLSCAN_TIMED
The following is the code for the TBDpatt initialization file:

# Do NOT worry about the Pattern and Event numbering (1.1, 1.1.1, etc.)
# - These number entries are optional.
# Copy the boiler plate structure down to the Event statement.
# The "(modeinit)" entry tells Encounter Test this is a special
# test mode initialization sequence.
[ Define_Sequence Mode_Initialization_Sequence 1 (modeinit);
Event 1.1.1 Stim_PI ():
"OD0"=1
"OD1"=0
"AT_SPEED"=1
"PLL_EN"=1
"reset"=0
"scan_clk"=0
"scan_en"=1
"spi_fs"=0
"test_mode"=1 ;
Event 1.1.2
Start_Osc (pulses_per_cycle=1,up 40.00 ns): "PLL_IN"=+;
Event 1.1.3 Stim_PPI ():
"PLL_CLK"=0 ;
] Pattern 1.1;
Event 2.1.1
Wait_Osc (cycles=10000,off): "PLL_IN";

OPCG Flow
] Pattern 2.1;
] Define_Sequence Mode_Initialization_Sequence 1;
For test mode initialization, this example sets the inputs and wait for 10,000 cycles for the PLL
to lock, as shown in Figure Figure 2-6 on page 75.
Figure 2-6 Test Mode Initialization
More information on inserting OPCG logic is available in the Design For Test in Encounter
RTL Compiler, Inserting On-Product Clock Generation Logic.
OPCG Test Sequences

Test sequences are used by designs that require specialized sequences that:
wouldn't be created by ATPG (such as sequences requiring special ordering of stim
events.
account for on-chip clock generation logic where the hardware tester starts an oscillator
and the clocks are generated on product. The oscillator events are put into the sequence
for the tester and the PPI events are put in for ATPG.
The following example illustrates a special sequence to get OPCG logic to issue the true-time
delay test launch and capture clocks.

OPCG Flow
read_sequence_definition testmode=FULLSCAN_TIMED importfile=TBDseqPatt_filename

create_logic_delay_tests testsequence=opcg_sys_capture testmode=FULLSCAN_TIMED
Following is a sample of the content of the TBDseqPatt_filename identified as the

importfile in the read_sequence_definition command above:
Note: In the example:
mode=node indicates any pins or flops/latches to be included in Stim or Scan_Load
Events are listed individually rather than as a vector.
model_entity_form=name indicates the pins, flops or latches are identified by name
rather than index.
the Define_Sequence name is referenced with the testsequence keyword (notice
the value for testsequence in the create_logic_delay_tests command above
matches the Define_Sequence name below). Several different test sequences may
be defined within a single TBDseqPatt file.
although this is an example of a test sequence for delay test, most of the patterns
are static; only the pattern with the release and capture clocks is dynamic and is
identified as such with pattern_type = dynamic.
TBDpatt_Format(mode=node,model_entity_form=name);
[ Define_Sequence opcg_sys_capture (test);
# This is the scan load event.
# The sequence for scanning comes from build_testmode
[ Pattern (pattern_type = static );
Event Scan_Load():;
] Pattern;
# In this next section, we wait for the scan enable signal to settle.
# Oscillator events are ignored by ATPG and simulation. They are included as
directions to the tester.
Event Wait_Osc (cycles=10): "PLL_IN";
] Pattern;
# Now that weve done the scan load and have set up our oscillator
# we now go through the sequence of events that will get the OPCG logic
# to generate a launch and capture clock. PLL_EN is the signal that
# controls this operation. When we set it to logic 1 the OPCG logic will issue the
# clocks. This signal would be assigned +GO.
# Stim_PI_Plus_Random tells Encounter Test to apply an explicit
# value to PLL_EN and to apply the ATPG pattern specific values
# to all of the other pins. Do not use TG=IGNORE here.
Event Stim_PI_Plus_Random(): "PLL_EN"=1;
] Pattern;
# The Wait_Osc command synchronizes other events with the
# tester supplied input reference clock.
# Stim_PI starts the state machine by lowering the PLL_EN signal. ATG=IGNORE is
# included so the test generator ignores the pattern. The simulator wiill use the
# stim_PIevent
[Keyed_Data; TG=IGNORE ] Keyed_Data ;
Event Wait_Osc (cycles=0): "PLL_IN";

OPCG Flow
Event Stim_PI(): "PLL_EN"=0;

] Pattern;
# This tells Encounter Test that, after you have exercised the
# pattern sequence above, the OPCG logic will issue a
# launch/release and capture pulse at the PPI (cutpoint)
# NOTE: This is a "trust me" situation. There is no way
# Encounter Test (or any other ATPG tool) can really
# verify that a double clock pulse was issued OR what
# the timing of these pulses is.
[ Pattern (pattern_type = dynamic) ;
Event Pulse_PPI(timed_type=release): "PLL_CLK"=+ ;
Event Pulse_PPI(timed_type=capture): "PLL_CLK"=+ ;
] Pattern;
# This Wait_Osc event defines how many PLL_IN
# clocks to issue before continuing on to
# the next sequence of events.
# For our design these 10 cycles allow the state machine
# within the OPCG logic to reset.
[Keyed_Data; TG=IGNORE ] Keyed_Data ;
Event Wait_Osc (cycles=10,off): "PLL_IN";
Event Stim_PI(): "PLL_EN"=1;
] Pattern;
# This is a standard scan unload event.
# [ Pattern (pattern_type = static );
Event Scan_Unload():;
] Pattern;
] Define_Sequence opcg_sys_capture ;
The following figure represents a scan shift when scan_en=1 and AT_SPEED=0.

OPCG Flow
Figure 2-7 OPCG Scan Shift
Note: This is a broadside load Verilog simulation and, therefore, there is only one scan shift
clock (scan_clk) to load the data. No additional application sequence is required to enter or
exit scan shift mode. All necessary data for this was provided in the pin assignment file.
The following figure shows a special sequence to have OPCG issue at-speed delay test
clocks. For the sample design, the OPCG logic will issue the launch and capture pulse when
PLL_EN goes to 0. Note that AT_SPEED=1 and this selects the OPCG output as the clock
source.

OPCG Flow
Figure 2-8 Sequence with OPCG Issuing At-speed Delay Test Clocks

OPCG Flow

3
Low Power Flow

Introduction
Encounter Test Low Power Flow
Introduction
The following terms are commonly used in reference to low power:
Power Mode The static state of the design established by the power status
(on or off) of each power domain.
Power Domain The collection of logic blocks that are connected to the same
unique power supply.
CPF Common Power Format. Refer to Low Power in Encounter
RTL Compiler and the RTL Compiler Common Power
Format Language Reference for additional information.
UPF Unified Power Format. Refer to Low Power in Encounter RTL
Compiler and the RTL Compiler Common Power Format
Language Reference for additional information.
The Encounter Test low power methodology features the following:

The prepare_cpf_data command for CPF file and read_power_intent for UPF file
read the power intent and correlate it with the Encounter Test model.
Downstream commands that require power information access the CPF or UPF/1801
database generated by the prepare_cpf_data or read_power_intent command.
Reporting of faults and fault statistics for low power components.

Low Power Flow
Optional preparation of a low power component fault subset. The test is generated
against this subset targeting only the low power components; the
create_scanchain_tests and create_logic_tests commands generate low
power test. These test results are typically used for analysis and verification.
Analysis of test patterns by using the write_toggle_gram command
Generation of Retention Test. Refer to Creating Retention Tests in Encounter Test:
guide 5: ATPG for details.

Low Power Flow
Managing Power Consumption During Test

Figure 3-1 illustrates a use model flow for managing power in a design when producing test
patterns.
Figure 3-1 Low Power Consumption Use Model Flow
RTL Netlist
RTL Compiler-DFT
CPF or UPF/1801
Synthesized Netlist
Encounter Test
Structural
Verilog
Test Vectors
Test Vectors
Experiment
Write Toggle Gram
Flop-based
Toggle Count File Current data files
Estimated power
static/dynamic -switching
Power Meter -leaking
Voltage Storm
dynamic IR Drop Plot
Electromigration

Low Power Flow
The methodology described above utilizes the following:

The DFT features of RTL Compiler
Encounter Test to generate power aware ATPG patterns for high quality testing at the
ATE
The capability of Voltage Storm to analyze patterns generated by Encounter Test
The result is a verifiable flow for test patterns to eliminate tester failure due to excessive power
consumption.
Preparing a Netlist for Low Power Test Generation

Figure 3-2 depicts the flow to produce a netlist with low power structures.
Figure 3-2 Low Power Logic Model Flow
RTL Compiler / DFT

RTL Netlist
Insert DFT Boundary Scan
CPF or UPF/1801 optional step

Insert DFT MBIST
Insert DFT Scan power Gating required step
recommended
Insert DFT PTAM
Insert Scan Chains
Encounter Test
Build Test Model
Use the DFT features of RTL Compiler to prepare the netlist for maximum flexibility during
test. Process an RTL level netlist by using the Common Power Format (CPF) or Unified Power
Format (UPF) to insert Power Test Access Mechanism (PTAM) logic and Power Aware Scan

Low Power Flow
Chain capability. Use the prepared netlist as input to the Encounter Test flow to build the test
model on which ATPG runs.
Tip
Inserting PTAM logic is highly recommended for increased low power test flexibility.
Refer to the following topics in Design for Test in Encounter RTL Compiler for additional
information:
Inserting Boundary Scan Logic
Inserting Memory Built-In-Self-Test Logic
Inserting Flop Gates to Reduce Power
Inserting Power Test Access Mechanism (PTAM) Logic
Controlling Scan Configuration
Encounter Test Low Power Flow

Figure 3-3 on page 86 illustrates the Encounter Test low power flow.

Low Power Flow
Figure 3-3 Encounter Test Low Power Use Model
Start
optional step
Synthesized
Netlist
Build Model
Structural required step
Verilog
Read_Power_Intent
or contrib dir
CPF or Prepare CPF Data
UPF/1801
Build Test Modes
Build Fault Model
Verify Test Structures
Report Test Structures
No Power Yes
Create ATPG Component create_lp_tests
(PC) Testing
No
Analysis Analysis
Report PC Fault
Report PC Fault Acceptable
Statistics
Statistics PC Coverage
Write Toggle Gram Yes
Yes
Exceeding No Top-off No Another

Limits patterns test mode
Yes No
Yes
Write Vectors
Delete
Delete Regenerate
Sequences or End
Regenerate
Patterns
Delete Sequence
Range
Resimulate

Low Power Flow
The Encounter Test low power methodology is integrated into the standard ATPG use model
flow; however, it utilizes power definitions contained in the CPF or UPF/1801 file. The
following descriptions highlight the low power related tasks within the ATPG use model.
As shown in Figure 3-3 on page 86, the prepare_cpf_data command reads the CPF
information and the read_power_intent command reads the UPF/1801 information, from
both library and design definitions, parses the CPF or UPF/1801 file, and populates the
Encounter Test CPF or UPF/1801 database. Encounter Test applications that run later
automatically use this database when needed, without the requirement to explicitly specify a
CPF or UPF/1801 file.
The CPF or UPF/1801 data is first used in the Build Test Modes task. One approach to
solving the low power issue during test is to partition the design from a power perspective by
using the functional power modes defined in the CPF or UPF/1801 file. To leverage this
approach, selected power modes are mapped to a test mode. The following criterion is used
to select the power modes:
The power modes must have a representation of each switchable power domain that is
in an on and off state across the selected set of test modes.
The processing of the power modes as test modes must start with the test mode that contains
the least amount of powered on circuitry, and then move to the next, until all selected test
modes are processed. This helps address faults in those locations in the design where power
is turned on early. As a result, when a different powered domain is powered on in subsequent
test modes, ATPG does not need to focus on this power domain if it has been tested
previously.
Encounter Test can determine that a power mode is targeted by a test mode by the
specification of the power_mode keyword in the pin assign file. During build_testmode,
the power_mode keyword is set to the CPF or UPF/1801 defined power mode name to set
the power mode state within that test mode.
The first decision block in Figure 3-3 on page 86 determines whether to generate test vectors
that specifically target the power components identified in the netlist through the CPF or UPF/
1801 library definitions. The Encounter Test installations contrib directory includes scripts
create_lp_tests (for static faults) and create_lp_delay_tests (for dynamic faults)
that produce low power test vectors. These scripts can be run before or after the standard
ATPG runs. This step is optional for production purposes because the faults associated with
low power components are also targeted by running the create_scanchain_tests and
create_logic_tests commands. Refer to Creating Retention Tests in Encounter Test:
guide 5: ATPG for additional information.

Low Power Flow
Important
The create_lp_tests.pl and create_lp_delay_tests.pl scripts in the
contrib directory are not supported formally.
The Analysis blocks in Figure 3-3 on page 86 list Report Power Component (PC) Fault
Statistics as an analysis task. This task comprises of producing and analyzing low power fault
reports and low power fault statistics reports. These reports are useful in analyzing the ATPG
results. Refer to Creating Retention Tests in Encounter Test: guide 5: ATPG for additional
information.
Write Toggle Gram is an additional Analysis step. While the Report PC Fault Statistics task
focuses on the faults in the design, the write_toggle_gram command focuses on the
patterns created to test those faults. This analysis can be done on any pattern set created
with Encounter Test to determine if the toggling of the flops during the test is at an acceptable
level. Although the keyword maxscanswitching may be used to control fill of the patterns
to a balanced level, escapes may still be possible. For example, these escapes could occur
where the toggle limit exceeds the limit specified due to over-compaction of the patterns.
When this occurs, either discard the experiment that contains these violations or delete those
particular sequences from the pattern set. If deleting specific sequences, the patterns must
be resimulated to determine the test coverage impact resulting from the deletion. These
patterns must also undergo additional analysis with the write_toggle_gram command to
ensure that the deletion of the sequences did not transfer the problem to another location in
the patterns. Refer to Calculating Switching Activity for Generated Test Vectors in Encounter
Test: Guide 6: Test Vectors for additional information.
This process can be repeated for each of the selected low power test modes to provide a
complete low power test pattern set for a quality design.
During the analysis performed using the write_toggle_gram command, a Toggle Count
Format (TCF) file can be written for the patterns being analyzed. The TCF file can be used
with VoltageStorm to determine an estimated average and peak power consumption when
the patterns are applied to the chip at the tester.
Building the Low Power Logic Model

Build the logic test model after completing netlist preparation and after inserting the
appropriate test structures. Test pattern generation and verification is based on the test
model.

Low Power Flow
Figure 3-4 illustrates the logic model flow steps.
Figure 3-4 Logic Model Flow
Synthesized
Netlist
Build Test Model
Structural
Verilog
CPF or Read_Power_Intent
UPF/1801 or
Prepare CPF Data
Structural Verilog - library models are required to build a test model. These technology
library models will be imported so that the internal workings of the Encounter Test tool (ATPG,
Fault Simulation, and so on) can understand the behavior and develop accurate fault models
of the design to assure a quality design.
The prepare_cpf_data command reads the CPF file and subsequent Encounter Test
applications requiring the CPF information can extract it from the Encounter Test low power
database; no other application is required to read in the CPF file. Refer to Prepare CPF Data
on page 89 for details.
Similarly, the read_power_intent command reads the UPF/1801 file and subsequent
Encounter Test applications requiring the UPF information can extract it from the Encounter
Test low power database; no other application is required to read in the UPF file.
Use the command build_model (via GUI, click Verification-Build Models-Model).
Refer to Building a Logic Model in the Encounter Test: Guide 1: Models for additional
information.
Prepare CPF Data
CPF data may be introduced into the Encounter Test low power flow with the
prepare_cpf_data command after completion of build_model. Refer to Figure 3-1 on
page 83. The prepare_cpf_data command executes the following:
Accepts a CPF file and compares the signals in the CPF file to the Encounter Test model
to verify the signals exist in the model. The following is the syntax to specify an input CPF
file with the cpffile keyword:

Low Power Flow
prepare_cpf_data cpffile=file
Stores the CPF data in the Encounter Test database for use by downstream commands
Accepts a name mapping file that contains the mapping between objects in the Common
Power Format (CPF) file and their corresponding names in the netlist. This is required
since object names could get modified during synthesis and the name mapping file
allows tracking of these changes while continuing to use the golden CPF file. The
following is the syntax to specify an input name mapping file with the
namemappingfile keyword:
prepare_cpf_data namemappingfile=file
Refer to prepare_cpf_data in the Encounter Test: Reference: Commands for syntax

details.
Sample Scenario for Using CPF Data
Example 3-1 shows a sample output log for prepare_cpf_data. Refer to Sample CPF
Input File in Encounter Test: Guide 2: Testmodes for a sample of a CPF file specified with
the cpffile keyword.
Example 3-1 prepare_cpf_data Output

INFO (TDA-007): Job Information:
Date Started: Monday Mar 24 12:00:46 2008 EDT
Host machine is end-bull, i686 running Linux 2.4.21-37.ELsmp.
This job is process number 25272.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.

(keywords marked with * have program generated values,
keywords marked with + were specified to default.)
WORKDIR=.
logfile=./testresults/logs/log_prepare_cpf_data_032408120046
cpffile=pf_test_clean.cpf
[end TDA_009]
INFO (TLP-600): Processing Common Power Format (CPF) file pf_test_clean.cpf.
[end TLP_600]
Processing commands as they appear in the CPF file:
Processing command define_level_shifter_cell

Processing command define_isolation_cell
Processing command define_always_on_cell
Processing command define_state_retention_cell
Processing command set_design
Processing command set_hierarchy_separator
Processing command create_power_domain

Low Power Flow

Processing command create_nominal_condition
...
...
INFO (TLP-601): The CPF information has been saved in the Encounter Test database.
[end TLP_601]
INFO (TLP-605): Getting Power Component instances in the design. [end TLP_605]
INFO (TLP-606): Found 45 instances of Power Component type(s) SRPG in the design.
[end TLP_606]
INFO (TLP-606): Found 0 instances of Power Component type(s)LEVELSHIFTER in the
design. [end TLP_606]
INFO (TLP-606): Found 0 instances of Power Component type(s) ISO in the design.
[end TLP_606]
INFO (TDA-001): System Resource Statistics.Maximum Storage used during the run
and Cumulative Time in hours:minutes:seconds:
Working Storage = 11,909,684 bytes

Mapped Files = 249,856 bytes
(Paging) Swap Space = 13,877,436 bytes
CPU Time = 0:00:00.09

Elapsed Time = 0:00:01.00 [end TDA_001]
*******************************************************************************
* Message Summary *
*******************************************************************************
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
1 INFO (TDA-001): System Resource Statistics. Maximum Storage used during the run
1 INFO (TLP-600): Processing Common Power Format (CPF) file pf_test_clean.cpf.
1 INFO (TLP-601): The CPF information has been saved in the Encounter Test database.
1 INFO (TLP-605): Getting Power Component instances in the design.
3 INFO (TLP-606): Found 45 instances of Power Component type(s) SRPG in the
design.
*******************************************************************************
Read Power Intent
UPF/1801 data may be introduced into the Encounter Test low power flow with the
read_power_intent command after completion of build_model. Refer to Figure 3-1 on
page 83. The read_power_intent command:
Accepts a UPF/1801 file and compares the signals in the file to the Encounter Test model
to verify the signals exist in the model. The following is the syntax to specify an input UPF
file with the upffile keyword:
read_power_intent upffile=file

Low Power Flow
Stores the UPF/1801 data in the Encounter Test database for use by downstream
commands.
Refer to read_power_intent in the Encounter Test: Reference: Commands for syntax

details.
Sample Scenario for Using UPF/1801 Data
Example 3-2 shows a sample output log for read_power_intent.
Example 3-2 read_power_intent Output

INFO (TDA-006): QF path information.
QF_PATH=/home/et/sbox/svijay/check_in_r14/tools.lnx86/bin/64bit:
QF_NLSPATH=/home/et/sbox/svijay/check_in_r14/tools.lnx86/msg/%N:
QF_LD_LIBRARY_PATH=/home/et/sbox/svijay/check_in_r14/tools.lnx86/
lib/64bit:
[end TDA_006]
INFO (TDA-007): Job Information:
Date Started: Wednesday Apr 01 13:58:19 2015 IST
Host machine is rlno-svijay, x86_64 running Linux 2.6.18-
308.13.1.el5.
This job is process number 17118.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=.
logfile=./testresults/logs/log_read_power_intent_040115135819-
071912000 messagecounteach=10 upffile=./2.sec-dom.my2.1.0e.upf
reportpowercomponent=all + reportpowerstateinfo=yes
[end TDA_009]
INFO (TPI-600): Processing Unified Power Format (UPF) file './2.sec-
dom.my2.1.0e.upf'. [end TPI_600]
Processing commands as they appear in the UPF file
Processing command set_design_top
Processing command create_supply_net
Processing command create_supply_port
Processing command connect_supply_net
Processing command create_supply_port
Processing command connect_supply_net
Processing command create_power_switch
...
...
INFO : Finding Equivalent Ports which are connected through nets successfull.
INFO : Finding Root Supply Source process successfull.

Low Power Flow
INFO : Updating Root Supply Source process successfull.

INFO : Checking Root Supply Source process successfull.
*******************************Power Modes Details***************************
Power Mode Name : PM1
Domain Name Net Supply Name State Name Nominal Condition Name Voltage Value
...
...
Power Mode Name : PM2
Domain Name Net Supply Name State Name Nominal Condition Name Voltage Value
...
...
*****************************************************************************
INFO : Merging Process of PSTs successfull.
INFO : Nominal Condition generation process successfull.
INFO (TPI-601): The UPF information has been saved in the Encounter Test database.
[end TPI_601]
INFO (TPI-607): For Power Component type 'LEVELSHIFTER', there are no cells defined
in the UPF file. [end TPI_607]
INFO (TPI-605): Getting Power Component instances in the design. [end TPI_605]
INFO (TPI-606): Found 1 instances of Power Component type(s) 'SRPG' in the design.
[end TPI_606]
INFO (TPI-606): Found 0 instances of Power Component type(s) 'LEVELSHIFTER' in the
design. [end TPI_606]
INFO (TPI-606): Found 3 instances of Power Component type(s) 'ISO' in the design.
[end TPI_606]
List of SRPG instances in the design:
-------------------------------------
List of SRPG instances in the design:
-------------------------------------
inst_A.out1_reg
List of ISO instances in the design:

------------------------------------
CPF_ISO_HIER_INST_5.g1
...
================ Reporting Power State Information ================
Power Mode : PM1 0.00 percent of the logic is off
...
*******************************************************************************
* Message Summary *
*******************************************************************************
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
1 INFO (TPI-600): Processing Unified Power Format (UPF) file './2.sec-
dom.my2.1.0e.upf'.
1 INFO (TPI-601): The UPF information has been saved in the Encounter Test database.
1 INFO (TPI-605): Getting Power Component instances in the design.
3 INFO (TPI-606): Found 1 instances of Power Component type(s) 'SRPG' in the design.
1 INFO (TPI-607): For Power Component type 'LEVELSHIFTER', there are no cells
defined in the UPF file.

Low Power Flow
For a detailed explanation of a message and a suggested user response execute

'msgHelp <message id>'. For example: msgHelp TDA-009
*******************************************************************************
Building a Low Power Test Mode

Encounter Test utilizes the functional power structures (that is, switchable power domains) to
aid in the management of test. The following are advantages of these approaches:
Constrained Power Control Component
If these components are constrained into a single state (as when all power domains are
held in a powered on state only for test), not all the faults will be tested. This method
allows for different test modes to see these components in different states the global fault
model allows for the mark off faults across test modes which will quickly allow these
components to achieve a higher coverage.
Partitioning test
If a switchable power domain can be shutdown in a test mode, the ATPG engine will only
target the faults in the powered on logic and the average power on the chip will be less
with less active logic during test.
The build_testmode command will automatically load and use a low power database
created by the prepare_cpf_data or read_power_intent command.
Figure 3-5 depicts the flow to produce a low power test mode.

Low Power Flow
Figure 3-5 Low Power Test Mode Flow
Review the guidelines
Configure mode definition statement
Build the testmode
Verify Test Mode
Recommended Low Power Guidelines
Typically, when selecting power modes to be built as a test mode, it is recommended that at
a minimum, a power mode will be needed to represent each switchable power domain in both
an on and off state. Though this is not a hard requirement, it will provide for higher quality
test for a design. More or less power modes can be selected to be mapped to test modes if
desired.
To ensure that the design is fully tested, each logic block must be included in at least one test
mode that has that logic block power on. Adhere to the following guidelines when selecting
test modes:
1. If MBIST is inserted, one of the selected power modes must have every power domain
in which MBIST is inserted in a powered on state.
2. At least one instance of each power domain must be at an on condition, preferably
across multiple power modes.
3. At least one instance of a power domain is preferred to be off across power modes.
Memory is a significant area of power consumption during test. Memory testing is typically
managed by two methods:
The amount of parallelism which targeted memories will be running at the same time
The frequency at which the targeted memories are being tested

Low Power Flow
Configuring a Low Power Test Mode Definition Statement
The inputs for the build_testmode command are pin assign file and a mode initialization
file. The mode initialization file is typically an optional input for most test modes. Refer to
Mode Initialization Sequences in the Encounter Test: Guide 2: Testmodes for additional
information.
The Power_Mode definition statement links the power mode to the generated test mode. The
power modes configuration is the assumed configuration which is forced when the test mode
is constructed. If the statement is not included as either a mode definition statement or in an
assign file, no specific power mode will be assumed and all power domains will be assumed
active. Refer to Power_Mode in the Encounter Test: Guide 2: Testmodes for the mode
definition syntax.
Building the Low Power Test Mode
Use the build_testmode command (via GUI click Verification-Build Models-Test

Mode).
Important
Low power test flows using CPF 1.0 extended and CPF 1.1 are currently not
supported via GUI.
Refer to Building a Test Mode in the Encounter Test: Guide 1: Models for additional
information.
Verifying a Low Power Test Mode
The power-related check performed by the verify_test_structures command

identifies observable X-sources that are the result of powered-off logic. X-source
identification ensures the isolation logic is valid.
A series of default tests can be run with the verify_test_structures command. These
tests are in areas such as analyzing scan clocks, scan flops, tri-states, feedback, clock
choppers, fix value flops and clock race conditions.
Advanced tests are available that deal with compression and with X sources that are the
result of powered-off logic. X-source identification ensures the isolation logic is valid. These
options must be explicitly selected.

Low Power Flow
Use interactive message analysis to analyze error or warning messages in the logs. Refer to
Analyzing Test Structure Problems in the Design in the Encounter Test: Guide 3: Test
Structures for additional information.
Note: Boundary Scan Verification will be needed if the insert_dft boundary_scan
command was issued as part of the RTL Compiler portion of the flow.
Analyzing Low Power Fault Model

A fault model is typically built after creating a testmode, however, it may also be built after
creating a logic model.
Use the build_faultmodel to create a fault model with low power components.
Refer to Build Fault Model in Encounter Test: Guide 4: Faults for more information. Also
refer to Reporting Low Power Faults and Reporting Low Power Fault Statistics in Encounter
Test: Guide 4: Faults for information on generating fault reports and fault statistics reports
for power components.
Generating and Analyzing Low Power Vectors

Refer to Analyzing Low Power Test Patterns and Producing Vectors in Encounter Test:
Guide 6: Test Vectors for information on generating low power vectors, calculating
switching activity for the generated vectors, and writing low power vectors.

Low Power Flow

4
RAM Sequential Tests
RAM Sequential test is the process of testing dynamic faults on the perimeter of a memory
element (RAM or ROM). The faults on the perimeter of the memory element are precisely
identified so that the only way these faults can be tested is through exercising a memory
operation. These faults are recommended to be created as part of a cell boundary fault
model. See Build Fault Model Examples for Cell Boundary Fault Model in Encounter Test:
Guide 4: Faults.
The memory models are required and need to be included in the build_model step; they
cannot be black boxed. The source for the memory models can come from Encounter Test
build_memory_model or can be migrated to the Encounter Test memory model format
from another tool. See Building Memory Models for ATPG in Encounter Test: Guide 1:
Models.
Use Model
The following figure represents the flow for performing RAM sequential tests.

Figure 4-1 RAM Sequential Test Flow
Note:
1. To run the RAM sequential flow with the true_time use model script, specify
DELAYTESTTHRUMEMORIES=yes or DELAYTESTTHRUMEMORIES=only in the setup
file. If DELAYTESTTHRUMEMORIES=only is specified, the RAM sequential use model
flow is the only type of ATPG that is performed.
2. The value of the memories keyword on the prepare_fault_subset command can
be yes (to select all memories in the design) or a comma separated list of names of the
specific memories whose faults are to be included in the subset. The specific memory
names may be listed by one of the following (all names in the list must be one or the other;
module names and instance names should not be mixed):
cell name (Verilog module name): to include all instances of the specific modules
instance names: to include only selected instances of the memory modules

3. The create_logic_delay_tests command for processing the faults on the

perimeter of the memories must include memories=yes to let the test generator know it
is specifically targeting memory faults. It must also include append=yes to append to the
experiment that was initialized by prepare_fault_subset.
4. A commonly used, but a not required keyword, for create_logic_delay_tests is
singleload. When singleload=yes (the default), the generated test sequences
include only one scan load. When you specify singleload=no then test sequences will
be generated with two or more scan loads, which is generally beneficial for testing faults
around a memory.
5. The true_time use model script allows values of singleload=no (default)|yes
in the setup file.
6. The testmode fault statistics in the log for this create_logic_delay_tests run are
for the fault subset rather than the full fault model. The global fault statistics are against
the full fault model.
7. The simulation of the vectors from create_logic_delay_tests fault grades the
RAM sequential test vectors against the full fault model, and any additional faults that are
serendipitously tested by these vectors (such as those faults in the shadow of the RAM)
are included in the test coverage. The testmode, as well as global coverage shown in this
run, is calculated against the full fault model.
8. The results of the simulation are committed to the full set of test vectors for the testmode
with commit_tests.
9. Distributed processing is not supported for RAM sequential tests.
Command Examples
Use model flow selecting faults on the perimeter of all memories on the
design
The following command lines show the default flow when running the true_time use model
script. These commands prepare the faults around the perimeter of each of the memories on
the design, and then the tests are generated on these faults and simulated against the full
fault model.
Note: Tests are generated with multiple scan loads in the sequences that yield the highest
test coverage. If your tester cannot support multiple scan load test sequence, specify
singleload=yes on the create_logic_delay_tests command.
prepare_fault_subset workdir=. testmode=FULLSCAN_DELAY experiment=ramseq1
memories=yes

create_logic_delay_tests workdir=. testmode=FULLSCAN_DELAY experiment=ramseq1

memories=yes append=yes singleload=no
analyze_vectors workdir=. testmode=FULLSCAN_DELAY inexperiment=ramseq1

experiment=ramseq2_full simulation=hsscan
commit_tests workdir=. testmode=FULLSCAN_DELAY inexperiment=ramseq1_full
Selecting specific memory modules for RAM sequential test by module

name
The following command lines represent a more complex flow. The example shows two
testmodes, each configured to include a subset of the memories on the design. The faults
selected are the ones for the memories that are actively included in the testmode. The
memories are selected by module (cell) name. Tests are generated for the faults, simulated
against the full fault model, and then committed.
prepare_fault_subset workdir=. testmode=FULLSCAN_DELAY1 experiment=ramseq_ram1
memories=ram1
create_logic_delay_tests wordir=. testmode=FULLSCAN_DELAY1 experiment=ramseq_ram1

memories=yes append=yes singleload=no
simulate_vectors workdir=. testmode=FULLSCAN_DELAY1 inexperiment=ramseq_ram1

experiment=fullsim_ram1
commit_tests workdir=. testmode=FULLSCAN_DELAY1 inexperiment=fullsim_ram1
prepare_fault_subset workdir=. testmode=FULLSCAN_DELAY2 experiment=ramseq_ram2_3

memories=ram2,ram3
create_logic_delay_tests workdir=. testmode=FULLSCAN_DELAY2

experiment=ramseq_ram2_3 memories=yes append=yes singleload=no
simulate_vectors workdir=. testmode=FULLSCAN_DELAY2 inexperiment=ramseq_ram2_3

experiment=fullsim_ram2_3
commit_tests workdir=. testmode=FULLSCAN_DELAY2 inexperiment=fullsim_ram2_3
Selecting specific memory modules for RAM sequential test by instance

name
The following command lines also represent a complex flow. There is only one testmode but
we have decided to test specific instances of the memories separately. The memories are
selected by instance (block) name. Tests are generated for the faults, simulated against the
full fault model, and then committed.
prepare_fault_subset workdir=. testmode=FULLSCAN_DELAY experiment=ramseq_ram1_i1
memories=chip.core.ram1_i1
create_logic_delay_tests wordir=. testmode=FULLSCAN_DELAY

experiment=ramseq_ram1_i1 memories=yes append=yes singleload=no
simulate_vectors workdir=. testmode=FULLSCAN_DELAY inexperiment=ramseq_ram1_i1

experiment=fullsim_ram1_i1
commit_tests inexperiment=fullsim_ram1_i1
prepare_fault_subset workdir=. testmode=FULLSCAN_DELAY

experiment=ramseq_ram1_i2_3 memories=chip.core.ram1_i2,chip.core.ram1_i3
create_logic_delay_tests workdir=. testmode=FULLSCAN_DELAY

experiment=ramseq_ram1_i2_3 memories=yes append=yes singleload=no
simulate_vectors workdir=. testmode=FULLSCAN_DELAY inexperiment=ramseq_ram1_i2_3

experiment=fullsim_ram1_i2_3
commit_tests inexperiment=fullsim_ram1_i2_3


5
Hierarchical Test Flow

Introduction
Core Processing Methodology Flow
Chip Processing Methodology Flow
Requirements and Limitations
Introduction
Encounter Test supports the Hierarchical Test methodology for processing of large designs
comprised of multiple instances of the same cores. Tests are generated for each core
out-of-context. When the core is instanced on a chip, the existing out-of-context core tests are
migrated to be applied at the chip I/O. The remaining chip faults around the cores are the only
ones tested at the chip level. See Figure 5-1 for a high-level depiction of the process.
Advantages of this process are:

Reduces memory usage: core migration models are used for all instances of each
unique core in the chip design. When processing the chip, this saves substantially on the
size of the model. Memory consumption in applications (often proportional to the size of
the model) is similarly reduced.
Improves speed of ATPG on the chip (SoC): Tests for each instance of each in-context
core are migrated rather than generated. ATPG run at the chip level only targets faults
outside the cores; the number of such faults should be relatively small and the paths into
cores should be short so the time to generate the tests is less.

Figure 5-1 Depiction of Hierarchical Test
Core Processing Methodology Flow

The following figures represent the methodology flow for generating tests for the
out-of-context core and preparing those tests for migration. This flow can apply to cores used
in multiple chip designs and should need to be done only once for each final version of a core.
The first step, shown in Figure 5-2, is to wrap the core and process it as a standalone entity
(called the out-of-context core) using the normal test process.
RC-DFT inserts IEEE 1500 style wrappers and ties into the WIR control register the
ability to control the modes of the core. This includes the ability to control INTEST and
EXTEST compression, and the ability to have the INTEST compression modes be either
Active or Inactive where the inactive mode ensures the core does not interfere with the
top-level compression of Active core outputs.
Encounter Test is used to create tests for the core. Tests may include:
OPCG
XOR Compression
OPMISR+ Compression
Static and/or Dynamic Faults

The second step, shown in Figure 5-2, is to build the core migration model and prepare the
data required for migration of the tests at the chip (SoC) level.
Figure 5-2 Out-of-Context Core Processing Flow
Netlist for
unwrapped core START
Wrap Core with Refer to chapter Hierarchical Test in

Compression Design for Test in RTL Compiler
Wrapped
Core Netlist
Build Model Model identified with core=yes
Build Testmodes (INTEST, INTEST testmodes to generate tests to migrate

BYPASS testmode to allow bypass at the chip
BYPASS, EXTEST) EXTEST testmodes logic in core migration model
Verify Test Structures for

Core tbdata
each Testmode
Build Fault Model
Migratable tests for INTEST Testmodes: Spe-

Create Scanchain and cial scanchain test without explicit shifts
Logic Tests Logic Compression (XOR, OPMISR), Fullscan
Commit Tests
Prepare for Test Migration

Figure 5-3 Preparing for Test Data Migration
Build Core Migration Model
Prepare Core Migration

Faults per Testmode
Core Migration
Core tbdata
Directory/Module
Info per Testmode

Tests per Testmode
Chip Processing Methodology Flow

The following figure represents the methodology flow for a chip (SoC) that instantiates one or
more cores that have been prepared for test data migration.

Figure 5-4 Chip Processing Flow
START
Design Chip with

compression above the
Cores
Chip Netlist
Build Model Chip Model with migration models for each Core
Build Core Migration One or more instances of one Core available in

each testmode; other cores are in bypass mode
Testmodes
Build Testmodes for

Core Migration Chip Top
Directories
Verify Test Structures for
Chip Top Testmodes
Faults from top level and Cores; uses fault rule

Build Fault Model
for cores
Migrate Core Tests for Migrate tests for instances of one core at a
each test and Commit time
Create Logic Tests for Chip All cores in Bypass mode to test
Top and Commit interconnections and top-level chip logic
Example of Out-of-Context Core Processing

The following is an example of the steps and commands required to process a Core so its
tests can be migrated when it is instanced on a Chip (SoC).

RC-DFT for Core - XOR with Bypass Register and WIR

set_attr library typical.lib
set num_ichan 39
set num_wchan 5
set num_ichan_index [expr $num_ichan-1]
set num_wchan_index [expr $num_wchan-1]
read_netlist ../DLX_CORE_CLOCK_GATED.v
set te [define_dft test_mode -active high te]
set se [define_dft shift_enable -active high se]
check_dft_rules
##################################################
# Define and Insert Internal and Wrapper Channels
##################################################
insert_dft wrapper_instruction_register
set wint [find / -pin DLX_CORE_3_wir_inst/INTEST]
set wext [find / -pin DLX_CORE_3_wir_inst/EXTEST]
# Insert scan
define_dft shift_enable WSEN_in -active high -create_port
define_dft shift_enable WSEN_out -active high -create_port
set in_portlist [find /designs/* -port ports_in/*]

set out_portlist [find /designs/* -port ports_out/*]
set wrappedInputList [ insert_dft wrapper_cell \

-location $in_portlist -wsen WSEN_in -wint $wint -wext $wext -wck I_CORE_SYS_CLK \
-name wrap_in \
-shared_through buffer \
-exclude_comb_feedthrough_paths -skipped_locations_variable skipped_in]
puts "skipped_in=$skipped_in"
set wrappedOutputList [ insert_dft wrapper_cell \

-location $out_portlist -wsen WSEN_out -wint $wint -wext $wext -wck I_CORE_SYS_CLK
\
-name wrap_out -guard 0 -wog $wint \
-shared_through buffer \
-exclude_comb_feedthrough_paths -skipped_locations_variable skipped_out]
puts "skipped_out=$skipped_out"
# Fix EXTEST mode leak through CGIC enable pin

set wext_ts [define_dft test_mode -active high $wext]
identify_integrated_clock_gates_controlling_wrapper_cells icgs ""
foreach icg $icgs {
puts "Inserting control_1 test point at [vname $icg/pins_in/test]"
insert_dft test_point -type control_1 -location $icg/pins_in/test -
test_control$wext_ts
}
rm $wext_ts
################################################
check_dft_rules
report dft_core_wrapper
set_attr dft_prefix DFT_WCHAIN_ /
for {set i 0} {$i < $num_wchan} {incr i} {

define_dft scan_chain -sdi DFT_WCHAIN_SI[$i] -sdo DFT_WCHAIN_SO[$i] -create_ports
}

set core_wrapper_ss [filter core_wrapper true [find / -scan_segment *]]

connect_scan_chains -elements $core_wrapper_ss
set_attr dft_prefix DFT_ICHAIN_ /
for {set i 0} {$i < $num_ichan} {incr i} {

define_dft scan_chain -sdi DFT_ICHAIN_SI[$i] -sdo DFT_ICHAIN_SO[$i] -create_ports
}
connect_scan_chains -incr
report dft_chains > $env(RCDFT_OUT_DIR)/dft_chains.rpt0
write_db -to_file $env(RCDFT_OUT_DIR)/DLX_CORE_WRAPPED_WIR.db
set dft_prefix DFT_
##################################################
# Define test_bus_ports
##################################################
# Data ports
edit_netlist new_port_bus -input -name CPI -left_bit 7 -right_bit 0 /designs/
DLX_CORE
edit_netlist new_port_bus -output -name CPO -left_bit 7 -right_bit 0 /designs/
DLX_CORE
for {set i 0} {$i < 8} {incr i} {

define_dft test_bus_port -function compress_sdi -index $i CPI[$i]
define_dft test_bus_port -function compress_sdo -index $i CPO[$i] }
define_dft test_bus_port -function serial_sdi WSI -create_port

define_dft test_bus_port -function serial_sdo WSO -create_port
# WIR (Local) control signals
set bypass [find / -pin DLX_CORE_3_wir_inst/BYPASS]
# Global Control signals

define_dft test_bus_port -function compression_enable SCOMP -create_port
define_dft test_bus_port -function mask_load CMLE -create_port
define_dft test_bus_port -function mask_enable -index 0 CME0 -create_port
define_dft test_bus_port -function mask_enable -index 1 CME1 -create_port
define_dft test_bus_port -function spread_enable SPREAD -create_port
define_dft test_bus_port -function wrapper_and_compression_clock CK -create_port
# Controls for WIR

define_dft test_bus_port -function select_wir WIR_SEL -create_port
define_dft test_bus_port -function shift_wr SHIFTWR -create_port
define_dft test_bus_port -function capture_wr CAPTUREWR -create_port
define_dft test_bus_port -function update_wr UPDATEWR -create_port
define_dft test_bus_port -function wrapper_reset WRST -create_port
set wchains [find / -actual_scan_chain DFT_W*]

set ichains [find / -actual_scan_chain DFT_I*]
insert_test_compression -use_existing_channels $ichains \

-use_existing_wrapper_channels $wchains -bypass_reg \
-compressor xor -decompressor xor -mask wide2 DLX_CORE \
-use_wir_macro DLX_CORE_3_wir_inst -directory $env(RCDFT_OUT_DIR)
rm dft/scan_chains/DFT_ICHAIN*
rm dft/scan_chains/DFT_WCHAIN*

foreach p [find / -port_bus DFT_ICHAIN*] {

set p1 [basename $p]
edit_netlist disconnect $p1
rm $p }
foreach p [find / -port_bus DFT_WCHAIN*] {

set p1 [basename $p]
edit_netlist disconnect $p1
rm $p }
report dft_chains > $env(RCDFT_OUT_DIR)/test4.rpt

write_scandef > $env(RCDFT_OUT_DIR)/test4.scandef
write_et_atpg -library $env(REGLIBS)/../sim/tsmc13.v -directory

$env(RCDFT_OUT_DIR)/et \
-compression -hier_test_core -serial
Create Tests for Core
Build Model
The only unique thing for processing the core for use in hierarchical test is to identify that it is
an out-of-context core whose tests are intended to be migrated when it is instanced on a chip
(SoC). This identification is done by including core=yes on the command line:
build_model cell=DLX_CORE core=yes blackbox=yes blackboxoutputs=z \
industrycompatible=yes teiperiod=__rcETdft_ \
designsource=$WORKDIR/DLX_CORE.et_netlist.v \
techlib=/techlib/regs/../sim/tsmc13.v
Note: If you do not specify core=yes, it will not impact the top-level fault processing but the
generated fault model will not have PI/PO faults.
Build Testmodes
There will be many testmodes built for this methodology; INTEST, EXTEST, and BYPASS
testmodes. For this example, the following testmodes were built.
Testmode Name (testmode=) Mode Definition Name (modedef=)

FULLSCAN_INTEST FULLSCAN_INTEST
FULLSCAN_EXTEST FULLSCAN_EXTEST
FULLSCAN_BYPASS FULLSCAN_BYPASS
COMPRESSION_INTEST COMPRESSION_INTEST
COMPRESSION_EXTEST COMPRESSION_EXTEST

Testmode Name (testmode=) Mode Definition Name (modedef=)

COMPRESSION_BYPASS COMPRESSION_BYPASS
COMPRESSION_DECOMP_INTEST COMPRESSION_INTEST
COMPRESSION_DECOMP_EXTEST COMPRESSION_EXTEST
COMPRESSION_DECOMP_BYPASS COMPRESSION_BYPASS
SERIAL_INTEST FULLSCAN_INTEST
SERIAL_EXTEST FULLSCAN_EXTEST
SERIAL_BYPASS FULLSCAN_BYPASS
The command line is not unique for hierarchical test, the unique features are in the modedef,
seqdef, and assignfile. The following is an example of the command line generated by
RC-DFT for this design.
build_testmode \
testmode=FULLSCAN_INTEST \
assignfile=$WORKDIR/DLX_CORE.FULLSCAN_INTEST.pinassign \
seqdef=$WORKDIR/DLX_CORE.FULLSCAN_INTEST.seqdef \
modedef=FULLSCAN_INTEST \
allowflushedmeasures=yes
The modedef for INTEST includes boundary=migrate; for EXTEST includes

boundary=external,model; for BYPASS includes boundary=bypass.
The assignfile sets the test function pins required for each state. It may also include
statements for other types of logic such as OPCG or OPMISR. There are no unique
statements for hierarchical test in the core processing.
The seqdef defines the mode initialization sequence required to initialize the testmode.
Note: You may build additional testmodes that are not INTEST, EXTEST, or BYPASS, but
they will not be considered in the hierarchical test methodology. The only tests that are
migrated are those created for INTEST testmodes. The active logic in the EXTEST and
BYPASS testmodes is included in the core migration model.
The verify_test_structures command is run on each testmode. There are no unique

keywords for hierarchical test. The following command line example runs all default checks
and the xclockanalysis check that looks for clock inputs to flops/latches that are at X in the
test constraint and clocks off state. Other options to limit output or to add or subtract specific
checks may be included to meet your design and methodology requirements.

verify_test_structures testmode=FULLSCAN_INTEST xclockanalysis=yes
Build Fault Model
The build_faultmodel command is run once to create the set of faults for the design and
identify which faults are active in each existing testmode. There are no unique keywords for
hierarchical test.
build_faultmodel
Create Logic Tests
For hierarchical test, you want to create tests for each of the INTEST testmodes as those are
the tests that will be migrated. You want to create a form of the scanchain tests that does not
include explicit shifts and create logic tests.
Although create_scanchain_tests and create_logic_tests may be run separately,

by default the scanchain test is created when you run create_logic_tests if it does not
already exist (that is, you already committed the scanchain test or you are appending to an
experiment that already contains the scanchain test). The form of the scanchain tests that
does not include explicit shifts is automatically selected because the testmode was built with
boundary=migrate. So, there are no unique keywords required to create tests for
hierarchical test. A sample command line is:
create_logic_tests testmode=FULLSCAN_INTEST experiment=DLX_CORE_compression
Note:
You may create tests for other testmodes, but the only tests that are migratable are those
for testmodes that have boundary=migrate in their mode definition file (INTEST).
The only valid tests for migration are scanchain and logic tests; no other types of tests
may be included in the set of tests to be migrated.
This discussion and example are centered on static test, however delay test is also
supported and the same commentary applies to create_logic_delay_tests as
well as create_scanchain_delay_tests.
Commit Tests
Tests that are to be migrated for hierarchical test must be committed. The processing of the
tests for migration is done for all tests that are committed for the testmode. When there will
be tests for more than one INTEST mode, commit the tests for one mode before creating tests
for the next mode. This will avoid targeting faults in the second mode that were already tested

in tests generated for a prior test mode. There are no unique keywords for commit_tests;
the following is an example command line:
commit_tests testmode=FULLSCAN_INTEST inexperiment=DLX_CORE_compression
Other Commands
There are no other commands required, however, you may choose to run reports or write
vectors for analysis or for testing the core out-of-context of the chip. There are no restrictions
on running other commands except as noted in the preceding Create Logic Tests section.
Note: It is recommended to use parallel Verilog simulation of all out-of-context tests; only
serial Verilog simulation will be available once the tests are migrated to an SoC. The ability to
run parallel Verilog simulation on migrated tests is planned for a future release. Until then, it
is recommended to use serial Verilog simulation of a few migrated tests for each core
instance.
Prepare for Core Test Data Migration

Once all your tests are created for the out-of-context core, the next step is to prepare the data
required for migrating the tests at the chip level. The following sections continue the example
to show the commands for preparing the core tests for migration.
Build Core Migration Model
This step extracts all the necessary logic from your EXTEST and BYPASS testmodes. The
goal is to create the smallest possible model that still includes all logic necessary to allow
testing, on the chip (SoC), of logic above or outside the cores; and allows the core to be
bypassed when migrating tests for another core on the chip (SoC). The testmodes that have
been created for the core and their characteristics are already known to the application from
data in the workdir of the core. Therefore, the only input required for this command is the
location of the workdir and the location where the output data is to be written. The following
is a sample command:
build_core_migration_model coremigrationdir=./et/DLX_CORE_DIR
The location of the workdir (as in the previous command examples) is obtained from the
WORKDIR variable set in the environment or is assumed to be the directory you are in when
you execute the command. You may explicitly set the workdir on the command line with
WORKDIR=<name of workdir>.
coremigrationdir is the location for the core migration data. The core migration model
will be written into a sub-directory named by the module name of the top level. So, for this
example, since the top level module is named DLX_CORE, the data will be written to ./et/

DLX_CORE_DIR/DLX_CORE. This is done so you can specify the same coremigrationdir for
several cores and the data will be kept per core; this is useful when you build the model for
chip (SoC) processing.
Prepare Core Migration Faults
This step must be run for each testmode for which you intend to migrate tests, in which case,
all the INTEST testmodes. It extracts the information about the faults in the testmode and their
status and stores information that allows these faults to be accounted for in the chip
faultmodel (even though the INTEST logic will not exist in that model). The status information
is used to give credit for the tested faults when the tests are migrated.
The following is a sample command:

prepare_core_migration_faults coremigrationdir=./et/DLX_CORE_DIR \
testmode=FULLSCAN_INTEST
Prepare Core Migration Info
This step must be run for each testmode for which you intend to migrate tests and for each of
the core bypass modes that will be referenced at the chip level. The data it produces is used
by build_core_migration_testmode when processing the chip (SoC). The following is
a sample command:
prepare_core_migration_info coremigrationdir=./et/DLX_CORE_DIR \
Prepare Core Migration Tests
This step must be run for each testmode for which you intend to migrate tests. The data it
produces is used by migrate_core_tests when processing the chip (SoC). During this
process, the tests are translated into a form that does not require internal logic; so, for
example, stimulus on flops/latches is translated to the appropriate stimulus on the scan-in(s)
and pulses of the scan clock(s). The following is a sample command:
prepare_core_migration_tests coremigrationdir=./et/DLX_CORE_DIR \
Chip Processing
Design Chip Netlist
There is no tool support for this step at this time. You need to catenate all WIR scan paths
and connect them as well as other core control pins to the ports of the chip (SoC).

Build Model
This step builds the model for the chip (SoC) using the core migration models created for each
core. The location of the core migration models is included in the techlib or designsource
specification. If the data for all the cores included on the chip (SoC) used the same
coremigrationdir, then you just need to include that directory in your specification; you do not
need to mention the module name in the specification. The following is a sample command:
build_model designsource=SOC_top.v techlib=./et/DLX_CORE_DIR,/techlib/regs/../
sim/tsmc13.v
Build Core Migration Testmodes
This step builds the testmode data required for migration of core tests. You run this for each
core (or set of core instances) that is to have its tests migrated. You must point to the location
of the output data from prepare_core_migration_info. All keywords from
build_testmode are also available on this command. The following is a sample command.
build_core_migration_testmode testmode=FULLSCAN \
assignfile=$WORKDIR/SOC_top.FULLSCAN.pinassign \
seqdef=$WORKDIR/SOC_top.FULLSCAN.seqdef \
COREMIGRATIONPATH=./et/DLX_CORE_DIR
The unique requirement for this step is that the assignfile must contain an indication of which
instances of a single core are to be targeted for test migration and which cores are to be
bypassed. An example of the statements in the assignfile are given below. This indicates that
instance DLX_CORE_1 will be in the state set up by core testmode FULLSCAN_INTEST and
DLX_CORE_2 will be in the state set up by core testmode FULLSCAN_BYPASS. From the
information in the core migration directory, the application knows that DLX_CORE_1 should
have tests migrated for it and DLX_CORE_2 is to be bypassed.
coreinstance=DLX_CORE_1 testmode=FULLSCAN_INTEST ;
coreinstance=DLX_CORE_2 testmode=FULLSCAN_BYPASS ;
Build Testmodes for Chip Top
This step is used to build the testmodes that are required to test the logic around the cores.
There is nothing unique about this step, it is the same as in any Encounter Test processing
flow.
Verify Test Structures for Chip Top Testmodes
This step is used to verify the test structures in the testmodes that are required to test the
logic around the cores (from the previous step). There is nothing unique about this step, it is
the same as in any Encounter Test processing flow.

Build Fault Model
This step builds the faultmodel for the chip (SoC) and includes information gathered by
prepare_core_migration_faults that was run on the core. The only unique input to
this command is the identification of the core migration directory that contains the results of
prepare_core_migration_faults. The following is a sample command:
build_faultmodel coremigrationpath=./et/DLX_CORE_DIR
Migrate Core Tests and Commit
This step migrates the tests that were prepared for migration during core processing. The
step is run on each core migration testmode. The following is a sample command line:
migrate_core_tests testmode=FULLSCAN experiment=migrated_tg1 \
coremigrationpath=../ATPG_CORE_TEST/patt_migrate
When the migration is complete, the tests are committed. Once they are committed, the
global fault coverage will reflect the status of the faults that were in the original INTEST
testmode even though that logic is not included in the chip (SoC).
commit_tests testmode=FULLSCAN inexperiment=migrated_tg1
Create Logic Tests for Chip Top and Commit
This step is used to create tests for the other testmodes on the chip (ones that are not used
for migrating core data). The tests are created and committed as for any other Encounter Test
processing.
Requirements and Limitations
Requirements
Cores are expected to have been wrapped using RTL Compiler (RC)-DFT. In cases of custom
design where wrappers are not inserted by RC, the custom wrappers must conform to the
requirements of ET processing.
Core Test migration to the chip is supported only for well isolated cores.
Only Encounter Test supported test compression logic structures can have tests
migrated.
Core test migration requires that the cores for which patterns will be migrated have been
processed through Encounter Test Core Processing Flow.

Limitations
The following is a list of limitations on the current support for hierarchical test:
No Encounter Test automatic sequence generation for chip level test modes intended for
migration of core test patterns. Encounter Test does not understand how to properly
initialize the core configuration registers or any PLLs that must be set up and started by
the chip modeinit sequence. Also, the scan sequences for chip modes used for migrating
core patterns have no scan sequences as they are all defined by the cores whose
patterns are to be migrated.
No support for LSSD style scan requiring skewed loading or unloading.
No support for use of partition files when defining core or chip test modes for which tests
are to be migrated.
No "assumed scan" support for core or chip test modes that intend to follow the core test
migration flow.
No "scan type none" allowed for cores or chip test modes associated with core test
migration.
No support for 1149.1 scan modes for cores, and if used on a chip, it can be only for
initializing the chip mode for test migration by use of a parent test mode. This also means
no support to read BSDL for a core, although that may still be of use for chip level 1149.1
processing.
Only compression structures natively supported by Encounter Test are allowed within
cores and for top level compression logic.
No ability to read in STIL patterns for learning the sequences for a core or a chip.
No support for PRPG save and restore registers in LBIST modes for cores or at the chip
level.
No support for TB_STABILITY latches for cores.
No support for FLH latches.
No support initially for scanfill sequences.
No support to read in migratable or migrated patterns for simulation within Encounter
Test, including in the GUI analysis. Patterns that have been prepared for migration
cannot be brought back in for analysis.
Full core gate level models used in the chip are not allowed for core test migration; only
the core migration model may be used. A full gate level model of the core should be used
only when running ATPG at the chip level for that core.

No support initially to compute overall chip level switching activity from migrated test
patterns.
No support for creating chip wide core internal IDDQ test patterns. The ability to create
core specific IDDQ tests that could be migrated is a future support item.
No support for embedded macro test, including P1687 if it needs to access a net inside
a boundary model at the chip level.
No support to perform any kind of integrity checking, for example, to validate that the
current core definition matches the version used when the boundary model and core
patterns were generated, other than standard UNLEV attribute processing.
No support for concatenated core INTEST chains at the chip level.
No support for migration of patterns to a core through resistors between the core pins
and chip pins, specifically, if the resistors feed the core pins directly. However, the
migration is possible if there is a buffer inserted between the resistor and the core.

6
On-Product XOR Compression Flow

Introduction
XOR Compression Macro
Modes of Operation
XOR Compression Design Flow
XOR Compression Limitations
Introduction
Test Synthesis adds specialized circuitry, called a Compression Macro, which allows for
reduction in scan chain lengths and leads to reduced test time and test data volume. XOR
compression is an on-product test data compression method based on the use of
combinational XOR structures. An XOR-tree compactor is used for test response
compression (that is, scan-outs) and an optional XOR based test input (that is, scan-ins)
spreader can be used for test input data decompression.
The following subsections describe an alternative structure for On-product test data
compression based on the use of combinational XOR structures. An XOR-tree spreader is
used for test response compression and an optional XOR based test input spreader can be
used for test input data de-compression. Figure 6-1 on page 122 shows a high-level diagram
of the on-product XOR compression architecture. A stream of compressed test data from the
tester is fed to the N scan input pins of the chip under test. A space expander based on an
XOR based spreader network internally distributes the test data to a large number of internal
scan channels which is a multiple (for example, M) of the number of scan input pins N. The
input side test data spreader therefore feeds M*N scan channels.

Figure 6-1 On-Product Test Data Compression Architecture
On the output side, the test data response is compressed by a space compactor to create an
N-wide output test response data stream. The space compactor is based on a combinational
XOR-tree. Similar to the case of OPMISR and OPMISR+, optional X-masking logic can be
added between the scan channel tails and the input to the XOR based space compactor. The
masking logic is optional in the case of XOR-based compression since it has better tolerance
for capturing X-states than a MISR however it is highly recommended. It is difficult to predict
the number of X-states that may be captured on a clean design once it is fully implemented
and put on a tester.
While the XOR-based space compactor is needed on the output side, a simpler input side
decompressor based on scan fanout can also be used in this architecture. The four
compression options are summarized in Figure 6-2 . On the input side, the space expander
can be based on either scan fanout or an XOR spreader. On the output side, the space
compactor can be based on either a MISR or XOR tree. Encounter Test ATPG and
Diagnostics support all four combinations shown in Figure 6-2 . Test Synthesis does not
currently support the combination of an XOR spreader with a MISR space compactor.

Figure 6-2 Encounter Test Compression Options
XOR Compression Macro

Table 6-1 describes the external view of a basic XOR-compression macro configured for a
design with N scan input/output pins and M*N internal scan channels. Where possible, the
pins names and connectivity are very similar to that of OPMISR and OPMISR+. The test input
data is brought in via the N scan input pins and fed the N-wide RSI_SI pins. The M*N wide
decompressed data is fed to the M*N wide internal scan channel heads via the SWBOX_SI
pins. The test response is gathered from the M*N scan channel tails by the SWBOX_SO pins.
The compressed test response is fed back to the tester by the N-wide DSO SO pins. The
control signals SCOMP and SPREAD control the operation of the compression and spreading
operations.

Table 6-1 XOR Compression Macro Pin Connectivity
Pin Name Direction Connection Shareable Purpose

RSI_SI[0:N-1] Input Chip-level With any Source of test data
Scan Input functional top- from tester
receiver level port
DSO_SO[0:N-1] Output Chip-level With any Passes test
Scan Output functional top- response to tester
driver level port
SCOMP Input Chip-level With any Active when output
Test Mode functional top- test response is
control level port. being compressed
Functional
compliance
value=0
SPREAD Input Chip-level With any Active when input
Test Mode functional top- test date is being
control level port. decompressed.
Functional Note that this pin is
compliance optional and will not
value=0 exist when the user
chooses to not use
the XOR-spreader
when creating the
compression macro.
SWBOX_SI[0:M*N-1] Output Head of Not applicable Feeds
internal scan decompressed test
channels stimuli to internal
scan channels
SWBOX_SO[0:M*N-1] Input Tail of Not applicable Feeds
internal scan decompressed test
channels stimuli to internal
scan channels
Table 6-2 describes the additional pins required for X-tolerance using the Channel masking
method described in OPMISR Test Modes in Encounter Test: Guide 2: Testmodes. These
pins and their purpose are identical to that of the OPMISR and OPMISR+ masking logic.

Table 6-2 XOR Compression Macro Pin Connectivity for X-Masking
Pin Name Direction Connection Shareable Purpose

CK Input Chip-level With any Clock to enable
Test clock functional top- loading of mask
level port. data during channel
Functional mask load state
compliance
value=0
CME Input Chip-level With any WIDE1 Mask enable
Test data functional top- data from tester.
input level port Exists only when
WIDE1 masking is
selected.
Operational during
scan load/unload.
One bit per scan
cycle.
CME0, Input Chip-level With any WIDE2 Mask enable
CME1 Test Mode functional top- data from tester.
control level port. Exists only when
WIDE2 masking is
selected. Similar
purpose as above.
CMLE Input Chip-level With any Enables loading of
Test Mode functional top- mask data during
control level port. channel mask load
Functional state.
compliance
value=0
Figure 6-3 on page 126 shows an internal conceptual view of the XOR-Compression Macro.
There are 4 conceptual blocks composed of the XOR-Spreader, XOR-Compactor, Scan
Multiplexing Logic and the optional X-Masking logic.

Figure 6-3 Internal View of XOR-Compression Macro
Modes of Operation
Figure 6-4 on page 127 shows an external view of the XOR Compression Macro. The XOR
compression macro has the following modes of test operation.
1. Compression Mode with both XOR-spreader and XOR-compactor active (See Figure 6-
5 on page 127). This is set up when both SPREAD and SCOMP are active.
2. Compression Mode with scan fanout spreader and XOR-compactor (See Figure 6-6 on
page 128). This is set up when SPREAD is active and SCOMP is inactive. Another
possibility is that the XOR-Compression Macro is configured without the SPREAD pin in
which case this is the only available Compression Mode. In this case the Scan Input pin
X will feed the scan channels connected to scan channels X, X+M, X+2M, X+3M etc.,
where M is the scan fanout.
3. Full-scan mode (see Figure 6-7 on page 128) is established when SCOMP is inactive and
SPREAD is inactive or absent. In this case multiple internal scan channels are
concatenated to form full scan chains. The scan chain X for example will be affiliated with
SCANIN(X), RSI_SI(X), and scan channels X, X+M, X+2M, X+3M... and finally
DSO_SO(X) and SCANOUT(X). Each internal scan channel (i) is affiliated with the pins
SWBOX_SI(i) and SWBOX_SO(i).

Figure 6-4 XOR Compression Macro Connection to I/O Pins and Scan Channels of
Design
Figure 6-5 Compression Mode with Both Spreader and Compactor Active

Figure 6-6 Compression Mode with Scan Fanout and Compactor Active
Figure 6-7 XOR Compression in Full Scan Mode

XOR Compression Design Flow

Figure 6-8 shows the design flow starting from compression macro insertion through ATPG.
Figure 6-8 Design Flow for XOR Compression
XOR Compression Limitations

Consider the following limitations:
The WIDE0 masking option is not allowed for XOR compression. This restriction is
enforced since the extra WIDE0 logic gives no advantage over the no masking option.
With WIDE0 masking, every channel is masked when the mask enable is asserted.
Therefore, no useful data can be obtained from cycles that assert the mask enable.
Unlike MISR compression, that cycles X bits can instead be ignored by the tester. This
makes the no masking option better since it saves the additional mask enable pin and
additional on chip masking logic.

When the numchannels option is not an integer multiple of the numchains option, the
scan chains in FULLSCAN mode may not be balanced since some of the FULLSCAN
chains will contain one more scan channel than the others.
When masking is used, the specified value for numchannels must be at least twice as
large as the specified value for numchains.
There is no (reasonable) upper limit on numchains or numchannels, however, if the
numchannels/numchains multiple is too large, the ability to diagnose the resulting
data will be affected. A warning is issued when this condition occurs.

7
SmartScan Compression Flow

Introduction
Compression Serial and Parallel Interfaces
Compression with Serial Only Interface
Debugging Miscompares in SmartScan Patterns
SmartScan Limitations
Using OPCG with SmartScan Compression
Using External Pipelines with SmartScan Compression
Introduction
Related Topics
convert_smartscan_failures in the Encounter Test: Reference: Commands.
SmartScan Compression in Design For Test in Encounter RTL Compiler Guide
Converting SmartScan Serialized Tester Fail Data to CPP in Encounter Test: Guide
7: Diagnostics
SmartScan is a low pin compression solution that supports as few as 1 scanin and 1 scanout
pin while still allowing a reasonable amount of compression and diagnostics. This is useful for
designs where limited pins are available for testing purposes, For example, when performing
multi-site or system-level testing, the number of contacted test pins can be very limited. An
efficient solution to meeting this requirement is to reduce the number of scanin and scanout
pins on the design.

The following figure gives an overview of the SmartScan compression architecture:
Figure 7-1 SmartScan Compression Architecture
In the SmartScan compression architecture, each scanin feeds an N-bit serial shift register
(also known as Deserializer) and each scanout is similarly fed by an N-bit serial shift register
(also known as Serializer). This is typically known as the Serial interface. To load data into
each channel, the Deserializer first needs to be completely loaded with the test data that
would normally be applied to the Decompressor directly from multiple scanin pins. After the
Deserializer is loaded, the clock to the internal scan chains starts and the test data is shifted
into a channel. On the output side, all the bits within the Serializer simultaneously capture
data from the last flops of the channels and then serially shift it out through a single scanout
pin. The Deserializer and Serializer operations are overlapped such that while new data is
shifted in through the SERIAL_SCAN_IN pin, the response data loaded into the Serializer
(from the scan chains) is simultaneously shifted out through the SERIAL_SCAN_OUT pin.
RTL Compiler supports generation and insertion of the SmartScan compression macro. This
includes the Deserializer and Serializer registers, the clock control logic, and the optional
mask registers. RC also generates the necessary interface files required in the Encounter
Test design flow. Refer to Figure 7-2 on page 134 and Figure 7-4 on page 145 for more
information on these files.

Refer to the Inserting Scan Chain Compression Logic chapter in Design for Test in RTL
Compiler Guide for more information on SmartScan compression architecture and insertion
of SmartScan compression macro.
Encounter Test supports the SmartScan compression inserted by RC for both serial and
parallel interfaces.
Parallel Interface is where several scanin and scanout pins are available and these are
directly connected to the XOR compression network.
Serial only Interface has only a few serial scanin and scanout pins that connect to the
Deserializer and Serializer registers, which in turn are connected to the XOR
compression network.
Compression Serial and Parallel Interfaces

The following figure depicts the design flow for this scenario:

Figure 7-2 Design Flow for SmartScan Compression with Parallel and Serial Interface
netlist with both serial and parallel interface pins
Insert Compression linehold file

RC ignoremeasures file
Macro
SmartScan testmodes
SmartScan description file
Build Model
Build any/all of the following Testmodes:

- compression_smartscan
- compression_decomp_smartscan
- compression
- compression_decomp
- FULLSCAN

ET
Perform ATPG &
Parallel Interface Patterns
Simulate Tests
Convert to Serialized
Patterns Serial Interface Patterns
Write Vectors
Convert Vectors to TDL/WGL/

STIL/Verilog Patterns

In this scenario, the Verilog netlist generated by RC contains several scanin and scanout pins
(parallel interface) for parallel access to the XOR compression network. One or more of these
pins is also shared with the serial interface.
This scenario allows the patterns to be applied either via the Parallel or the Serial interface.
For example, the parallel interface can be used during manufacturing test, while the Serial
interface can be used to apply patterns during system test.
SmartScan Testmodes
With SmartScan compression, RC generates two SmartScan test modes,
compression_smartscan and compression_decomp_smartscan for test generation.
If there is no XOR spreader on the input side, then only the compression_smartscan
testmode is generated.
Two control signals are required for SmartScan operation. These can be PI controlled or can
be internally generated test signals:
SMARTSCAN_ENABLE
Will be at Active High value in SmartScan Testmodes
Inactive value will cause SmartScan flops to be included within the scan chains
SMARTSCAN_PARALLEL_ACCESS
Active High value will select Parallel interface; inactive value selects Serial interface
Performing ATPG
Pattern generation will be done using the Parallel interface, and will be post-processed to also
be applied through the Serial interface.
ATPG Constraints in SmartScan Testmodes
The following constraints must be applied during ATPG in SmartScan testmodes. Faults
untestable due to these constraints will be targeted in non-SmartScan testmodes.
ATPG will not stim Scanins or measure Scanouts during capture cycles
Increases complexity of serialized patterns
No assumption is made as to whether all the scan pins will be contacted when
applying the serialized patterns at the tester or on the board.

Scan Enable must be inactive during capture cycles within Logic Tests
When Scan Enable is Active, SmartScan Controller allows clock to scan chains only
every Nth pulse of the top level clock (CLK)
Will allow Scan Enable being active for first (launch) Pulse in LOS tests
Linehold File
ATPG uses the linehold file generated by RC for SmartScan testmodes. This file must list the
parallel Scan in pins (real or pseudo), the channel mask enable pin (if present, to its inactive
value) and the scan enable pin (to its inactive value) for create_logic_tests.
A sample linehold file is given below:

Hold Pin PSI1 = X;
Hold Pin PSI2 = X;
Hold Pin SE = 0;
Hold Pin CMLE = 0;
Ignoremeasures File
ATPG uses the ignoremeasure file generated by RC for SmartScan testmodes. This file lists
the parallel Scan out pins (real or pseudo) and is used to prevent test generation for data from
SO pins during capture.
A sample ignoremeasures file is given below:

PSO1
PSO2
PSO3
Scan Chain Tests
For SmartScan testmodes, the recommendation is to convert patterns generated by the

create_scanchain_tests command run with the keyword format=simplified. The
scan chain tests generated with this keyword do not contain any explicit scan shifts, which is
not supported for SmartScan designs having external pipelines, pulse width multipliers, or
interleaved clocking.
The scan chain tests generated with this keyword do not use any masking on the first Test
Sequence. This provides a method to debug when chains are not working properly, without
getting the masking logic involved.

Note:
The create_scanchain_tests command will generate multiple test sequences;
only the first test sequence will not have masking and the following ones will have
mask events in them.
In a flow with the SmartScan Serial-only interface, create_scanchain_tests
will default to format=simplified. You can choose to override this by explicitly
specifying format=normal, in which case, the scan patterns can be simulated in
NCSim only after converting them through convert_vectors_to_smartscan.
Converting Parallel Interface Patterns to Serialized Patterns

After pattern generation is complete, the generated parallel patterns are converted into serial
patterns so that they can be applied through the SmartScan interface, that is, using
SERIAL_SCAN_IN and SERIAL_SCAN_OUT pins. This gives the flexibility to apply the
patterns either through parallel or the serial interface. For example, you might want to apply
patterns using parallel interface during manufacturing test and using serial interface during
system test.
The convert_vectors_to_smartscan command requires the following input:

Mandatory
SmartScan description file - this defines serial SI-SO pins and correlate bits of
Serializer/Deserializer registers to the Parallel pins
Optional:
SmartScan sequence file - this is used to set the SMARTSCAN_PARALLEL_ACCESS
signal to zero
Test sequence name - this is the name of the test sequence defined in the
SmartScan initialization sequence file.
Refer to convert_vectors_to_smartscan in the Encounter Test: Reference: Commands for

the syntax of the command.
The following figure shows the changes to the test pattern made by
convert_vectors_to_smartscan:

Figure 7-3 Update to ATPG Pattern by convert_vectors_to_smartscan
Patterns generated by ATPG Patterns after Serialization
Test Sequence(): Test Sequence():

Compressed Input Stream Load_SR
Internal Scan Load Internal Scan Load
Stim PI Stim PI
Pulse PPI Pulse PPI
Measure PO Measure PO
Load Channel Masks Load_SR
Use Channel Masks -- removed --
Diagnostic Scan Unload Diagnostic Scan Unload
Compressed Output Stream Unload_SR
Compressed Input/Output Stream is replaced with Load_SR / Unload_SR, which contain the
serialized data. Loading of the mask registers also is done using the Deserializer.
Note: The Use_Channel_Masks event is removed and the data within it is combined with
the Load_SR of the next Test Sequence. Hence, the converted patterns cannot be reordered,
as the CME data for a Test Sequence is present in the sequence following it.
The pattern generation is done only once, using the many parallel scanin and scanout pins
(called parallel interface). Once these patterns are converted to use the few serial scanin and
scanout pins (called serial interface), the user has the flexibility of using either set of patterns.
Note:
convert_vectors_to_smartscan can convert the scan chain and logic tests
separately, or convert a single experiment where these test sections are appended
together.
convert_vectors_to_smartscan supports conversion of logic tests that were
generated with testreset=yes on the ATPG command line.
SmartScan Initialization Sequence File
For SmartScan testmodes, RC generates a sequence file that sets the

SMARTSCAN_PARALLEL_ACCESS control signal to its inactive value, which implies that the
Deserializer should drive the compression channels. The Scan_Enable signal should also
be set to its inactive value to ensure the SmartScan registers are reset.

The convert_vectors_to_smartscan command prepends the initialization sequence in

the sequence file to the converted test patterns so that the Deserializer and Serializer logic
is used for application of the converted ATPG patterns. Otherwise, the top-level Parallel
Scanin/Scanouts (real or pseudo) would continue to bypass the Deserializer/Serializer
registers and feed the Channels.
Note that this sequence will replace the mode initialization sequence of the SmartScan
testmode. Therefore, this sequence must perform the same operations as the testmode
modeinit sequence, with the exception of setting the SMARTSCAN_PARALLEL_ACCESS,
Scan Enable, and Channel Mask Enable signals to their inactive values.
The initialization sequence must have the attribute smartscan_modeinit and the name of
this sequence must be specified for convert_vectors_to_smartscan through the
testsequence keyword. The following is a sample SmartScan init sequence supplied to
convert_vectors_to_smartscan:
[ Define_Sequence smartscan_initseq 1 (smartscan_modeinit);
"DFT_compression_enable"=1
.......
] Define_Sequence smartscan_initseq 1;
SmartScan Description File
A SmartScan Description file contains information on the SmartScan structures present in the
netlist, that is, mapping of serializer and deserializer flops to the corresponding primary
inputs/outputs. Each bit (flop) in the Deserializer will map to a primary input pin (or pseudo
primary input pin added by edit-model) with test function SI, CME or CMI. Similarly, each bit
of the Serializer will map to a primary output pin or pseudo primary output pin. The file also
provides the mapping between the deserializer/serializer bits and the scan-in/scan-out used
to serially shift data into the deserializer/from the serializer.
The write_et command in RC generates the SmartScan description file in the ASCII
format. When using write_compression_macro to generate the SmartScan macro, this
file must be created manually.
An Update register can also be optionally present between the deserializer and the
decompressor. The update register is also a shift register and is of the same length as the
deserializer register. The SmartScan description file will provide the mapping of flops/bits in
update register with the corresponding primary inputs pins.
The convert_vectors_to_smartscan command uses the SmartScan description file

through the smartscanfile keyword.

SmartScan Description Syntax
The following syntax statements will be supported initially for comments:
Line comments
//
--
Block comments
The block comments can span multiple lines. These are as shown below:
/*block of comments*/ - "/*" to start and "*/" to end block comments.
Comments spanning multiple lines per the following example:

/* comment line1
comment line 2
Comment line 3 */
Header
The SmartScan description file can optionally also have an header present, which can
contain some comments for the user to understand what this file contains. The complete
header will be treated as comment by the parser and it must be enclosed using the line
comments syntax shown above.
SmartScan Macro Version
The SmartScan description file should have the SmartScan macro version specified that is
used to generate this file. The syntax for this is as below:
SMARTSCAN_MACRO_VERSION=<version_number>;
Example:
SMARTSCAN_MACRO_VERSION=1.0;
The SmartScan macro version can start with 1.0 and increment as and when we make
changes to the SmartScan hardware (serializer, deserializer, clock-controller etc) inserted by
the RC. This will help ET understand which version of hardware it is dealing with, if there are
any incremental updates to hardware.

Statement Syntax
A statement would define a serializer, deserializer or an update register and the mapping of
its flop with the primary input (or pseudo primary input) pins. It will have the following syntax:
SMARTSCAN_REG = <Reg_type> {
[Serial_Primary_PIN = <serial_pin_name>;]
REG_BIT_CORRESPONDENCE = (
<Hierarchial_flop_name>, BIT_INDEX =<bit_index>, PIN= <primary_pin_name>;
<Hierarchial_flop_name>, BIT_INDEX =<bit_index>, PIN= <primary_pin_name>;
.
.
)
};
Here:
Reg_type : Specifies the type of register and can be of following types

DESERIALIZER_SHIFT_REG
SERIALIZER_SHIFT_REG
DESERIALIZER_UPDATE_REG
Serial_Primary_PIN : Specifies the primary (or pseudo) input or output pin. This will not
be specified for Reg_type= DESERIALIZER_UPDATE_REG. It can be one of following:
SERIAL_SCAN_IN
SERIAL_SCAN_OUT
serial_pin_name : Name of the top level Serial Scan IN/OUT pin.
Hierarchial_flop_name : Hierarchical name for the flop in the shift register.
The flopname can also be enclosed in double quotes (""), to support names having special
characters or escaped names. The use of double quotes is not mandatory for simple names
which do not have any special characters.
Bit_Index : This specifies the position of flop in the shift register.
For desererializer and update register: In serial mode, the flop closest to SSI pin has bit_index
1 and next closest has bit_index 2 and so on.
For serializer: In serial mode, the flop closest to SSO pin has bit_index 1 and the next closest
flop has bit_index 2 and so on.

Primary_pin_name : Equivalent parallel scan in or scanout pin corresponding to the

specified flop. This is the pin which feeds in the data directly into the corresponding mux.
Statements
The language is case insensitive. Therefore, although the above shows the statement
elements in uppercase, they really can be entered in any case. Note that the names of cells,
instance, pins, etc must be in the same case as they are in the model.
The statement must end with a semicolon (;).
Use of braces '{' and brackets '(' is compulsory as shown above
Use of '=' is mandatory, where needed, as shown in syntax above
Use of comma ',' is mandatory, where needed, as shown in syntax above
The comments may appear any place white space may appear. The white space is either
a blank or a new line character
Test Sequence Name
Typically, the test sequence name is not specified. By default,

convert_vectors_to_smartscan uses a sequence with type smartscan_modeinit.
This sequence can be read in earlier in the Encounter Test flow or during
convert_vectors_to_smartscan by specifying the file containing this sequence using
the sequencefile keyword. If the testsequence keyword is not specified and no
sequence of type smartscan_modeinit is read in, then
convert_vectors_to_smartscan uses the testmode mode initialization sequence
during the conversion process.
The baseline convert_vectors_to_smartscan flow consists of the following command

line:
convert_vectors_to_smartscan testmode=<testmode name> \
inexperiment=<parallel interface input experiment name> \
experiment=<serial SmartScan interface output experiment name> \
smartscanfile=<SmartScan Description File name>
In this baseline flow, a sequence of type smartscan_modeinit is used if it exists,

otherwise, the testmode mode initialization sequence is automatically converted to be used
for the serialized SmartScan patterns. In addition to using this sequence, any SmartScan
Parallel Access pin must be set to the non-stability state to switch to the SmartScan
configuration. To do this, PI and PPI pin names are scanned for the characters PAR followed
by the characters ACCESS (for example, SMARTSCAN_PARALLEL_ACCESS). If found, a
pattern is added to the mode initialization sequence, setting this pin to its non-stability state.

When the SmartScan Parallel Access signal is a Primary Input, the tester directly controls the
signal and automated conversion is typically sufficient. For cases where a custom SmartScan
initialization sequence is necessary, use the sequencefile keyword to define a custom
mode initialization sequence of type smartscan_modeinit to be used during the
conversion process.
The keyword testsequence=none must be specified to override a pre-existing sequence

of type smartscan_modeinit and force the use of testmode mode initialization sequence
during the conversion process.
Some examples are given below:
Example 1
SmartScan Parallel Access signal is a tester contacted PI named

'smartscan_parallel_access' and no custom process is required to initialize the converted
vectors. In this case, keywords sequencefile and testsequence are not required. The
testmode mode initialization sequence will automatically be converted and used in the
converted vectors, and the 'smartscan_parallel_access' PI will be set to its inactive state.
Example 2
SmartScan Parallel Access signal is a PPI named 'smartscan_parallel_access' and is set

internally through a register. In this case, the testmode mode initialization will define how to
set the register and PPI to the Active state. The keyword sequencefile is specified for
convert_vectors_to_smartscan to define a custom mode initialization sequence of
type smartscan_modeinit. This custom sequence will be used during the conversion
process and will define how to set the SmartScan Parallel Access register and PPI to the
inactive state as required for the converted vectors.
Example 3
SmartScan Parallel Access signal is a PPI named 'smartscan_parallel_access' and is tied off
internally within the design to the inactive state as is common for Serial-Only SmartScan
configurations. In this case, the keyword sequencefile and testsequence are not
required. The signal is hard wired on-chip to the correct state for serialized SmartScan
vectors.
Example 4
In the above examples, if the SmartScan Parallel Access PI or PPI name does not have the
characters PAR followed by the characters ACCESS, then the testmode mode initialization
sequence will not be automatically converted. In this case, the keyword sequencefile is
required for convert_vectors_to_smartscan to specify this custom sequence of type
smartscan_modeinit to be used during the conversion process.

Compression with Serial Only Interface

The following figure depicts the design flow for this scenario:

Figure 7-4 Design Flow for SmartScan Compression with Serial Only Interface
netlist with only serial interface pins

editfile
Insert Compression linehold file
RC ignoremeasures file
Macro
SmartScan testmodes
SmartScan description file
Dummy parallel interface with pseudo

Build Model SI/SO pins
Build any/all of the following Testmodes:

- compression_smartscan
- compression_decomp_smartscan
- FULLSCAN

ET
Perform ATPG &
Simulate Tests Parallel Interface Patterns
Convert to Serialized
Patterns
Write Vectors
Convert Vectors to TDL/WGL/

STIL/Verilog Patterns

In this scenario, the RC-generated Verilog netlist contains only few scan pins for the Serial
interface.
While building the model for Encounter Test, the editfile generated by RC is used to add
pseudo SI/SO pins to the model to create a dummy Parallel interface to facilitate test
generation. Build Testmode and test generation assume the presence of N scanin and N
scanout pins (Parallel interface), but only a few of those pins actually exist in the hardware.
The pseudo pins are added by specifying the editfile keyword for build_model.
Pattern generation is done using the Parallel interface and the

convert_vectors_to_smartscan command converts the patterns to be applied through
the Serial interface. The pseudo pins are deleted from the patterns to be used for simulation
and at the tester.
In this case, only serial interface can be used when applying the patterns either at the tester
or on the board.
Debugging Miscompares in SmartScan Patterns

This section provides techniques for debugging SmartScan miscompares in NCsim. Figure
7-5 shows the SmartScan clocking waveforms for a sample design that has 16-bit wide
deserializer/serializer registers and 2-bit long scan chains.
Figure 7-5 Sample SmartScan Clocking Waveforms
This section assumes that FULLSCAN patterns are passing Verilog simulation without any
miscompares. Otherwise, debugging needs to start with the FULLSCAN miscompares. Also,
verify that the SmartScan description file content matches the netlist, especially with pipelines
present, as there is very limited verification support in convert_vectors_to_smartscan
for such scenarios.

Below is the recommended flow and areas to investigate when faced with Verilog simulation
miscompares of the SmartScan converted patterns.
1. Verify that ATPG patterns in the SmartScan testmode(s) are passing parallel Verilog
simulation. If there are failures during parallel Verilog simulation, it is likely due to some
problems either with the generated ATPG patterns or the functional logic and its modeling
in NCsim. These miscompares should be debugged using conventional pattern debug
methods.
2. If the design has a real parallel interface, then first run serial simulation of the ATPG
patterns in the SmartScan testmode(s) (using the real parallel interface). This will ensure
that the compression logic, including masking, is functioning correctly. If these patterns
pass serial simulation, then the debug of the converted patterns can focus primarily on
verifying the operation of the SmartScan logic.
3. Check whether the converted scan chain tests are passing serial simulation. The
recommendation is to create the scan chain tests with format=simplified and then
convert these, as these tests do not contain any explicit scan shifts. The simplified scan
chain tests contain a test sequence where no masking is applied (only contains load and
unload of channel data) and additional test sequences that also include masking events.
4. If the scan chain test without masking fails, then the problem is likely with the SmartScan
initialization sequence, scan shift operation, or pipelines in the design. The failures
should be unrelated to masking or OPCG logic and their converted data.
a. If the scan chain test without masking fails, verify that the SmartScan initialization
sequence (supplied to convert_vectors_to_smartscan) is as expected. The
SmartScan init sequence should match the testmode modeinit sequence, with the
following exceptions:
The SmartScan parallel access signal must be at the opposite of its value in the
testmode modeinit sequence.
The Scan Enable and Channel Mask Load Enable signals must be at their
inactive state at the end of the SmartScan initialization sequence. Ideally, they
should also be at that value at the end of the testmode modeinit sequence.
b. Verify the clocking of the scan flops during simulation. The scan flops must be
clocked once every N cycles, where N is the width of the deserializer register.
c. Similarly, verify the clocking to the pipeline registers on the scan path. Pipelines
between the deserializer (or serializer) and the channels must be clocked similarly
to the scan flops.
d. External pipelines must be clocked during every cycle of the top-level test clock or
of the OPCG load clock (when present). External pipelines must not change state
during the launch-capture cycles.

5. If the scan chain test without masking passes but the chain tests with masking fail, then
the issue is likely with the mask data and/or its loading through the deserializer registers.
a. Convert the patterns with and without the command line option
scanenablereset=yes/no to check if both of these pattern sets pass serial
simulation. Patterns converted with scanenablereset=yes (default) will cause
the SmartScan controller to be reset after loading the mask registers, whereas there
is no such reset when using scanenablereset=no.
b. Verify the clocking of the mask registers during simulation. Similar to the scan flops,
the mask bits should be clocked once every N cycles, where N is the width of the
deserializer register. Similarly, verify the clocking to the pipeline registers on the
mask load path.
6. If all the scan chain tests pass but the logic tests fail, then check the following in the logic
tests.
a. The scan enable signal must be at its inactive state during the launch-capture
cycles. This must have been accomplished either by providing a linehold file during
create_*_tests or specifying a Test Constraint (+/-TC) on the scan enable pin
when building the testmode.
b. Verify that linehold and ignoremeasure files had been provided during
create_*_tests. The linehold file must hold all the scanin pins (except CME) to
X and the Scan Enable and Channel Mask Load Enable signals to their inactive
values. The ignoremeasure file must contain all the scanout pins. If the design has
bi-directional scan pins, then the scanin pins must also be added to the
ignoremeasure file. The bi-directional scanin and scanout pins must be stimmed to
Z in the linehold file. The intent of these files is to ensure the ATPG patterns can be
converted successfully and there is no loss of pattern quality when applied at the
tester.
c. Determine whether all the logic tests are failing or only the ones with masking events
in them.
d. When present, verify the clocking of the OPCG registers during simulation. The
OPCG side-scan flops and pipelines on the OPCG load path must be clocked during
every cycle of the top-level OPCG load clock.
SmartScan Limitations
wide2 masking is not supported for SmartScan architecture.

Launch on Shift (LoS) ATPG may experience a coverage impact in SmartScan

testmodes due to the ATPG constraints in these testmodes. In such cases, Launch on
Capture (LoC) ATPG should be run as a top-off to improve coverage.
Using OPCG with SmartScan Compression

Refer to SmartScan Compression with OPCG in Design For Test in Encounter RTL
Compiler Guide for information on SmartScan and OPCG compression architecture.
Encounter Test supports SmartScan compression inserted with OPCG by RTL Compiler for
both serial and parallel interfaces.
After pattern generation is complete, the convert_vectors_to_smartscan command

translates OPCG setup sequences (for side-scan load) into structure neutral form.
Encounter Test supports smartscan_modeinit sequences that can contain

start_osc() events. The SmartScan parallel access signal is disabled in
smartscan_modeinit. Refer to SmartScan Initialization Sequence File on page 138 for a
sample SmartScan init sequence.
When you specify this SmartScan init sequence to convert_vectors_to_smartscan

through testsequence keyword, the command uses this sequence to initialize the
SmartScan logic.
Using External Pipelines with SmartScan Compression

External pipelines between SmartScan registers and SCAN IN/OUT and CME pins are
supported for the following SmartScan compression scenarios:
SmartScan in serial-only interface
Figure 7-6 Serial-only SmartScan with External Pipelines

In this scenario, external pipelines are present on the serial scan pins only. These pipelines
participate during the Deserializer and Serializer shifting (i.e., when
smartscan_parallel_access = 0) and also during the pattern generation using the
parallel interface (smartscan_parallel_access = 1).
If these pipelines need to be bypassed during pattern generation, they can be bypassed in
the parallel mode by using the smartscan_parallel_access as the select signal for the
bypass Mux around the pipeline.
SmartScan with serial and parallel interface
Figure 7-7 Serial and Parallel Interface SmartScan with External Pipelines
In this scenario, external pipelines are present on the serial scan pins as well as the other
parallel interface pins. All external pipelines will be visible to ATPG if they are not bypassed
in the parallel interface. Only the external pipelines on the path to/from the Deserializer/
Serializer will participate during serial scan shifting.

Use Model for SmartScan with External Pipelines
Figure 7-8 Use Model for SmartScan with External Pipelines
START
Insert SmartScan Compression RC Task
Insert Pipelines in the Design
Build Testmode
Run create_scanchain_tests
format=simplified
Encounter Test Tasks
Run create_logic_*_tests
Run convert_vectors_to_smartscan
Write Vectors
Insert SmartScan Compression
This can be done either manually or by setting compress_scan_chain -compressor

option to smartscan_xor. Refer to Inserting Test Compression Logic in the Design for Test
in Encounter RTL Compiler Guide for more information.
Insert Pipelines in the Design
Edit the netlist to add pipelines wherever required.
Build Testmode
Perform the following tasks before building the testmode:

Add pipeline information using pipeline_depth option to the Assign file. The
pipeline_depth value specified in the pinassign file to build_testmode must
include External pipelines that are visible to ATPG. Here is a sample syntax based on
Figure 7-6:
assign pin=PSI1 test_function=SI, CMI, pipeline_depth=3;
assign pin=PSO1 test_function=SO, pipeline_depth=3;
assign pin=PSI2 test_function=SI, CMI, pipeline_depth=1;
assign pin=PSO2 test_function=SO, pipeline_depth=2;

There may be cases where the external pipelines are bypassed in the parallel mode
(smartscan_parallel_access=1) and only participate during the Deserializer and
Serializer shifting in the serial mode (smartscan_parallel_access=0). In such
cases, such external serial pipelines will not be visible in the testmode or to the test
generation process. To facilitate the successful conversion of the ATPG patterns, the
testmode must be supplied with information about these external serial pipelines so that
the patterns are generated to account for the additional cycles needed to load through
these serial pipelines.
For the scenario mentioned above, use the new keyword
smartscanMaxSerialPipeDepth=<integer> in the Assign file to specify the
maximum pipeline depth on the serial path to the SmartScan registers. This is the
maximum depth between the input and output side.
For example, consider a design where there are four external serial pipelines on the path
from SSI to the Deserializer and six external serial pipelines on the path from Serializer
to the SSO. These pipelines are bypassed in the testmode (that is, where
smartscan_parallel_access=1) but participate in the serial mode of operation
during the shifting of the Deserializer and Serializer registers. In this case, the Assign file
must contain the statement smartscanMaxSerialPipeDepth=6.
For scenarios where the external pipelines also participate in the parallel mode (that is,
visible in the testmode), there is no need to specify this keyword in the Assign file. It
should be sufficient to describe these pipelines in the SmartScan Description file using
the syntax described later (SERIAL_PIPE_DEPTH,
PRE_DESERIALIZER_PIPE_DEPTH, POST_SERIALIZER_PIPE_DEPTH).
Run create_scanchain_tests format=simplified
Run this command to test the scan chain integrity because when external pipelines are
present, the scan chain test patterns cannot be converted with explicit shifting.

Run create_logic_*_tests
Run this command to generate test patterns. The generated patterns will contain padding
data for overscan cycles. Refer to Encounter Test: Reference: Commands for more
information on test generation commands.
Run convert_vectors_to_smartscan
Run this command to convert the parallel patterns produced by ATPG for compression parts
to serial patterns required by the SmartScan architecture. Use the following keywords in the
SmartScan Description File to specify external pipelines:
Specifying external serial pipelines that participate in De/Serializer shift operation -
These pipelines exist on the path from SSI to Deserializer and/or from Serializer to
SSO during the SmartScan serial mode (smartscan_parallel_access=0).
Specify the optional keyword SERIAL_PIPE_DEPTH = <integer>; in
SMARTSCAN_REG statement.
Specifying External pipelines that are visible to Test Generation (pipelines before
Deserializer) - These pipelines exist between the Parallel Scanin pins and the
Deserializer
Specify keyword PRE_DESERIALIZER_PIPE_DEPTH=<integer> on
correspondence pin that has these pipelines
The pipeline depth must NOT include internal pipelines (i.e., between Deserializer
& channels)
Specifying External pipelines that are visible to Test Generation (pipelines after the
Serializer) - These pipelines exist between the Serializer and the Parallel Scanout
pins.
Specify keyword POST_SERIALIZER_PIPE_DEPTH=<integer> on
correspondence pin that has these pipelines.
The pipeline depth must NOT include internal pipelines (i.e., between channels &
Serializer)
Here is the sample description file syntax for the scenario depicted in Figure 7-7.
SMARTSCAN_REG = DESERIALIZER_SHIFT_REG {
SERIAL_SCAN_IN = PSI1;
SERIAL_PIPE_DEPTH = 2;
<Deserializer_flop_name>, BIT_INDEX = 1, PIN= PSI1,
PRE_DESERIALIZER_PIPE_DEPTH = 2 ;
<Deserializer_flop_name>, BIT_INDEX = 2, PIN= PSI2,
PRE_DESERIALIZER_PIPE_DEPTH = 2;


)
};
SMARTSCAN_REG = DESERIALIZER_UPDATE_REG {
<Update_flop_name>, BIT_INDEX = 1, PIN= PSI1;

)
};
SMARTSCAN_REG = SERIALIZER_SHIFT_REG {
SERIAL_SCAN_OUT = PSO1;
<Serializer_flop_name>, BIT_INDEX = 1, PIN= PSO1,
POST_SERIALIZER_PIPE_DEPTH = 1;
<Serializer_flop_name>, BIT_INDEX = 2, PIN= PSO2,
POST_SERIALIZER_PIPE_DEPTH = 1;

)
};
Here is the sample description file syntax for the scenario depicted in Figure 7-6 where
the pipes are bypassed during the parallel mode. Therefore, there are no
pre_deserializer_pipe_depth or post_serializer_pipe_depth keywords.
SMARTSCAN_REG = DESERIALIZER_SHIFT_REG {
SERIAL_SCAN_IN = PSI1;
<Deserializer_flop_name>, BIT_INDEX = 1, PIN= PSI1;
<Deserializer_flop_name>, BIT_INDEX = 2, PIN= PSI2;

)
};
SMARTSCAN_REG = DESERIALIZER_UPDATE_REG {

)
};
SMARTSCAN_REG = SERIALIZER_SHIFT_REG {
SERIAL_SCAN_OUT = PSO1;
<Serializer_flop_name>, BIT_INDEX = 1, PIN= PSO1;
<Serializer_flop_name>, BIT_INDEX = 2, PIN= PSO2;

)
};

Requirements and Limitations for External Pipelines

At the end of loading an overlapped scan pattern, input and output pipelines on serial
path are primed with data for next pattern. The data must not be updated/corrupted
during launch-capture cycles.
Therefore, pipelines should hold state outside the scan and mask load operations, which
can be achieved by gating the pipeline clock with Scan Enable.
Pipeline design and hookup is expected to be correct-by-construction.
If Scan Enable also has '-TC' flag, then presence of TSV-309 indicates incorrect/missing
gating on the pipelines
Without '-TC' flag, TSV assumes 'X' on Scan Enable and hence TSV-309 would likely be
present even though gating may have been implemented correctly
No additional checking done in SmartScan mode of operation
Currently, only syntax check is done for the pipeline related keywords in the SmartScan
description file. The pipeline depths specified in description file are expected to match
the design.
Pattern conversion will ignore the measure on the POST_SERIALIZER_PIPE(s) as they
cannot be measured via the Serializer.
A warning message is issued by convert_vectors if a value other than X is expected
by ATPG on these pipelines.
For SmartScan compression with OPCG, the pipelines on OPCG path must be equal to
or greater than the serial pipelines on path to Deserializer. Also, no pipelines are allowed
before the seral scanin before the branch-off point. These limitations are represented in
the following figure.

Figure 7-9 Pipelines Limitations with SmartScan and OPCG

8
Generating IEEE 1687 (IJTAG) Compliant
Macro Tests
This document covers the following topics:

IJTAG IEEE 1687 Macro Test Generation Flow
Building Encounter Test Model and Testmode(s)
Reading ICL
Migrating PDL Tests
Processing Tester Controlled Clocks Asynchronous to TCK
Processing Tester Controlled Clocks Correlated to TCK
Handling Scan Chains Spread Across Multiple Macros
Assumptions and Limitations
IJTAG IEEE 1687 Macro Test Generation Flow

Cadence support for macro tests in this release is based on the IEEE 1687 v1.71 standards.

Generating IEEE 1687 (IJTAG) Compliant Macro Tests
The process flow for IJTAG IEEE 1687 compliant macro test generation is shown in the
following figure:
Figure 8-1 IJTAG Macro Test Generation Flow
Building Encounter Test Model and Testmode(s)

The Encounter Test model can be built using either a complete netlist or a partial netlist. The
logic included in the netlist should resemble that in the Instrument Connectivity Language
(ICL) file and should be sufficient to ensure that an IEEE 1149.1 (the primary test access
mechanism that is specified in 1687) or Fullscan ATPG-compatible testmode (alternate
access method) can be built and verified.

information.
For building the testmode, the mode initialization (modeinit) sequence, which is provided by
the user in the mode initialization file, starts the reference oscillator(s), initializes fixed value
registers and sets other such constraints that stay constant for the testmode that is
generated.
Refer to Performing Build Test Mode in Encounter Test: Guide 2: Testmodes for
additional information.
A sample mode initialization file is shown below:

[ Define_Sequence Mode_Initialization_Sequence 1 (modeinit);
# Compliance Enable and JTAG Pins
"BURNIN_RUN"=0
"MBIST_DEVICE_SCHEDULE_SERIAL"=0
"MBIST_ENGINE_SCHEDULE_SERIAL"=0
"PMDA_MBIST_DEVICE_SCHEDULE_SERIAL"=0
"PMDA_MBIST_ENGINE_SCHEDULE_SERIAL"=0
"PMDA_RESET"=1
"PMDA_TCK"=0
"PMDA_TDI"=0
"POWERON_RUN"=0
"SCAN_ENABLE"=0
"TEST_MODE"=0
"ref_clkc"=0
"ref_clkd"=0
"TCK"=0
"TMS"=0
"TRST_N"=1
"ref_clka"=0
"ref_clkb"=0
;
] Pattern 1.1;
#**************************************************************
#* Initializing dft_configuration_mode_pins
#**************************************************************
[ Pattern 1.1.1.1.1.2;
Event 1.1.1.1.1.2.1 Stim_PI ():
"SCAN_ENABLE"=0;
] Pattern 1.1.1.1.1.2;
[ Pattern 1.1.1.1.1.3;
Event 1.1.1.1.1.3.1 Stim_PI ():
"TEST_MODE"=0;
] Pattern 1.1.1.1.1.3;
Event 1.3.1
Start_Osc (up 3.906ns, down 3.906ns): "I_CU_REFCLK_P"=+;
] Pattern 1.3;
## Wait for PLL to lock
## 1000*10ns
Event 1.3.1

Wait_Osc (cycles=100,off): "I_CU_REFCLK_P";

] Pattern 1.3;
#***************************************************************
#* Starting Chip Reset - Place Custom Reset Below this Point
#***************************************************************
"TMS"=1 ;
Event 1.5.2 Stim_PI (): # TRST Reset ON
"TRST_N"=0 ;
] Pattern 1.5;
Event 1.6.1 Stim_PI (): # TRST Reset OFF"TRST_N"=1 ;
] Pattern 1.6;
[ Pattern 1.7;
"PMDA_RESET"=1 ;
] Pattern 1.7;
#**********************************************************
#* Ending Chip Reset - Place Custom Reset Above this Point
#**********************************************************
[ Pattern 1.8;
"TMS"=0 ;
Event 1.8.2 Pulse (): # Run-Test-Idle
"TCK"=+ ;
] Pattern 1.8;
] Define_Sequence Mode_Initialization_Sequence 1;
Note: For TAP-based design, the modeinit sequence should end in the Run-Test-Idle TAP
state. It is not required that the ScanRegisters in the ICL be defined as scan chains in these
testmodes. The access and operations of these ScanRegisters are inferred from the ICL files.
Refer to Correlation between ICL, PDL, MIPD and IJTAG Description Files on page 180 for
more information.
The corresponding 1149.1 testmode assign file may look like:

assign pin=TDI test_function=TDI;
assign pin=TDO test_function=TDO;
assign pin=TMS test_function=TMS;
assign pin=TCK test_function=-TCK;
assign pin=TRST_N test_function=+TRST;
assign pin=SCAN_ENABLE test_function=-TI;
assign pin=TEST_MODE test_function=-TI;
assign pin=ref_clka test_function=-ES ;
assign pin=ref_clkb test_function=-ES ;
assign pin=PMDA_TCK test_function=-ES;
assign pin= I_CU_REFCLK_P test_function=-OSC;
Reading ICL
The read_icl command parses the input ICL files and generates the Macro Isolation
Database (MIPD) files.

Note: All ICL constructs and keywords listed in 1687/v1.71 standard are not supported in the
current release. Refer to Assumptions and Limitations on page 193 for the list of constructs
that are not currently supported.
If you specify multiple ICL files (as comma-separated list) through the iclfile keyword,
each file is parsed individually and then processed by read_icl to generate a single MIPD
file.
Refer to read_icl -H or man read_icl for information on command syntax and supported
options.
The output MIPD file is generated in the tbdata directory and is named as follows:
mipd.<testModeName> if testmode is specified
mipd if testmode is not specified
The key steps in the ICL parsing and analysis done by the read_icl command are as
follows:
Perform syntax checks on the ICL files.
Ensure ICL complies with the semantic rules specified in the 1687 specification
document.
Identify the macros/instruments in the ICL that will participate in the PDL retargeting.
This is done as all modules defined in ICL are assumed as macros. Information about
these macros is then saved in MIPD. A macro instance can belong to multiple
ALGORITHMs.
Gather all ScanInterfaces defined in the ICL. Each chip-level ScanInterface is a means
to access internal registers. ScanInterfaces are required to be defined and act as the
starting point for ICL processing for generating operations.
The scanInterface must be defined explicitly in the ICL file. Implicit scanInterfaces are not
supported in the current release.
Parse the AccessLink statement and associate BSDL instruction names with
ScanInterfaces.
Extract correspondence for different port types on the macro instances. Correspondence
can be only to a chip-level IO.
Establish data correspondence for ports of type DataInPort and DataOutPort.

Correspondence for ports of type ShiftEnPort, SelectPort, ScanInPort, ScanOutPort

and TCKPort is needed for establishing scanop sequence and a scan path so a
scanRegister can be accessed from chip IOs.
Extract Scan Preconditioning sequence to activate ScanRegister between TDI (ScanIn)
and TDO (ScanOut) ports. For TAP-based design, this requires stepping through the TAP
protocol to load the instruction opcode into the JTAG IR to activate the ScanInterface.
Parsing of constructs such as ScanMux will be important for this step. For non-TAP
designs, the sequences will consist of controlling PIs such as ShiftEnPorts and
SelectPorts.
Extract from the ICL and define the Pingroups based on ICL port definitions and
ScanRegisters. Pingroups are represented as macro/instance specific objects.
Extract from the ICL and define the Operations against each Macro instance. MIPD
operations are defined with one-to-one mapping with ScanInterfaces.
The following checks for ICL consistency:
Verify access to instrument ports/registers from chip-level ICL. A warning is issued
if the instrument data and scan ports are not connected at chip level.
Whether chip-level ICL refers to non-existent ports on instrument ICL definition.
ActiveSignals should be explicitly mentioned in the AccessLink statement of the
ICL. An error is generated if there is no ActiveSignals defined.
Note:
While the read_icl command does not require the Encounter Test model
(build_model) to process the ICL and extract the structures and sequences, it is
recommended that a production environment follows the flow as represented in Figure 8-
1 on page 158.
For a given testmode, the ICL model will be (optionally) verified to be an accurate
representation of the Encounter Test test model (netlist). The propagation of the
testmode stability state should result in some paths being sensitized. These paths, along
with the general structure of the ICL, are verified to be a valid abstraction of the chip
design. As a preliminary check, it is verified that for each ICL instrument, there is a
corresponding module in the netlist. The instrument instance name should match the
netlist instance name (including hierarchy). The top level port names at the chip should
also match the ones defined in the model.

Handling ScanInterfaces and ScanRegisters
While in traditional Macro Test, the sequence to operate a scan chain is defined or derived as
part of building the testmode, in IJTAG, the sequences to operate ICL scanRegisters are
derived from analysis of the ICL file. For each scanInterface consisting of one or more
scanRegisters, its scan sequence contains the following steps:
Scan Preconditioning Sequence that sets up access to the scanRegister and puts it in
shift mode of operation. For example, this may involve loading the TAP with an instruction
to select the scanRegister and then moving to the Shift-DR state. For non-TAP designs,
this may be simply setting the shift enable signal to its active value.
Scan Sequence that performs an overlapped load/unload of the data for the register.
Scan Exit Sequence that returns back to a stability state. For example, this may involve
moving the TAP back to Run-Test-Idle. For non-TAP designs, the shift enable would be
set to its stability value.
Handling of ScanInterfaces requires the following information to be passed to the pattern

generation engine from ICL:
Preconditioning information consisting of TAP instruction name to get the scan register
in the active path.
The top level SI and SO pins for read and write (TDI and TDO in case of TAP).
The length of the scan register/scan path.
If there are multiple ScanRegisters in series within the same ScanInterface, the
information on the order in which these ScanRegisters are encountered and the one that
is nearest to SI pin and the one nearest to SO pin is needed to reconstruct the scan chain
in pattern generation engine.
The following is a sample MIPD syntax generated by read_icl:

MACRO = Macro_Instance_Name[, , Macro_Instance_Name];
[GROUP = GROUP_NUMBER;]
OPERATION = Operation_Name;
PINGROUPS = Pingroup_Name[, Pingroup_Name];
CORRESPONDENCE = (
Macro_pin = Entity, INVERSION = in_value;
[; Macro_pin = Entity, INVERSION = in_value;]
)
SCANPRECONDITIONING = (
Entity = Value ;
[ ; Entity = Value ;]
)
SCANSEQUENCE = (
CLK_port = Entity;
CHAIN {
SI_port = Entity;
SO_port = Entity;

SCANLENGTH = Length;
}
[CHAIN {

}]
)
SCANEXIT = (
Entity = Value ;
[ ; Entity = Value ;]
)
The SCANPRECONDITIONING section has the following features:

Allows sequential execution of events: The order in which pins are specified in this
section will be honored and the events for assigning values/pulses, will be executed
in that order.
Allows pulse events to be specified in this section: A clock pin can be specified with
value equal to Pulse.
The SCANSEQUENCE section contains the following:
CLK_port: Specifies the scan clock port at the chip level that needs to be pulsed
for each scan shift.
Chain : This keyword denotes a scan chain and provides the following data:
ScanLength : Provides the complete length (in the current scan interface) of
the specified chain and in between the specified SI and SO pins.
SI_port : Provides the SI/TDI pin at the chip level.
SO_port : Provides the SO/TDO pin at the chip level.
A scan interface can contain multiple CHAIN keywords each representing a separate
scan chain.
There can be one or more Chain statements in the ScanSequence section.
Caution
Support for multiple CHAIN keywords has not been tested for the current
release.
SCANEXIT :
This will provide the ScanExit sequence that takes the register out of shift state and
returns back to stability state. The syntax is similar to a Scanpreconditioning
statement.

All the ports specified with ENTITY are retargeted ports. Encounter Test finds the
appropriate chip-level ports for the macro pins specified in the ScanInterface statements
in ICL and writes the same in MIPD.
Entries in square parenthesis [ and ] are optional.
Use of semicolons and brackets, as shown, is mandatory. All keywords are case
insensitive.
Handling AccessLinks
The Scanpreconditioning section Entity contains the special keyword AccessLink with
the following syntax:
AccessLink.<EntityName>.<InstructionName>.<ScanInterfaceName>.<ActiveSignalName>
Here AccessLink is a keyword and EntityName, InstructionName,

ScanInterfaceName and the ActiveSignalName are as defined in the AcccessLink
syntax for ICL in IEEE 1687 specification.
The InstructionName will specify the TAP instruction name that, when loaded in the TAP,
will make the specified ActiveSignal true. Note that < and > are explicit and mandatory
delimiters in the syntax of the above statement.
Performing 1687 Verification Checks
Specify verify=yes on read_icl command line to run the following 1687 verification
checks that detect any issues with the input ICL and ensure that the input correlates with the
netlist.
For each module in ICL, there is a corresponding module in the netlist.
Require that the ICL instance name matches the netlist instance name (including
hierarchy).
After processing the ICL, the tool constructs the full hierarchal instance name as
specified in ICL for each of the macro instances. It then accesses the Encounter Test
model for each of these instances and matches the name with the netlist. If the tool does
not find a matching name, a warning is issued and no MIPD is generated for the specific
instance. This will result in an appropriate error/warning message being issued from
migrate_pdl_tests if you try to read/write this macro pins via the PDL.
For each DataInPort and DataOutPort in the ICL, there is a corresponding pin on the
corresponding module in the netlist.

The full hierarchal names of the DataInPort and DataOutPort as constructed from ICL,
are matched with the Encounter Test model.
If the specified name of the port is not found in the model, the tool issues a warning
message and the specified ports shall be removed from the portGroup for the
<module_name>_IO operation of the corresponding module. This implies that the
PDL cannot read/write data at these ports and an appropriate error/warning is issued if
you try to do so.
For the path from a chip IO to an instrument in the ICL, there must be a sensitized path
from the same IO to the same pin on the corresponding netlist instance.
After generating the correspondence information for each of the DataInPorts and
DataOutPorts defined in ICL, the tool verifies the correspondence by simulating the
design in Encounter Test. High Speed Scan simulator is used to set up the modeinit state
from the testmode and apply any preconditioning, if available, for the operation. The tool
then simulates a value of 0/1 at the top-level chip pin and checks for the corresponding
value at the corresponding macro pin. If the values do not match, a warning message is
issued and the macro pin is removed from the correspondence statement for the specific
operation. Subsequently, you will not able to read/write to these pins via PDL; an error is
generated for migrate_pdl_tests command if you try to do so.
Note:
Currently, the tool only checks whether a pin really corresponds to a top-level chip
pin or not. In case of warnings, you will need to debug the issue manually using the
Encounter Test GUI - open the GUI, set up the testmode after simulating the
modeinit, and then simulate a value of 0/1 at the top-level pin. Then manually trace
back the path in the GUI for the logic cone feeding the specific pin and check what
is preventing the pin to correspond to the top-level pin.
Currently, the verification check is done only for DataInPort and DataOutPort. The
scan related ports and TCKPort are assumed to be verified using BSV.
The attribute REQUIRE_HI can be specified in ICL at the chip IOs or an instance pin level
to identify pins that must be at a constant value 1 in the testmode. This check verifies
whether the specified macro pin is at a constant high value at the test mode stability
state.
The syntax for this attribute is:
Attribute REQUIRE_HI = "YES";
This attribute is only supported on DataInPort port types.

The REQUIRE_HI attribute is only meant for verification, and if the specified pin
is not at the constant value of 1, a warning is issued.

If a macro pin is specified with this attribute, the pin will not be processed for
correspondence generation for the specified macro instance and will not be written in the
mipd for the <moduleName>_IO operation. You will not be able to read/write to this
macro pin via PDL.
The attribute REQUIRE_LO can be specified in ICL to identify pins that must be at a
constant value 0 in the testmode. The support for this check is similar to the check for the
REQUIRE_HI attribute discussed above. The only difference is that the pin will be
checked for a value of 0 instead of 1 at the testmode stability state.
Syntax for this attribute is:
Attribute REQUIRE_LO = "YES";
This attribute is only supported on DataInPort port types.
Migrating PDL Tests

The migrate_pdl_tests command maps the existing test vectors defined in the user-
specified Procedural Description Language (PDL) file for an embedded macro/core to the
device under test. This command generates chip-level patterns in TBDbin format that are
converted to tester format patterns using write_vectors.
Refer to PDL file for more information on the syntax of the PDL file and the supported PDL
functions.
The command also takes the MIPD file (generated by read_icl) and the IJTAG description
file as input.
The IJTAG description file, provided through the descfile keyword, contains the BSDL
opcodes for each JTAG instruction referenced by AccessLink, the TAP port information, and
Algorithm information. This avoids the need to have a BSDL file available at the time of pattern
retargeting. Refer to IJTAG Description File for information on the syntax of the IJTAG file.
Refer to migrate_pdl_tests -H or man migrate_pdl_tests for information on

command syntax and supported options.
This command computes and maintains the effective scope as each PDL statement is
processed. This ensures that iCalls are executed with respect to the current scope.
Additionally, this also facilitates instance specific Pingroup naming.
An iRead/iWrite to ScanRegisters is represented in the generated TBDbin vectors as a serial

operation that first applies the TAP sequence to set up the access to the register, followed by
loading of the register itself. The patterns generated by this command are, therefore, serial in
nature and all events are at the chip IOs instead of internal latches.

Parallel simulation of the generated patterns is not possible. Refer to Format of Migrated
TBDbin Patterns for information on the format of the migrated patterns.
IJTAG Description File
The IJTAG description file consists of the following elements:

Algorithm - This specifies the name of the entry point function in the PDL file.
Syntax:
Algorithm <PDL_Entry_iProcName>;
Here Algorithm is the keyword and PDL_Entry_iProcName represents the actual

name of the entry point function in the PDL file.
The Algorithm name must match the name of a root-level iProc in the PDL. In the re-
targeted patterns, the mode initialization is applied prior to execution of each
Algorithm in the TBDbin.
If there is a need for multiple entry point functions, then each of these functions needs to
be specified in separate ALGORITHM statements.
For example:
Algorithm entry_iproc1;
Algorithm entry_iproc2;
The entry-level scope is always the chip and for each ALGORITHM statement, the
process restarts from the modeinit and a new tester loop is generated for each of the
algorithms.
TAP Instruction Opcode - This identifies the opcode for the valid TAP instruction
names specified in the AccessLink statement in the ICL file.
Syntax:
TAP_INSTRUCTION_OPCODE {
<INSTRUCTION_NAME> = <OPCODE>;
<INSTRUCTION_NAME> = <OPCODE>;

}
TAP_INSTRUCTION_OPCODE : This is a required keyword and is not case sensitive.

INSTRUCTION_NAME : Specify the TAP instruction name. This name should match the
instruction name specified in the AccessLink statement in the ICL file.

OPCODE : This is the opcode, which when loaded in the TAP, will enable the specified
instruction. This is a binary value and the length should be the same for all the opcodes
specified. This length should be equal to the length of the instruction register.
TAP Port Identification - The TAP port identification statements define the TAP ports
of the device.
Syntax:
TAP_PORTS {
TAP_SCAN_IN = <TDI port name>;
TAP_SCAN_OUT = <TDO port name>;
TAP_SCAN_MODE = <TMS port name>;
TAP_SCAN_CLK = <TCK port name>;
[TAP_SCAN_RESET = <TRST port name>;]
}
Here TAP_PORTS, TAP_SCAN_IN, TAP_SCAN_MODE, TAP_SCAN_OUT,

TAP_SCAN_CLK, TAP_SCAN_RESET are keywords.
TDI port name : name of the chip-level port for the TDI pin that goes into the TDI pin
of the TAP.
TDO port name : This is the name of the chip-level port for the TDO pin that comes
from the TDO pin of the TAP.
TMS port name : This is the name of the chip-level port for the TMS pin that goes into
the TMS pin of the TAP.
TCK port name : This is the name of the chip-level port for the test clock pin.
TRST port name : This is the name of the reset port at the chip-level that feeds into
the TRST pin of the TAP. This is optional if the TAP does not have a TRST pin.
Note:
All keywords are case insensitive.
Presence of comma, semicolon, and parenthesis is mandatory as shown in the
syntax.
Comment Syntax
The following syntax statements are supported for comments:
Line comments:
//
--
#
Block comments:

The block comments can span multiple lines. These are as shown below:
/*block of comments*/ - "/*" to start and "*/" to end block comments.
Comments spanning multiple lines per the following example:

/* comment line1
comment line 2
comment line 3 */
Sample IJTAG Description File

Algorithm myPDLentry1;
Algorithm myPDLentry2;
TAP_INSTRUCTION_OPCODE {
PARALLEL = 0111;
SERIAL = 0101;
STATUS = 0001;
GLOBALSTATUS = 0011;
ECIDACCESS = 1001;
}
TAP_PORTS {
TAP_SCAN_IN = JTAG_TDI;
TAP_SCAN_OUT = JTAG_TDO;
TAP_SCAN_MODE = JTAG_TMS;
TAP_SCAN_CLK = JTAG_TCK ;
TAP_SCAN_RESET = JTAG_TRST;
}
PDL file
A PDL file contains procedures to apply test patterns for the macro. The pattern retargeting
engine reads this data and migrates these test patterns at the SoC level.
You can specify a single or multiple PDL files (as comma-separated list) as input to
migrate_pdl_tests through the pdlfile keyword. If you specify multiple PDL files, each
of those files will be parsed individually and then the iProc name specified with the algorithm
(entry level iProc) will be called.
The iProcsForModule statement carries over the scope from one PDL file to another PDL
file. It is, therefore, recommended to specify one iProcsForModule at the top of every PDL
file. It is also recommended to first specify any PDL file carrying global variables that are
referenced by other PDL files.
PDL files also support the source keyword of TCL. Using this keyword, a PDL file can include
the code from another PDL file. For example:
source b.pdl

This command will source all code written in b.pdl file in the current PDL file.
However, if the source keyword is used, it is not possible to specify individual time stamps
separately for the sourced files. This can only be specified in the files that are provided
separately to migrate_pdl_tests.
Encounter Test supports the following PDL commands in the current release.
Supported PDL Commands

Note: Refer to the IEEE 1687 v1.71 standard for more information on the commands
mentioned in this section.
Encounter Test currently supports the following PDL commands:

iApply
iCall
iClock
iDefault
iNote
iProcsForModule
iProc
iPutMsg
iRead
iRunLoop
iWrite
iApply
This command applies the values previously defined by either iWrite and/or iRead
commands to the hardware.
Syntax:
iApply [-group operationName]
group: This is optional and can be used to specify the name of the operation
operationName: It is the name of operation as specified in the MIPD file

If verbose=yes is specified, the command output prints the name of operation that has been
executed for each of the command instance. This helps identify the operation that is currently
executed, in case there are multiple matching operations.
If you do not specify the -group option, the set of macro ports that are read or written to
before the iApply command are identified and matched to an available operation. The first
operation that matches is executed to generate retargeted patterns for the specified ports.
If the tool is unable to match the ports with any of the available operations, it issues an
appropriate error message and you can try using the -group option to explicitly provide the
operation name. An example:
iApply -group Chip_IO;
Note:
If multiple operations match a set of ports, there will be no optimization and the first
matched operation will be executed.
The iApply command cannot be used for clock operations. Use the PDL command
iRunLoop to generate pulses on functional or test clocks.
An empty iApply command without any preceding unprocessed iRead or iWrite
commands will generate appropriate warning messages.
Currently, reading/writing to ports of multiple macros within a single iApply (Operation)
is not supported. You need to add iApply statements after reading and writing to
individual macro ports.
Reading and writing macro I/O ports and scan registers cannot be combined within a
single iApply, as there are different operations for I/O and scan. You need to provide
them as part of separate iApply commands.
iCall
This command provides a mechanism to invoke an iProc from within another iProc. While an
argument can be passed to the iProc, there is no way to return an argument.
Syntax:
iCall[instanceName].procName (arguments)*
procName: The name of the iProc to be called
arguments: Space separated list of parameters to be passed to the called iProc
instanceName: Proper name for the macro instance, for which the PDL commands in the
called iProc should be executed. The macro instance name must exist in the Encounter Test
model.

Note: If an iProc is called using an iCall with an instanceName parameter, the

subsequent commands within that iProc will apply only to the specified macro instance
name. If there are hierarchical iCalls (nested iCalls) and each one is called with its own
instanceName, then the inner iCall will honor the instanceName already specified in the
parent iCall and append this name to any instanceName specified within the nested
iCall.
If a macro instance name is not specified and no current scope is available, the commands
within the called iProc will be executed at the chip-level scope. The default scope is assumed
to be of chip-level macro.
Example:
iCall myproc 10 # calling iProc with name myproc and
# argument 10.
iCall shorty # calling iProc with the name shorty
iCall srt.bdabistgrp12_13.shorty # calling shorty only for
#macro instance
#srt.bdabistgrp12_13
iClock
This command specifies that a system clock is to be running and verifies that the clock port
has a valid controlled source.
Syntax:
iClock <clk_port_name>
Here clk_port_name is the name of the port at the macro level. The macro-level name for
the port shall come via the current scoping. Use the PDL commands iProcForModule and
iCalls to specify the correct scoping in PDL for this command.
Example:
ICL:
ClockPort MySclk {
Source ClockIn;
}
PDL:
iClock MySclk
In this case, the iClock command verifies that the read_icl command has resolved the
macro clock port to its chip-level clock port and has generated a SCK operation that contains
the specified macro clock port. If there is no such operation, the tool will issue a warning

message specifying that the macro clock cannot be pulsed in PDL as its correspondence is
not resolved.
Only clocks which successfully passed this iClock check can be referenced by the -sck
option in the iRunLoop command.
iDefault
This command resets the previously stored value for the pins. This resets the internal tables
of stimuli to allow the full set of primary input and latch patterns to be generated.
Syntax:
iDefault
This command does not have any parameters.
Example:
iDefault # This calls MTGResetStims() in PDL
iNote
This command passes free-form information to the runtime environment. The information is
stored as keyed data in the generated patterns.
Syntax:
iNote [tbdlevel] [keydata] text;
tbdlevel: Optional. Can have the values TESTERLOOP, TESTPROCEDURE, or

TESTSEQUENCE. Other values will be ignored. The default will be TESTSEQUENCE.
keydata: Optional. Can be a string of characters and will default to IJTAG_NOTE, if not
specified.
text: Required. Can be a string of characters, should be enclosed within quotes if contains
whitespace or special characters.
Note: Specify either only one (that is, text) or all values to the command.
Example:
# Will add keyed data of ALGORITHM_TYPE=PLLLIB on the Tester_Loop # level of
vector data
iNote "TESTERLOOP" "ALGORITHM_TYPE" "PLLLIB";
# Will add keyed data of IJTAG_NOTE= iApply for Write to memory on the #
Test_Sequence level.

iNote iApply for Write to memory
iProcsForModule
This command is used to specify the ICL module with which the subsequent iProc
statements are associated. Include this command at the top of the file defining the iProc
statements for a given instrument.
Syntax:
iProcsForModule moduleName
moduleName: The module name as defined in Verilog and should be present in the
Encounter Test model.
Note: For the current release, specifying the namespace before the module name, as
mentioned in the IEEE 1687 v1.71 standard, is not supported.
Example:
iProcsForModule MbistModule; # MbistModule is the name of the module
iProc
This command identifies the name of the procedure and, optionally, lists any arguments
included as variables in the procedure. The iProc names should be unique for the targeted
module/instrument; if they are not, only the last definition is kept.
Syntax:
iProc procName '{' arguments* '}' '{'commands+'}'
procName: This is a unique name that identifies the iProc
arguments: Space separated ordered list. A pair of arguments enclosed within braces will
constitute an argument and the associated default. Arguments without a default value must
be listed before those with a default value.
commands+: Valid PDL or TCL commands
Example:
iProc myproc {arg1 arg2 { arg3 24 } { arg4 0x32 } { arg5 1024 } {
.
}
iProc myproc2 { } {
. . .
}

The myproc procedure has five arguments: arg1, arg2, arg3, arg4, and arg5. The last
three arguments have defaults of 24, 0x32, and 1024, respectively.
Each argument defined for an iProc can have an optional default value; however, once you
define an argument with a default, it is mandatory to define defaults for all the subsequent
arguments.
For iCall invocations, arguments are passed in the order they appear in the iProc
command. If the arguments include a default, they can be omitted from an iCall statement.
Once an iCall command omits an argument, all of the remaining arguments should be
omitted as well.
iPutMsg
This command issues a message during the PDL execution and checks the severity code to
determine whether processing should be terminated for a macro or a macro group.
Syntax:
iPutMsg [messageNumber] [severityCode] text;
messageNumber: Optional. Default is 1. Specify a number less than 1000. The number is
appended to the prefix PDL to create a standard format Encounter Test message number (for
example, PDL-001).
severityCode: Optional. Specify one of the following for the severity code: I for
informational messages, W for warning messages, and S for messages that indicate the
processing for the current macro or group should be stopped. Default is I (Informational).
text: Required. Specify a quoted character string for the message text.
Note: Specify either only one (that is, text) or all values to the command.
Example:
# Will print to log file WARNING (PDL-002): Expect only one macro. [end #
PDL_002].
iPutMsg 2 W Expect only one macro.
# Will print to log file INFO (PDL-001): Expect only one macro. [end PDL_001].
iPutMsg Expect only one macro.
iRead
This command defines data to be observed and shifted out of the macro during a subsequent
iApply command. Multiple iRead commands can be entered prior to an iApply command.
However, if those commands refer to the same pinGroup, the expected values of the previous
commands will be overwritten.

Note: iReads specified between two consecutive iApplies should belong to the same
operation.
Syntax:
iRead reg_or_port_name value
where reg_or_port_name is defined as:

[InstanceName.] pinGroupName
Note: reg_or_port_name is subject to the effective scope (effprefix), if any, of the

command, which is prefixed to its name.
InstanceName: Optional. The pingroup along with its instance or block name. For example,
iRead INSTR3.TDR3 0101
pinGroupName: A valid pinGroup name as specified in the MIPD file. This name should
match the name of a pin or scanRegister in the ICL. You have to specify the entire bus or
register for pinGroupName and not a partial bit range.
value: A string value, either in binary, hex, or integer format, which specifies the data for
each pin in the pinGroup. The following prefix will define how the value will be interpreted:
Binary Value Prefix: 0b, b, or Lb # L is the length of the value string
Hex Value Prefix : 0h, 0x, h, or Lh # L is the length of the value string
NoPrefix: The default format for value is assumed to be integer
If the binary equivalent of the value string has less width than the number of pins in the
pinGroup, rest of the bits will be filled automatically, as below:
Under-sizing an unsized value will result in the assignment of the specified bit values to
the LSBs of the associated pinGroup, with the unspecified most significant bits being
assigned either a 0 or x depending on the most significant bit of the assigned value. If
the MSB is x, then the unspecified bits will be assigned x; otherwise, they will be
assigned 0.
Over-specifying a value or mismatch of the size will result in an error.
Note: The default format for value is integer. However, if the specified string for value has the
same length as the number of pins in the specified pinGroup, then as an exception the format
is assumed as binary and an INFO message for the same is printed.
Example:
Assume the pingroup MYREG is of length 10

iRead myreg 'b010X0Z01; # zero-filled to: 00010x0Z01

iRead myinst.myreg 0b11; # zero-filled to: 0b0000000011
iRead myreg 'hFxd; # Error: Does not fit myreg
iRead myreg 9 # default treated as int
iRead myreg 10b0 # equivalent to: 0000000000
iRunLoop
This command runs the loop for the specified number of times for the pulse on a clock pin
specified in the pingroups of the specific operation.
Syntax:
iRunLoop <cycleCount>['-tck'|'-sck' port][-group operationName]
cycleCount: This is a required option and should be specified as an unsigned integer

value greater than 0. It identifies the number of times the pulse should be applied. This
count results in repeating the pattern for the specified count.
-tck: This is the default option that is used to pulse the test clock port. If neither tck
nor sck option is specified, the tck option is assumed and test clock is pulsed for the
specified number of times.
-sck: This option is specified to pulse the functional or system clock to the module. The
port option is mandatory if sck is specified.
port: This option specifies the macro port name for the system clock that was specified
via the iClock command.
group: This is optional and identifies the operation name
operationName: This is the name of operation as specified in the MIPD file
Examples:
iRunLoop 20 // Pulse TCKPort of the macro 20 times
iRunLoop 10 sck MySclk // Pulse the top-level pin corresponding to macro clock pin
MySclk 10 times
iRunLoop 10 -group counter_TCK // Explicit call to operation counter_TCK for the
macro, to pulse 10 times
Note:
1. The group option is used to identify an operation name, which should be defined as a
normal operation with its associated pingroups, correspondence, and preconditioning, in
the MIPD file.
Example:
OPERATION = pulseClk;
PINGROUPS = PULSE_CLK;

CORRESPONDENCE = (
"c4_dmi_refck_p" = "c4_dmi_refck_p", INVERSION = 0;
)
PRECONDITIONING = ( # needed for PULSE_CLK
"c4_mb0_clk_p(0)"=1;
)
2. When the functional clocks are pulsed via the iRunLoop command, TCK will be in its off
state and patterns will not pulse TCK during this time. This is accomplished by keeping
separate operations for TCK and SCK clocks.
3. The functional clocks must be described in the PDL via the iClock command before
using them in the iRunLoop command.
iWrite
This command defines new data for the pins specified in the pinGroup, which will be
controlled through the scan path or primary inputs during a subsequent iApply command.
Multiple iWrite commands can be specified prior to an iApply command. However, if
those commands refer to the same pinGroup, the expected values of the previous commands
will be overwritten.
Note: iWrite specified between two consecutive iApplies should belong to the same
operation.
Syntax:
iwrite reg_or_port_name value
where reg_or_port_name is defined as:

[InstanceName.] pinGroupName
Note: reg_or_port_name is subject to the effective scope (effprefix), if any, of the

command, which is prefixed to its name.
InstanceName: Optional. The pingroup along with its instance or block name. For example,
iWrite INSTR1.TDR1 0011
iWrite INSTR2.TDR2 1100
pinGroupName: A valid pinGroup name as specified in the MIPD file. This name should
match the name of a pin or scanRegister in the ICL. You have to specify the entire bus or
register for pinGroupName and not a partial bit range.
value: A string value, either in binary, hex or integer format, which specifies the data for
each pin in the pinGroup. The following prefix defines how the value will be interpreted:
Binary Value Prefix: 0b, b or Lb # L is the length of the value string

Hex Value Prefix : 0h, 0x, h, or Lh # L is the length of the value string
NoPrefix: The default format for value is assumed to be integer
If the binary equivalent of the value string has less width than the number of pins in the
pinGroup, rest of the bits will be filled automatically, as below
Under-sizing an unsized value will result in the assignment of the specified bit values to
the LSBs of the associated pinGroup, with the unspecified most significant bits being
assigned either a 0 or x depending on the most significant bit of the assigned value. If
the MSB is x, then the unspecified bits will be assigned x; otherwise, they will be
assigned 0.
Over-specifying a value or mismatch of the size will result in an error.
Note: The default format for value is integer. However, if the specified string for value has the
same length as the number of pins in the specified pinGroup, then as an exception the format
is assumed as binary and an INFO message for the same is printed.
Example:
Assume the pingroup MYREG is of length 10
iWrite myreg 'b010X0Z01; # zero-filled to: 00010x0Z01

iWrite myinst.myreg 0b11; # zero-filled to: 0b0000000011
iWrite myreg 'hFxd; # Error: Does not fit myreg
iWrite myreg 9 # default treated as int
iWrite myreg 10.b0 # equivalent to: 0000000000
Correlation between ICL, PDL, MIPD and IJTAG Description Files
Operations are extracted from the ICL, written into the MIPD, and utilized during pattern
retargeting to identify how PDL commands should be executed on the target design. Each
root level PDL procedure should be included in the IJTAG description file as an Algorithm,
which may be applied to one or more modules in the ICL (macros in the MIPD). Each
Algorithm in turn, can apply one or more operations. The set of operations for a module is
generated as follows:
One operation is generated for each scan interface of a module. This operation is used
for reading and writing the scan registers that are accessed by that scan interface. The
operation includes all the necessary information about the scan preconditioning
sequence, the scan sequence, and the scan exit sequence in the MIPD. Among the
included information are the scan enable toggling, the scan clock pulsing, the scan
input(s) and output(s), and the scan length. The generated operations are named after
the corresponding scan interface (<scaninterface_name>), and this is how they
should be referenced in the PDL, if needed (iApply [-group

<scaninterface_name>]). Therefore, for this to work, all ScanInterfaces should to

be explicitly mentioned in the ICL. Inference of implicit scan interfaces is not currently
supported.
One operation is generated for all the DataInPorts and DataOutPorts of a module. For
now, these can only correspond to top-level primary I/Os. The generated operation is
named after the module (<module_name>_IO), and this is how it should be
referenced in the PDL, if needed (iApply [-group <module_name>_IO]). This
same operation needs to be used in the PDL when writing to data inputs and reading
from data outputs of that module. In accordance to 1687, all reads are performed at the
earliest possible opportunity and before all writes. Also, as these ports have direct
correspondence to primary I/Os, no scan operation and no clocking are required or
applied.
One operation is generated for all test clocks of a module declared using TCKPort.
According to 1687, all these test clocks are equivalent and have a rising active edge. The
generated operation is named after the module (<module_name>_TCK), and this is
how it should be referenced in the PDL, if needed (iApply [-group
<module_name>_TCK]). This operation is used for pulsing the clock(s) of a module
in order to, for example, allow primary I/O changes to take effect on the memory
elements of the module.
As mentioned before, the above operations are automatically extracted from the ICL
description of a design and the supplied PDL has to comply with them. That is, PDL
commands referencing scan registers, primary I/Os, and clocks cannot be mixed in the PDL
and a separate iApply that can be matched to each one of their corresponding operations
has to be issued in sequence.
The following section provides the ICL, PDL, IJTAG description files (flow inputs), and the
generated MIPD (flow intermediate output) for a sample design and the dependencies
between them are highlighted.
ICL
Module chip {
TCKPort chip_tck;
ShiftEnPort chip_se;
SelectPort chip_sel;
ScanInPort chip_si;
ScanOutPort chip_so {
Source inst.so;
}
DataInPort chip_inp;
DataOutPort chip_outp {
Source inst.outp;
}
Instance inst Of core {
InputPort tck = chip_tck;

InputPort se = chip_se;
InputPort sel = chip_sel;
InputPort si = chip_si;
InputPort inp = chip_inp;
}
}
Module core {
TCKPort tck;
ShiftEnPort se;
SelectPort sel;
ScanInPort si;
ScanOutPort so {
Source reg[0];
}
DataInPort inp;
DataOutPort outp;
ScanInterface scan {
Port si;
Port so;
Port tck;
Port se;
Port sel;
}
ScanRegister reg[3:0] {
ScanInSource si;
}
}
IJTAG Description File

Algorithm Test;
PDL
iProcsForModule core;
iProc Test{} {
iWrite inp 0;
iApply;
iWrite reg 0001;

iApply;
iWrite inp 1;
iRead outp 0;
iApply;
iRunLoop -loopcount 10;
iRead outp 1;
iApply;
iRead reg 0110;

iApply;
}

Generated MIPD File

MACRO = chip;
OPERATION = chip_IO;
PINGROUPS = chip_inp, chip_outp;
CORRESPONDENCE = (
chip_inp = chip.chip_inp, INVERSION = 0;
chip_outp = chip.chip_outp, INVERSION = 0;
)
OPERATION = chip_TCK;
PINGROUPS = chip_tck;
CORRESPONDENCE = (
chip_tck = chip.chip_tck, INVERSION = 0;
)
MACRO = chip.inst;
OPERATION = core_IO;
PINGROUPS = inp, outp;
CORRESPONDENCE = (
inp = chip.chip_inp, INVERSION = 0;
outp = chip.chip_outp, INVERSION = 0;
)
OPERATION = core_TCK;
PINGROUPS = tck;
CORRESPONDENCE = (
tck = chip.chip_tck, INVERSION = 0;
)
OPERATION = scan;
PINGROUPS = reg;
CORRESPONDENCE = (
reg[3] = chip.chip_si, INVERSION = 0;
reg[0] = chip.chip_so, INVERSION = 0;
)
SCANPRECONDITIONING = (
chip.chip_sel = 1;
chip.chip_se = 1;
)
SCANSEQUENCE = (
CLK_PORT = chip.chip_tck;
CHAIN {
SCANLENGTH = 4;
SI_PORT = chip.chip_si;
SO_PORT = chip.chip_so;
}
)
SCANEXIT = (
chip.chip_se = 0;
)
Migrating PDL Patterns by Reading-in BSDL File
In addition to the proprietary IJTAG description file described in the previous sections, the tool
also supports migrating PDL patterns by reading-in BSDL file, which is automatically
generated by the RTL compiler. This file contains TAP port information and instruction OP
codes for generating sequence to control the TAP.

When providing the BSDL file, use the pdlentryfunction keyword for migrate_pdl_tests
to specify the pdl entry function names.
Also, specify the input bsdl file name and its path using bsdlinput and bsdlpath
keywords.
Format of Migrated TBDbin Patterns
One of the key aspects of the PDL retargeting is that the patterns after migration are
converted into serial events at the chip I/Os. For example, read/write of scanRegisters may
first manipulate the TAP pins to set up access to the scanRegister, followed by loading of the
register through the TAP interface. There will not be any Scan_Load() / Scan_Unload() events
in the TBDbin that reference flops within the design. This also eliminates the need to
represent the scanRegisters as scan chains in the testmode, which may even be infeasible
for some of the scanRegister configurations described in ICL.
As mentioned earlier, for each scanInterface consisting of one or more scanRegisters, its
scan operation contains the Scan Preconditioning Sequence, Scan Sequence, Scan Exit
Sequence steps.
These steps comprise a scanop sequence for operating the ICL scanInterface. For TAP-
based access methods, each scanInterface is expected to be associated with a unique TAP
instruction; hence there will effectively be one scanop sequence for each TAP instruction in
the ICL. An exception would be when there are multiple scanRegisters and a single TAP
instruction that selects an offline-SIB which determines the scanRegister to be loaded.
Note: Currently, IJTAG does not support either inline or offline SIBs.

The following figure shows the building blocks that comprise a scanop sequence.
Figure 8-2 Constructing a scanRegister sequence definition (scanop)
Return to Run-
Test_Idle
Set up access to TDR(s) Load/Unload the TDR(s)
Scan operations are represented in the migrated patterns using Encounter Test structure
neutral events, Load_SR and Unload_SR. The Load_SR and Unload_SR events contain
the scan data values and the scanin and scanout pins at which to apply or measure the data,
without any reference to actual flops in the design.
Refer to Encounter Test: Reference: Test Pattern Formats and Encounter Test: Guide
6: Test Vectors for syntax of these events.
The advantage of using structure neutral events is they allow the test data to be represented
without requiring the scan register configuration to be restricted to those supported by an
Encounter Test testmode. These events also allow for a concise representation of the test
patterns as the scan protocol can be described separately from the actual usage of these
events, similar to the Scan_Load/Scan_Unload events.

Figure 8-3 Sample Scan sequence definition for Load_SR/Unload_SR
Each Load_SR (Unload_SR) event specifies a stim (measure) register and the test data to
be applied to that stim (measure) register. The stim (measure) register definition points to a
scanop that describes how to operate that register, the scanin (scanout) pin that is used by
that register, and the length of the register. Note that there may be multiple stim/measure
registers that share the same scanop sequence. In case of parallel scan chains, there will be

one Load/Unload_SR for each SI/SO pair. Since all the parallel scan chains shift
simultaneously, one scanop is sufficient to describe the operation of all the registers. The
following figure shows an exemplary definition for a stim and measure register pair that are
used for scanRegisters named PARALLEL_TDR and GLOBAL_STATUS_TDR in the ICL.
The following figure shows the stim and measure register definitions that link the scanop
defined in Figure 8-2 on page 185.
Figure 8-4 Definitions of Stim and Measure registers to be used in Load/Unload_SR

events
The following figure puts it all together and shows the overall structure within the TBDbin file.
Experiment contains the scan sequence definitions followed by the stim and measure
register definitions. This is then followed by the patterns themselves, where the Load_SR
event specifies the test data to be loaded into stim_register #1, which is essentially loading
PARALLEL_TDR. Similarly, the iRead of GLOBAL_STATUS_TDR is represented by the
Unload_SR event, which uses measure_register #2 for this purpose.

Figure 8-5 Re-targeted patterns that use Load_SR/Unload_SR events
write_vectors converts the migrated patterns in TBDBin format into WGL, Verilog, TDL,
or STIL format. Refer to Writing and Reporting Test Data in Encounter Test: Guide 6: Test
Vectors for information on converting patterns into tester formats.
Processing Tester Controlled Clocks Asynchronous to TCK

Asynchronous clocks are the clocks that are pulsed asynchronous to TCK. These clocks are
pulsed through the PDL iRunLoop sck option. These are considered as functional clocks
and are defined in the ICL through the ClockPort statement.
You can specify multiple ClockPort constructs at the module level in the ICL file. These
ports specify the functional clock that needs to be pulsed through PDL. The tool also supports
the DifferentialInvOf construct, which is used in case the functional clocks differ in
polarity. An example is given below:
ClockPort PCK;
ClockPort NCK { DifferentialInvOf PCK; }

Here, the ClockPort statement specifies the port name for the functional clock PCK, and the
DifferentialInvOf construct specifies that the other functional clock NCK to the module
share the same source as clock PCK but is phase inverted to the source of PCK clock
to the module is phase inverted to PCK clock.
This information is passed to MIPD through the <module_name>_SCK operation.
A sample is given below:

OPERATION = counter_SCK;
PINGROUPS = pck, nck;
CORRESPONDENCE = (
"pck" = "Pin.f.l.chip.nl.chip_pck", INVERSION=0;
"nck" = "Pin.f.l.chip.nl.chip_pck", INVERSION=1;
)
The DifferentialInvOf construct sets the inversion flag, as shown in the example above,
if the corresponding top-level chip clock pin is common.
The migrate_pdl_tests command pulses the functional clocks in the generated patterns
whenever you pulse them through PDL by specifying the iRunLoop sck option. If the
functional clock is a free-running oscillator, the tool generates the wait_osc event for the
specified number of clock cycles.
Some examples are given below:
Example 1: (when functional clock is not a free-running clock)
PDL:
iRunLoop 1 -sck MySclk
Output TBDpatt:
[Pattern 1.1.1.2.11.1 (pattern_type = static);
Event 1.1.1.2.11.1.1 Pulse ():
"chip_clk"=+;
]Pattern 1.1.1.2.11.1;
Example 2: (when functional clock is a free-running clock)
PDL:
iRunLoop 5 -sck MyOscClk

TBDpatt:
Event 1.1.1.1.1.11.2 Wait_Osc (cycles=5):
"P1_SYSCLOCK_1";
The information whether a functional clock is free-running oscillator or not is derived from the
testmode, as free-running oscillators are defined using +/- OSC test function. The testmode
modeinit would have started the free-running oscillator clocks using start_osc event as
shown below:
Example Modeinit:
Event 1.1.2.1.1.10.1 Start_Osc (up 4.000000 ns, down 4.000000 ns,
pulses_per_cycle=8):
"P1_SYSCLOCK_1"=+;
Processing Tester Controlled Clocks Correlated to TCK

The Encounter Test IJTAG solution supports correlated clocks that are synchronous to test
clock TCK. These additional test clocks are pulsed simultaneously with TCK, that is, during
shift, TAP operation, and during iRunLoop. The 1687 standard allows multiple TCKPort
statements at the module level in the ICL file. It also states that all TCKPort clocks are
assumed to be equivalent with the same polarity (rule 6.4.6.17 (a)). If you need a phase shift
between these clocks, write out the patterns using the write_vectors command.
Use the following syntax to specify multiple TCKPort statements at the module level in the
ICL file:
Module counter
{
.
TCKPort <clk 1>;
TCKPort <clk 2>;
.
}
These TCKPorts should have a connection to the respective top-level TCKPorts. Also, the
additional top-level TCKPorts need to be correlated to the 1149 TCK in the pinassign file
using the correlate statement as in the following example:
correlate chip_corr_tck +chip_tck;
The multiple TCK port information is passed through the MIPD file to migrate_pdl_tests,
as shown below:
MACRO = "Macro_Instance_Name" [, ,"Macro_Instance_Name"];
ALGORITHM = Algorithm_Name;
[GROUP = GROUP_NUMBER;]
....
"CLK_port" = "Entity"[,Entity]*;

The CLK_port statement accepts multiple, comma separated clock pin names, specified
above as entity. These pin names are the resolved pin names at the top-level block
corresponding to macro TCK ports.
In addition, the TCK operation <module_name>_TCK contains all the TCK ports for the
module and their corresponding ports at the top-level block (an example is shown below).
This operation is executed whenever you invoke it using the iRunLoop PDL command.
OPERATION = counter_TCK;
PINGROUPS = clk1, clk2;
CORRESPONDENCE = (
"clk1" = "Pin.f.l.chip.nl.chip_clk1", INVERSION=0;
"clk2" = "Pin.f.l.chip.nl.chip_clk2", INVERSION=0;
)
Based on the above data in the MIPD, migrate_pdl_tests pulses these clock pins
simultaneously every time the TCK is pulsed by Encounter Test, that is, in the preconditioning
for the TAP and shift operations and also every time you explicitly pulse these using
iRunLoop command.
Handling Scan Chains Spread Across Multiple Macros

If a scan register feeds another scan register which is either outside of a macro or present in
some other macro instance, the scenario represents a scan chain spread across multiple
macros. In such situation, a scan chain is formed by a single scan input at the chip level
feeding into multiple scan registers spread across multiple macros/instruments, and the
output is taken via a single scanout pin at the top.
The following figure depicts a simple series connection for three instruments.

Figure 8-6 Series Connection of Multiple Instruments
To support such a scenario, ICL provides the scanInterface statement that defines the list of
ports which comprise a scan interface. A scan interface consists of a ScanInPort and a
ScanOutPort with related control signals (SelectPort). A sample is shown below:
Module WrappedInstr_A {
ScanInPort SI;
ScanOutPort SO {Source TDR [0] ;}
ShiftEnPort SE;
CaptureEnPort CE;
UpdateEnPort UE;
SelectPort SEL;
ResetPort RST;
TCKPort TCK;
ScanInterface scan_client {Port SI; Port SO; Port SEL ;}
ScanRegister TDR [8:0] {ScanInSource SI ;}
}
If a module statement in ICL defines a ScanInPort, a ScanOutPort, and a SelectPort, but does
not define a scanInterface, then, by default, an implicit scanInterface is assumed with all the
above ports. The name for default implicit scanInterface is <module_name>_scan.
If there are multiple ports of either type and an explicit scanInterface is not defined, the tool
will not assume an implicit scanInterface and will instead generate a warning/error. The
implicit scanInterface may not apply to a top-level module where an explicit scanInterface is
required.

While reading MIPD, if the migrate_pdl_tests command encounters a scan chain

consisting of multiple macro instances, it also looks for similar scan operations in those macro
instances and combines/correlates all of the operations into a single super operation.
A sample PDL is given below:

iProcsForModule WrappedInstr_A;
iProc WrA_Write {} {
iWrite TDR 001010101;
}
iProcsForModule WrappedInstr_B;
iProc WrB_Write {} {
iWrite TDR 00101;
}
iProcsForModule WrappedInstr_C;
iProc WrC_Write {} {
iWrite TDR 0010011;
iApply;
}
iProcsForModule top;
iProc CHIP_TEST {} {
iNote chip_test_1;
iCall INSTR1.WrA_Write;
iCall INSTR2.WrB_Write;
iCall INSTR3.WrC_Write;
iApply;
}
Note that the iApply statement is specified only after all the values are applied to the target
TDR(s) in the scan chain. This iApply statement can be applied from the chip level or from
the scope of any of the instances associated with the TDRs, where the last value is written.
The tool automatically figures out the super operation that needs to be invoked.
If the PDL file does not contain user data for one or more of the scan registers that are part
of the chain, the scan registers without data are loaded with the values previously written to
them.
If no value was earlier provided, the default value, if any, is loaded. In case there is no default
assigned to the scan register, 0 is assumed as the default value.
You can use the migrate_pdl_tests keyword setdefaultvalue=0/1 to set the default
value to 1 or 0.
Assumptions and Limitations

The current IJTAG support works with the following assumptions and limitations:
No retargeting to intermediate levels of hierarchy is supported.

While the read_icl command does not require the ET model (build_model) to
process the ICL and extract the structures and sequences, it is recommended that a
production environment follows the documented flow.
AccessLink support is restricted to 1149.1 TAP controllers and any other scan interfaces
are not supported in this release.
Connection in ICL for a scan register will end at the TAP scan_in port (TDI) on the input
side and TDO port at the output side, if a TAP is present.
The select signal of a ScanMux can only connect to one of the following sources:
A SelectPort at the top level or as a SelectPort in a ScanInterface defined at the top
level.
Can come from an Active Signal statement or as a SelectPort in the ScanInterface
specified in the AccessLink statement.
Update stage of Scan Register for a non-TAP based design is not supported in this
release.
The following ICL constructs/features will not be supported in this release. Note that this
is not an exhaustive list but is intended to highlight only some key constructs:
Inline or offline SIBs
Logic Signals
ClockMux
OneHotDataGroup
oneHotScanGroup
Support for Broadcast to multiple registers in ICL
DataMuxes and DataRegisters
Partial read/write to a scan register or a vectored port is not supported in this release.
The FreqMultiplier attribute in ICL is not supported for iClock command, and
hence, cumulative multiplication factor or division ratio along the clock path is not
calculated.

Index
C
customer service, contacting 9
H
help, accessing 9
O
OPC logic 19
T
test mode
OPC logic 19
U
using Encounter Test
online help 9


Et Flows

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Et Flows

Uploaded by

Copyright:

Available Formats

Encounter Test: Flows

Product Version 15.12

October 2015 3 Product Version 15.12

Write LBIST Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

October 2015 4 Product Version 15.12

October 2015 5 Product Version 15.12

Using External Pipelines with SmartScan Compression . . . . . . . . . . . . . . . . . . . . . . . . 149

October 2015 6 Product Version 15.12

Typographic and Syntax Conventions

October 2015 7 Product Version 15.12

Encounter Test Documentation Roadmap

Flow PMBIST Pattern

Commands GUI Expert

October 2015 8 Product Version 15.12

Getting Help for Encounter Test and Diagnostics

Extended Message Help

October 2015 9 Product Version 15.12

Contacting Customer Service

Encounter Test And Diagnostics Licenses

Using Encounter Test Contrib Scripts

October 2015 10 Product Version 15.12

What We Changed for This Edition

Revisions for Version 15.12

Revisions for Version 15.11

Revisions for Version 15.10

October 2015 11 Product Version 15.12

October 2015 12 Product Version 15.12

This chapter covers the following topics:

October 2015 13 Product Version 15.12

Figure 1-1 Chip with LBIST and Other Test Components

October 2015 14 Product Version 15.12

Figure 1-2 LBIST Architecture

October 2015 15 Product Version 15.12

Top-Down Test Synthesis Flow with Insertion of JTAG-Driven LBIST Logic

October 2015 16 Product Version 15.12

START Task added or

Run Advanced DFT Rule Checker

Insert MBIST Logic

Synthesize Design and Map to Scan

Add ATPG-Related Testability Logic

Connect Scan Chains

Compress Scan Chains

Export to Encounter Test

Refer to Encounter Test Flow in Figure 1-6

October 2015 17 Product Version 15.12

a. Read the libraries.

b. Read in the design (RTL or gate-level netlist).

a. Define your test signals (shift enable and test mode).

b. Define your full scan test clocks.

c. Mark any objects--such as a pre-instantiated JTAG macro--that must not be mapped

a. Define the JTAG instructions: RUNBIST and/or SETBIST.

October 2015 18 Product Version 15.12

- define_dft jtag_instruction -name OPCGLOAD -opcode 011 -

b. insert_dft boundary_scan ...

b. Insert the OPCG logic.

a. insert_dft mbist ...

a. insert_dft shadow_logic ...

b. insert_dft rrfa_test_points ...

October 2015 19 Product Version 15.12

a. compress_scan_chains [-preview] ...

a. insert_dft logic_bist ...

a. write_et_lbist -library ...

October 2015 20 Product Version 15.12