Modus: Guide 7: Hierarchical Test: Product Version 18.11 August 2018

Modus: Guide 7: Hierarchical Test
Product Version 18.11

August 2018
© 2003–2018 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.
Cadence(R) Modus(TM) Solution may include third party software licensed under terms that require display
of notices included in Third Party Licenses and Technologies in Modus: Release: What’s New.
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 Cadence’s trademarks,
contact the corporate legal department at the address shown above or call 800.862.4522. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Modus Documentation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Getting Help for Modus and Diagnostics ..................................... 6
Contacting Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Modus and Diagnostics Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Modus And Diagnostics Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
What We Changed in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
18.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
18.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1
Generating IEEE 1687 (IJTAG) Compliant Macro Tests ..... 9
IJTAG IEEE 1687 Macro Test Generation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Building Modus Model and Testmode(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Reading ICL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Migrating PDL Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Processing Tester Controlled Clocks Asynchronous to TCK . . . . . . . . . . . . . . . . . . . 50
Processing Tester Controlled Clocks Correlated to TCK . . . . . . . . . . . . . . . . . . . . . . 52
Implementing Broadcast Scan with IJTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Broadcast with Serial Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Broadcast with Exclusive Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Specifying Logic Signal for SelectPort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Using Variable Length Scan Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Specifying Blackbox Module ScanInterface(s) in ICL . . . . . . . . . . . . . . . . . . . . . . . . . 61
Using DataMux for DataPath Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Support for Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Generating ModeInit Events in 1687 (IJTAG) Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Generating Start_Osc Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
August 2018 3 Product Version 18.11

© 1999-2018 All Rights Reserved.
Generating Stim_PPI Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Generating Pulse_PPI Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Assumptions and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2
Hierarchical Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Hierarchical Test - Core Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Building Core Migration Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Build Testmode on Core to be used in Hierarchical Test . . . . . . . . . . . . . . . . . . . . . . 71
Prepare Core Migration Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Hierarchical Test - Chip Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Build Core Migration Testmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Migrate Core Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Migrating Non-identical Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Build Testmode for Chip EXTEST Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A
Legacy Core-Level Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Prepare Core Migration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Prepare Core Migration Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Preparing Core Migration Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Preface
Typographic and Syntax Conventions

Modus 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 -LOG input_filename to specify the name of the script that
determines where Modus batch command results files are stored.
■ Optional arguments are enclosed in brackets.
Example: [-language stil|wgl|verilog|tdl]
■ 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
Modus 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
Hierarchical Test
Flow PMBIST
Diagnostics
Modus Flows
Expert
Reference Stylus Common UI
Legacy GUI
Documents GUI
Test Pattern Formats Glossary
Getting Help for Modus 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.
❑ 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.

Preface
2. For command and message help, use man <command_name> or man

<msgprefix>messages to display a man page with the requested information (for
example man build_model or man TSVmessages.
Click the Help or ? buttons on Modus forms to navigate to help for the form and its related
topics.
Refer to the following in the Modus: Reference: GUI for additional details:
■ “Help Pull-down” describes the Help selections for the Modus main window.
■ “View Schematic Help Pull-down” describes the Help selections for the Modus View
Schematic window.
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 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
Contact Customer Support link to view contact information for your region.
Modus and Diagnostics Tutorials

Modus and Diagnostics tutorials are provided through Rapid Adoption Kits (RAKs) that are
available on Cadence Online Support. To access the RAKs (Rapid Adoption Kits):
1. Login to Cadence Customer Online Support (COS) site.
2. Navigate to Resources > Rapid Adoption Kits.
3. Select the hyperlink Synthesis, Test and Verification Flow.

Preface
Modus And Diagnostics Licenses

Refer to “Modus and Diagnostics Product License Configuration” in Modus: Release:
What’s New for details on product license structure and requirements.
What We Changed in This Release
18.11
Added sections:
■ Defining Enumerations in ICL
■ iMerge
■ Prepare Core Migration Data
■ Legacy Core-Level Processing
18.10
Added sections:
■ Using DataMux for DataPath Multiplexing
■ Support for Bidirectional Ports
■ iReset

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

■ IJTAG IEEE 1687 Macro Test Generation Flow
❍ Building Modus Model and Testmode(s)
❍ Reading ICL
❍ Migrating PDL Tests
■ Processing Tester Controlled Clocks Asynchronous to TCK
■ Processing Tester Controlled Clocks Correlated to TCK
■ Implementing Broadcast Scan with IJTAG
■ Using Variable Length Scan Chain
■ Generating ModeInit Events in 1687 (IJTAG) Flow
■ 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 1-1 IJTAG Macro Test Generation Flow
Building Modus Model and Testmode(s)

The Modus 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.
Refer to “Performing Build Model” in the Modus: Guide 1: Models for more 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 Modus: Guide 2: Testmodes for additional
information.
A sample mode initialization file is shown below:

TBDpatt_Format (mode=node, model_entity_form=name);
[ Define_Sequence Mode_Initialization_Sequence 1 (modeinit);
[ Pattern 1.1 (pattern_type = static);
Event 1.1.1 Stim_PI ():
# 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 42 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.
Type man read_icl or read_icl help for information on the command.

Note: All ICL constructs and options listed in 1687/v1.71 standard are not supported in the
current release. Refer to “Assumptions and Limitations” on page 67 for the list of constructs
that are not currently supported.

If you specify multiple ICL files (as comma-separated list) through the iclfile option, each
file is parsed individually and then processed by read_icl to generate a single MIPD file.
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.
■ When executed with -verify yes, the command performs a verification check
(including correspondence and simulation checks) for all ports defined in all ICL
modules. To skip verification for clock/data ports, specify the attribute VERIFY= “NO” in
the ICL file. For example, to ignore simulation and correspondence checks for clockport
HSSREFCLKP, specify the following in the ICL file:
Module chip_Top {
ClockPort HSSREFCLKP {Attribute Verify=“NO”;}
}
■ 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 Modus 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 1-1 on page 10.
■ For a given testmode, the ICL model will be (optionally) verified to be an accurate
representation of the Modus 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.
■ Each special character (that is, ), (, [, ], \, and /) used with instance names in ICL
needs to be preceded with the escape character \.

For example, some sample netlist names and their corresponding names in ICL are
given below:
Netlist Name ICL Name

BISTIPRF1P/FCNTL_1/ BISTIPRF1P\/
EFUSEBAY_W[0]/ FCNTL_1\/
EFUSEBAY/fuseblock EFUSEBAY_W\[0\]\/
EFUSEBAY\/fuseblock
\A/B/C \\A\/B\/C
\A/B/C.D \\A\/B\/C.D
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 option 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 options each representing a separate scan
chain.

❑ There can be one or more Chain statements in the ScanSequence section.
Caution
Support for multiple CHAIN options 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. Modus 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 options are case
insensitive.
Handling AccessLinks
The Scanpreconditioning section Entity contains the special option AccessLink with the
following syntax:
AccessLink.<EntityName>.<InstructionName>.<ScanInterfaceName>.<ActiveSignalName>
Here AccessLink is a option 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 Modus 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 Modus 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 Modus. 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
Modus 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.
Defining Enumerations in ICL
You can define enum values in an ICL file and then use them with iWrite/iRead PDL
commands to make them more readable.
Enum definition syntax:

Enum enum_name
{
enum variable name=value; //repeatable
}
You can define enum values for DataInPorts, DataOutPorts, ScanRegisters, and
DataRegisters in ICL.
Usage examples are shown below.
Instrument ICL

Module MyInstr {
DataInPort enable { RefEnum YesNo; }
ScanRegister mode[3:0]
{
ScanInSource TDI;
RefEnum Modes;
}
DataInPort data[2:0];
DataOutPort okay { RefEnum PassFail; }
DataOutPort done { RefEnum YesNo; }
Enum PassFail {
Pass = 1'b1;
Fail = 1'b0;
}
Enum YesNo {
Yes = 1'b1; No = 1'b0; }
Enum Modes {
red = 4'b0011;
blue = 4'b1000;
green = 4'b0100;
}
}
These enum variables can be used in the PDL functions as shown below.
iProcsForModule MyInstr;
iProc TEST {} {
iWrite enable No
iWrite data 0b100
iApply
iWrite mode blue

iApply
iWrite enable Yes

iApply
iWrite enable No
iApply
iRead done Yes

iApply
iRead okay Pass

iApply
}
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 BSDL or IJTAG
description file as input.
The IJTAG description file, provided through the descfile option, 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.
Type man migrate_pdl_tests or migrate_pdl_tests help for more information on the

command.
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 option 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 option 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 options.
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 options 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 option. 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 option of TCL. Using this option, 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 option 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.
Modus 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.
Modus currently supports the following PDL commands:

■ iApply
■ iCall
■ iClock
■ iDefault
■ iNote
■ iProcsForModule

■ iProc
■ iPutMsg
■ iRead
■ iRunLoop
■ iWrite
■ iOverrideScanInterface
■ iScan
■ iReset
■ iMerge
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 option is specified as yes, 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 Modus 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’ [-status] | -comment] | [[tbdlevel] [key]] text;
-status: Optional. Will cause the default key to be IJTAG_STATUS instead of

IJTAG_NOTE.
-comment: Optional. Will cause the default key to be IJTAG_COMMENT instead of

IJTAG_NOTE.
tbdlevel: Optional. Can have the values PATTERN, TESTERLOOP, TESTPROCEDURE, or

TESTSEQUENCE. Other values will be ignored. The default will be TESTSEQUENCE.
key: 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:
■ -tbdlevel & -key should be specified in that sequence only when both are specified.
■ -status or -comment are exclusive options, that is, you cannot specify both of them in
a single execution.
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 Modus
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 Modus 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 pinGroupName value

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 L’b # L is the length of the value string
■ Hex Value Prefix: 0h, 0x, ‘h, or L’h # 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 10’b0 # 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 pinGroupName value
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 L’b # L is the length of the value string
■ Hex Value Prefix: 0h, 0x, ‘h, or L’h # 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
iOverrideScanInterface
This command is used to turn the broadcast on/off via the PDL.
Syntax:
iOverrideScanInterface <scanInterfaceList> -broadcast on | (off)
Example:
# broadcast u1.target to u2.shadow1 and u3.shadow2:
iOverrideScanInterface u1.target u2.shadow1 u3.shadow2 -broadcast on ;
# broadcast data written to "target" (the ScanInterface on the active
# chain) to the scan registers behind u2.shadow1 and u3.shadow2:
iWrite u1.reg1 010001;
iApply;
# Broadcast turned off
iOverrideScanInterface u1.target u2.shadow1 u3.shadow2 -broadcast off;
The broadcast group of ScanInterfaces must be previously defined in the ICL Instance
statement using the AllowBroadcastonScanInterface statement, otherwise Modus
generates a warning message.
The iOverrideScanInterface command contains only a list of ScanInterfaces having

ScanInPort sharing a common source. The path between the common source and the
ScanInPort may contain scan multiplexers properly selected to point to a common fan-out
point in the scan chain.
A ScanInterface which is on the active scan chain is said to be ‘shadowed’ by the other
ScanInterfaces in the broadcast group which are not on the active scan chain. When a group
of scan registers is configured for broadcast, the iWrite commands are issued only to those
scan registers that are part of the active scan chain and not to those shadowing the scan
registers on the active scan chain. This means the PDL can only do an iWrite to the object
associated with the ScanInterface which is on the active scan chain.
The first scanInterface ('target') in the iOverRideScanInterface commandline is

assumed to be on the active scan path, and Modus verifies that a complete scan path for both
input and output is available in ICL for the active ScanInterface. If there is no active scan path,
Modus generates an error message.
Rest of the ScanInterfaces that follow are assumed to be the 'shadow' and receive the
shadow data.

Note: You have to ensure that the hardware configuration allows the shadow registers to
receive the active scan data. Modus only enables selecting the active scan interface/
broadcast.
The length of the scan chain associated with the first scanInterface (that is, the target scan
Interface) should be greater than or equal to the length of the scan chains associated with the
other scanInterface list ('Shadow'). This also means that the number of bits in the value
argument of a iWrite command whose object argument (reg_or_port) is a scan register in
the broadcast group shall match the number of bits in the longest scan register in that group
(that is, length of chain for target scanInterface).
The broadcast mode, once set, will remain in effect until you explicitly disable it via the
iOverrideScanInterface -broadcast off command. Modus generates an error if a
scanRegister is read or written that is not part of active ScanInterface and broadcast scan
mode has not been disabled.
On encountering an iOverrideScanInterface -broadcast ON statement in PDL,

Modus looks for an appropriate broadcast operation at chip level and invokes the same. When
the broadcast is off, and iWrite to the same ScanRegister should invoke a non-broadcast
operation, it will enable the individual Instrument Select.
iScan
This command specifies the precise length of the scan chain between the ScanInPort and
ScanOutPort of the ScanInterface it is interacting with, along with the load and unload data.
A length parameter defines the length of both the input and output scan data and is specified
with every invocation of iScan command in PDL.
Syntax:
iScan ScanInterface_name length ['-si' siData] ['-so' soData]
Examples:
iScan myif 8 -si 0b01010101 -so 0b11xx00xx;
iScan myif 8 -si 0b11 -so 0b11; # zero-filled to 0b00000011
iScan myif 6 -si 0xfd -so 0xXX; # error: truncation disallowed
Out of all the parameters, scan interface name and scan length are mandatory, while scanIn
data and scanOut data are optional.
The iScan command contains read and write data. The iScan command is designed to
support a blackbox module as well, that is, a module description in ICL which has only ports,
but no scanRegisters (refer to Specifying Blackbox Module ScanInterface(s) in ICL for more
information). These modules can be used to hide proprietary intellectual property (IP). Such

modules are often used in conjunction with iScan commands in PDL and have a precisely
defined scan chain length at any given time via iScan, which is associated with each
ScanInterface of the blackbox module.
The iScan command modifies both the controlling state and expected state models. The
controlling state has two possible values, 0 and 1. The expected state has three possible
values: 0 which means "expect 0", 1 which means "expect 1", and X which means "do not
compare".
Note:
■ As iScan is a setup command, it only modifies the model state (in the same manner as
iWrite and iRead) and requires a following iApply command to initiate the series of
Capture-Shift-Update operations on the device.
■ ScanInterface_name should be prefixed with effPrefix and refers to scanInterface
defined in the target module.
■ The length argument should match the length of the scan chain referenced by the
scanInterface_name at the time iScan is executed.
■ The tool does not check for the length of the scan chain and assumes it to be correct by
construction.
■ If the -si argument is not provided, its default value is set as 0b0.
■ If the -so argument is not provided, its default value is set as 0bX, with padding
extending the value up to length.
■ The length of the provided scan data should not exceed the length specified by the
length parameter. Otherwise, it will result in error. If the length is less than the specified
length, then the data will be padded as per PDL padding rules.
■ Scan data is entered with the least significant bit as the rightmost bit which is physically
closest to the output scan port. Therefore, scan data always shifts visually from left-to-
right.
■ You can control ‘only read’ or ‘only write’ of scan data via the iScan command. This is
achieved by the appropriate hardware design of the control circuits for some of the scan
registers and may include logic which disables either the capture or the update logic (or
both), in which case cycling through the CSU states can result in read-only, write-only, or
shift-only operations.
The iScan command can be used along with broadcast (refer to Implementing Broadcast
Scan with IJTAG for more information). Here is an example PDL:
# broadcast u1.target to u2.shadow1 and u3.shadow2:
iOverrideScanInterface u1.target u2.shadow1 u3.shadow2 –broadcast on ;

# broadcast data written to “target” (the ScanInterface on the active chain)

iScan u1.target 8 –si 0b00001000 –so 0b001xxxxx; iApply ;
#Turn broadcast off

iOverrideScanInterface u1.target u2.shadow1 u3.shadow2 –broadcast off ;
iReset
This command forces the ResetPort to be asserted on the target module. For a top-level
module having an AccessLink, its reset sequence is also invoked. This command can be
triggered from PDL within the scope of its Target Module.
Syntax:
iReset [-sync] ;
-sync is an optional option. If the -sync option is specified, Modus will do a synchronous
reset, else, there will be an asynchronous reset. More information about synchronous and
asynchronous reset is given below.
■ Local Reset
Local reset events are generated when the module to be placed in its specific reset state
is NOT the top level module but some internal module. The iReset command must be
specified as target to some instance of this internal module.
Modus will set all the ports/registers of the target module instance to their specified reset
values. In case of local reset, the -sync option will not have any effect.
■ Global Reset
Global reset can also be considered as a chip-level reset. It places all the instances in
the chip to their specific reset state. If the top-level chip has an access link, then Modus
will generate reset events for the associated access link/TAP controller as well after
putting every module in the chip to its specific reset state. There are two types of reset
for the TAP controller - synchronous reset and asynchronous reset.
❑ Synchronous Reset
In this type of reset, if access link has a TMS port, then a sequence of five TMS=1
patterns are generated for the reset events.
❑ Asynchronous Reset
This is the default reset type that Modus performs if TRST port is defined. In this type
of reset, the TRST port for the TAP is asserted. If TRST does not exist, then
synchronous reset is performed.
Example:

ICL Specification
module temp {
iProcsForModule temp;
ResetPort jtag_rst_n ;
ScanRegister tdr_reg[3:0] { {
ResetValue 4'b0000;
DefaultLoadValue 4'b0000;
}
DataInPort D1 { DefaultLoadValue 0 ;}
….
}
PDL Mapping
iProc Test {}{
iReset;
Both the sections for ResetValue and DefaultLoadValue are optional and can be
specified when the data for them is present in ICL. They both can specified together, as
shown in the above example. If the ResetValue is not specified, then DefaultLoadValue
will be loaded, and in case both are absent, then the default reset value is set to 0.
ResetValue should always be consistent with DefaultLoadValue for all non X values.
iMerge
This command enables parallel executions of multiple iCalls where possible. The iCalls can
be made by the multiple instances of the same module or a different module.
Syntax:
iMerge ['-begin' | '-end’];
Only iCall and iNote functions are allowed after iMerge -begin until iMerge -end.
Example:
iMerge –begin
iNote “Starting the iMerge”
iCall InstA.proc1
iCall InstB.proc2
iMerge –end
The following examples show how to merge instances in different scenarios.
Example1: Merging instances A0, A1 of same module

# PDL for module IP_A

iProcsForModule IP_A;
iProc tdr_test {val} {
iWrite enab $val
iApply
iWrite REG 1010;
iApply
# PDL at Chip level

iProcsForModule Chip;
iProc multi_test {} {
iMerge -begin;
iCall A0.tdr_test 1;
iMerge -end;
}
# Tester patterns (migrated)

Set Primary Inputs:
A0.enab=1,
A1.enab=0
Scan Load:(Total=8 cycles)
A0.REG=1010
A1.REG=1010
Example2: Merging instances A0,A1 for different modules IP_A, IP_B

iWrite enab $val
iApply
iWrite REG 1010;
iApply
}
# PDL for module IP_B
iProcsForModule IP_B;
iProc tdr_test {} {
iWrite REG 1110;
iApply
}
# PDL at Chip level
iMerge -begin;
iCall B0.tdr_test;
iMerge -end;
}
#Tester patterns (migrated)
Set Primary Inputs:

A0.enab=1
Scan Load: (Total=8 cycles)
B0.REG=1110
Scan Load: (Total=8 cycles)
A0.REG=1010
Points to note:

■ Tester patterns shown in the example are based on merging the first iApply from each
iProc
❑ Had to serialize primary input stimulus and scan load
■ Loading of each of the scan registers is also serialized
❑ Loaded both registers in total 16 cycles
Example3: Merging instances in different modules IP_A, IP_B with iRunLoop

iWrite enab $val
iApply
iWrite REG 1010;
iApply
}
# PDL for module IP_B
iProcsForModule IP_B;
iProc tdr_test {} {
iRunLoop 20 -tck
iRead REG 0000;
iApply
}
# PDL at Chip level
iMerge -begin;
iCall B0.tdr_test;
iMerge -end;
# Tester patterns (migrated)
Set Primary Inputs:

A0.enab=1
Begin Loop: (repeat=20 cycles)

Pulse tck;
End Loop
Scan Load: (total=8 cycles)

A0.REG=1010
Scan Unload:
B0.REG=0000
Points to note:
■ iRunLoop in IP_B causes the Scan Load in IP_A to be delayed
■ Scan Load of A0.REG and Scan Unload of B0.REG can still be overlapped (total 8 cycles
for both)
The following example shows the merged PDL entries after usage of iMerge.
iCall InstA.run_test

iClock InstA.clk
iRead InstA.go Fail
iRead InstA.done No
iApply
iWrite InstA.mode blue
iApply
iWrite InstA.enable Yes
iApply
iRunLoop 9000 –sck InstA.clk
iRead InstA.done Yes
iRead InstA.go Pass
iRead InstA.count
iApply
iCall InstB.run_test
iClock InstB.clk
iRead InstB.go Fail
iRead InstB.done No
iApply
iWrite InstB.mode green
iApply
iWrite InstB.enable Yes
iApply
iRunLoop 7000 –sck InstB.clk
iRead InstB.done Yes
iRead InstB.go Pass
iRead InstB.count
iApply
Merged PDL after iMerge
iClock InstA.clk
iClock InstB.clk
iRead InstA.go Fail
iRead InstA.done No
iRead InstB.go Fail
iRead InstB.done No
iApply
iWrite InstA.mode blue
iWrite InstB.mode green

iApply
iWrite InstA.enable Yes
iWrite InstB.enable Yes
iApply
iRunLoop 9000 –sck InstA.clk
iRead InstA.done Yes
iRead InstA.go Pass
iRead InstA.count
iRead InstB.done Yes
iRead InstB.go Pass
iRead InstB.count
iApply
Usage of iMerge, as shown in the given example, offers following advantages:

■ All the merged iApply groups are executed at the same time, wherever possible
❑ Saving in Test Application Time
❑ Lesser number of Test Patterns
❑ Reduction in Test Data Volume => Lesser memory used at the Tester
■ iMerge is independent of IP PDLs
❑ Parallelism is exploited at the chip-level PDL
■ iMerge can be used to simultaneously unload patterns from multiple IPs, unlike
Broadcast
■ Multiple instruments can be tested in parallel
❑ As many iCalls can be merged as required
The following are currently not supported:

■ Support for nested iMerge - For example, an iProc being called from within an iMerge
has another iMerge –begin/–end inside it
■ Support for iTake/iRelease
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;
)
“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;
)
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 1-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 Modus 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 Modus: Reference: Test Pattern Formats and Modus: 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 a
Modus 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 1-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 1-2 on page 47.
Figure 1-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 1-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 Modus: 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 Modus 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 Modus, that is, in the preconditioning for the
TAP and shift operations and also every time you explicitly pulse these using iRunLoop
command.
Implementing Broadcast Scan with IJTAG

If there are multiple scan segments sharing a single scan data, the scan load for the data can
be done simultaneously in a single scan operation, which saves the data load time. This is
termed as broadcast scan. Note that the data is still unloaded from each of these scan
segments individually and the broadcast is only at the input level.
Broadcast scan configuration consists of a single TDI (test data input) point feeding data to
multiple scan segments in parallel. This allows a reduction in the time spent in loading scan
segments intended to receive identical data. It is important to note that the notion of scan
broadcast applies only to data being written to (that is, serially loaded into) scan chains. While
broadcast mode is active, the data can only be read from (that is, serially unloaded from) a
single instance of the scan broadcast group. When broadcast mode is not active, each of the
instances is accessible for read operations.
The following sections discuss various configurations that support broadcast scan.
Broadcast with Serial Access

In this scenario, the output from one instrument (SO) is taken to the input (SI) of the next
instrument to form a serial configuration of all the instruments connected in series. The
ScanIn from chip-level TDI also fans out to each of these instruments and ScanMux is
inserted in the scan path, which is controlled by the broadcast select (BS) signal, as shown
in the following figure:

Figure 1-6 Broadcast Scan with Serial Access
When the broadcast mode is ON, the broadcast select (BS) is high, thus causing the data
from chip-level TDI pin to be directly loaded in the Scan Inputs(SI) of each of the instruments.
When broadcast is OFF, the data is loaded serially via the chip-level TDI and is shifted via the
scan out (SO) pin of one instrument into the next instrument.
The select port (SEL) of the instrument is selected when either of the Broadcast Select (BS)
or the instrument select (SEL) is high. This can be achieved by putting OR gate as shown in
the figure. This OR gate may be present inside or outside the instrument but for simplicity, we
have shown it to be outside the instrument.
Each select signal at the output of JTAG controller represents a unique JTAG instruction. The
select signal is high when its corresponding JTAG instruction is loaded. As the instrument
select signal for each of the instruments is simultaneously turned ON (all instruments should
shift during serial scan), all select signals to the instrument are combined into a single select,
and thus we are left with just two select signals, one for broadcast select and the other for
instrument select. This means we need only two JTAG instructions in this scenario, and the
process is independent of the number of instruments.

Note: For serial access scenario, during the broadcast scan load, only the last instrument in
the chain can produce output data to be consumed at the chip TDO. To access (read) the data
from any of other instruments, the broadcast mode must be disabled.
Broadcast with Exclusive Access

In this configuration, each of the instruments can be individually accessed via the TAP, as well
as all of them can be loaded simultaneously via the broadcast. The select signal to the
instrument (SEL) is again a logical OR of broadcast select and the instrument select signal.
However, the difference is the presence of ScanMux at the output of the each of the
instruments (SO), as shown in the following figure.
Figure 1-7 Broadcast Scan with Exclusive Access
When the broadcast mode is ON, the broadcast select (BS) is high, thus causing the data
from chip-level TDI to be directly loaded in the Scan Inputs (SI) of each of the instruments.
Each instrument select (SEL) is high due to ORing with broadcast select (BS) signal, and
hence, each instrument receives the identical copy of the same data that is loaded from the
chip TDI.

When broadcast is OFF, the data is loaded individually via the chip TDI, and the instrument
is selected by loading the JTAG instruction to turn ON the instrument select signal (SEL1, or
SEL2, or SEL3, or SEL4). Here again, each select signal at the output of JTAG controller
represents a unique JTAG instruction. The select signal is high when its corresponding JTAG
instruction is loaded.
Note: This configuration requires N+1 JTAG instructions where N is the number of
instruments and the one extra instruction is required to enable the broadcast mode.
To implement scan broadcast, you need to define a broadcast group of ScanInterfaces in the
ICL Instance statement using AllowBroadcastOnScanInterface construct.
The allowance for broadcast indicates that the specified one or more ScanInterface(s) for the
module type being instantiated may participate in the broadcast scan action. It is mandatory
to specify the source of the associated SelectPort for each of the ScanInterfaces that
participates in broadcast.
The syntax for specifying a broadcast group in ICL file is given below:
Instance instance_name Of module_name {
Attribute att_name = att_value; // repeatable
Parameter param_name = param_value; // repeatable
InputPort port_name = source; // repeatable
AllowBroadcastOnScanInterface name1, name2, ...;
}
Here is an example:
Module MyMod2 {
ScanInPort SIa; ScanOutPort SOa; SelectPort Sela;
ScanInterface A {Port SIa; Port SOa; Port Sela ;}
ScanInPort SIb; ScanOutPort SOb; SelectPort Selb;
ScanInterface B {Port SIb; Port SOb; Port Selb ;}
ScanInPort SIc; ScanOutPort SOc; SelectPort Selc;
ScanInterface C {Port SIc; Port SOc; Port Selc ;} …
}
Instance Inst4 of MyMod2 {

AllowBroadcastOnScanInterface A, B, C;
InputPort SIa = SI [0]; InputPort SIb = SI [1];
InputPort SIc = SI [2];
InputPort Sela = Sel [0]; InputPort Selb = Sel [1];
InputPort Selc = Sel [2];
}
It is mandatory to specify a select port if the ScanInterface is part of

AllowBroadcastOnScanInterface statement.
The active signal will be made active by loading the corresponding JTAG instruction in the
JTAG controller. Therefore, there will always be a unique JTAG instruction for broadcast, and
also for selecting each of the instances individually, when broadcast is OFF.

Following is a sample ICL specification for exclusive access:

Module WrappedInstr {
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 ;}
}
Module CHIP_TOP {
ScanInPort TDI;
SelectPort SEL;
TCKPort TCK;
ScanOutPort TDO {Source SO_MUX ;}
AccessLink JTAG_MODULE Of STD_1149_1_2001 {

BSDLEntity MY_CHIPID__;
INSTR_SEL_1 {
ScanInterface {INSTR1.scan_client ;}
ActiveSignals {SEL1 ;}
}
INSTR_SEL_2 {
}
INSTR_SEL_3 {
}
INSTR_SEL_4 {
}
BROADCAST_SEL {
ActiveSignals {BS ;}
}
}
Instance INSTR1 of WrappedInstr { InputPort SI = TDI;

InputPort SEL = LS_SEL1;
AllowBroadcastOnScanInterface scan_client;
}
Instance INSTR2 Of WrappedInstr { InputPort SI = TDI;

}

}


}
LogicSignal LS_SEL1 {SEL1 || BS ;}

ScanMux SO_MUX SelectedBy

SEL1, SEL2, SEL3, SEL4, BS {
5'b00001 : INSTR4.SO // Active Scan Chain
5'b10000 : INSTR1.SO;
5'b01000 : INSTR2.SO;
5'b00100 : INSTR3.SO;
5'b00010 : INSTR4.SO;
}
}
Specifying Logic Signal for SelectPort

Modus supports LogicSignal construct in ICL in the path for the SelectPort. The logic
signals supported are:
■ Boolean logic signals - These logic signals are supported only for basic gates, for
example, Boolean Logical OR (||), Logical AND (&&) and Boolean NOT (!).
■ Bitwise logic signals - These logic signals are supported only for single bit operands, and
can be used interchangeably with equivalent Boolean logic signals. Examples - Bitwise
NOT (~), Bitwise AND (&) and Bitwise OR (|) gates.
Syntax of the LogicSignal construct is as follows:

LogicSignal signal_name {expression}
Some examples:
■ LogicSignal ctl_1 {SEL1 || SEL2}
■ LogicSignal ctl_2 {SEL1 && SEL2}
Here, ctl_1 and ctl_2 are names of LogicSignal constructs that are Boolean OR and
Boolean AND of SEL1 and SEL2 ports, respectively.
The default width of logicSignal_name is 1 bit. The valid operands in the expression
are: Ports, and ActiveSignals.
If Modus encounters a LogicSignal construct while resolving correspondence for an

Instrument SelectPort to a controlling ActiveSignal or to a top-level SelectPort, it traces all

paths to the source of the LogicSignals Input and adds them individually to the
preconditioning requirement. In case of OR gate, if the both the top-level sources for the
SelectPort are valid and different, Modus creates two operations for that instrument, both with
separate preconditioning statements corresponding to the valid select port source.
Therefore, in this scenario, there are two valid ways to operate an instrument, one is via
broadcast and other is via the individual instrument select.
An example of two different SCAN PRECONDITIOING statements to operate the same

instrument is given below:
Selecting the instrument via the INSTRUMENT_SELECT:

"AccessLink.<MY_CHIPID__>.<INSTR_SEL_1>.<TDR>.<SEL1>" = 1;
)
Selecting the instrument via the BROADCAST_SELECT:

"AccessLink.<MY_CHIPID__>.< BROADCAST_SEL>.<TDR>.<BS>" = 1;
)
During post processing, Modus identifies all operations that are created for ScanInterfaces
with AllowBroadcastOnScanInterface defined, across all Instances.
The operations that meet both the below requirements will be identified as broadcast
operations:
■ The ScanInput source is same
■ The ScanPreconditioning is same
Once an operation is identified as of type broadcast, it is passed in MIPD through a new

category of operations <ScanInterface_Name>_BROADCAST. These operations are
similar to their scan counterpart, the difference being that they are meant to be invoked only
when you explicitly enable broadcast via the iOverrideScanInterface command in PDL.
Example: Two Operations created for one scan Interface

MACRO = Block.f.l.CHIP_TOP.INSTR1;
GROUP = 1;
MODULE = WrappedInstr;
OPERATION = scan_client;
BROADCAST=YES;
PINGROUPS = TDR;
CORRESPONDENCE = (
TDR[8]" = "Pin.f.l.CHIP_TOP.nl.TDI", INVERSION=0;
TDR[0]" = "Pin.f.l.CHIP_TOP.nl.TDO", INVERSION=0;
)
"AccessLink.<MY_CHIPID__>.<INSTR_SEL_1>.<TDR>.<SEL1>" = 1;

)
SCANSEQUENCE = (
CLK_PORT = "Pin.f.l.CHIP_TOP.nl.TCK";
CHAIN {
SCANLENGTH = 8;
SI_PORT = "Pin.f.l.CHIP_TOP.nl.TDI";
SO_PORT = "Pin.f.l.CHIP_TOP.nl.TDO";
}
)
OPERATION = scan_client_BROADCAST;
BROADCAST=YES;
PINGROUPS = TDR;
CORRESPONDENCE = (
"TDR[8]" = "Pin.f.l.CHIP_TOP.nl.TDI", INVERSION=0;
"TDR[0]" = "Pin.f.l.CHIP_TOP.nl.TDO", INVERSION=0;
)
"AccessLink.<MY_CHIPID__>.< BROADCAST_SEL>.<TDR>.<BS>" = 1;
)
SCANSEQUENCE = (
CHAIN {
SCANLENGTH = 8;
}
)
In case of Boolean AND LogicSignal, the two sources are combined together and added to
the SCANPRECONDITIONING statement of the corresponding operation. In this case, the two
signals cannot correspond to mutually exclusive ActiveSignals that cannot be turned ON at
the same time. In such case, Modus generates an error message.
In case of Boolean NOT LogicSignal, Modus traces the path to the top-level pin and adds an
appropriate preconditioning.
Example:
SCANPRECONDITIONING = ( "CHIP_TOP.SEL1 = 0; )
If the source is an ActiveSignal and the expression requires the ActiveSignal to be inverted,
it may be removed from the preconditioning or Modus generates an error message if that
configuration cannot be achieved.
As ActiveSignal gets active by loading JTAG instruction, its inactive value means that the
instruction to activate the signal is not loaded in JTAG controller.

Using Variable Length Scan Chain

IJTAG supports variable length scan chain or scan register embedded within an instrument
via the iScan PDL command.
Specifying Blackbox Module ScanInterface(s) in ICL

Blackbox module is a handoff or internal module with only the ports and optionally the scan
interfaces defined. When they define one or many ScanInterfaces, blackbox modules are
operated with iScan PDL commands. Otherwise, a blackbox module typically only includes
ports with functions DataInPort, DataOutPort, and ClockPort.
The ScanInterface(s) defined as blackbox are the ones which only identify the ScanIn,
ScanOut and SelectPorts for the instrument, and there is no ScanRegister associated with
that ScanInterface in ICL. The instrument does have the embedded scanchains within the
specified SI and SO ports, but the connectivity of these chains within the instrument is not
explicitly visible in ICL.
Note: Connectivity of all the ports of a blackbox module outside of the instrument still needs
to defined in the chip-level ICL, the same way it is defined for any other module.
Some sample ICL specifications are given below:
Example 1:
Module BB1 {
ScanInPort SI; CaptureEnPort Ce; ShiftEnPort Se;
UpdateEnPort Ue; SelectPort Sel; ResetPort Rst;
TCKPort Tck; ScanOutPort SO;
ScanInterface scan_BB {Port SI; Port SO; Port SEL ;}
}
Example 2:
Module BB2 {
ScanInPort SI;
ScanOutPort SO {Source so_mux ;}
ShiftEnPort SE;
CaptureEnPort CE;
UpdateEnPort UE;
SelectPort SEL1;
SelectPort SEL2;
ResetPort RST;
TCKPort TCK;
# Non-blackbox Scan Path

ScanRegister TDR [8:0] {ScanInSource SI ;}
ScanMux so_mux SelectedBy SEL1 {
1'b1 : TDR[0]; 1'b0 : SI;
}
ScanInterface scan_BB1 {Port SI; Port SO; Port SEL1 ;}

# Blackbox Scan Path

ScanInterface scan_BB2 {Port SI; Port SO; Port SEL2 ;}
}
The read_icl command supports blackbox modules scanInterface(s), wherein the

connectivity within the instrument is not defined. The associated SelectPorts, SI and SO ports
are traced back to their top level corresponding ports and, accordingly an operation with
empty pin groups, empty correspondence and a scan length of zero, is created in MIPD. This
operation can only be invoked via the iScan PDL command.
Sample MIPD is given below:

OPERATION = scan_BB2;
PINGROUPS =;
CORRESPONDENCE = (
)
"AccessLink.<MY_CHIPID__>.<BBS>.<scan_BB2>.<scan_BB2_SEL>" = 1;
)
SCANSEQUENCE = (
CHAIN {
SCANLENGTH = 0;
}
)
Using DataMux for DataPath Multiplexing

This section explains how to use DataMux to observe the DataOutPort from Multiple IPs at
the chip-level DataOutPort.
The syntax of the ICL construct DataMux is given below:

DataMux mux_name SelectedBy mux_select_signals {
mux_select_value : data_source_name; // Repeatable
}
Sample usage is given below:

// implements C_S_REG = (select_bit) ? command[7:0] : status[7:0];
DataMux C_S_REG SelectedBy select_bit {
1'b0 : status[7:0];
1'b1 : command[7:0];
}

The DataMux statement maps one or more input values onto the output (which are of the
same width) when the specified select condition (the one listed after the SelectedBy
keyword) is met.
Each entry in the body lists the pairings of a select condition value with the associated input
value. The select condition value in each of these pairings can be considered as an opcode.
The width of the SelectSignals and OpCodes match as per the 1687 standard.
The signal driving the select input of the DataMux is justified to the value that sensitizes the
path to enable the DataMux to operate and connect the desired output, whenever the same
is accessed in the PDL.
The SelectSignal for DataMux can come from SelectPorts or DataInPort functions.
No default (fall-through) condition is included if no opcode matches the select condition; in

such a case, the output of the DataMux is undefined.
In an MIPD file, while processing the DataIn/DataOut Ports defined within a module, if the
correspondence to these ports/registers requires justifying the DataMux SelectSignal(s) to a
specific value to establish a path, then these ports/registers will have a separate operation
(mentioned below) created in MIPD, and will be removed from the default I/O operation for
that module.
■ Write operation - PortName_WRITE_DATA for DataIn ports having correspondence with
top-level INPUT ports.
■ Read operation - PortName_READ_DATA for DataOut ports having correspondence
with top-level OUTPUT ports.
These operations contain a preconditioning statement that has the SelectSignals for
DataMux/WriteEn Signals traced back to the chip-level controllable ports to assign the
required value to enable the specific DataIn/DataOut Ports access.
Support for Bidirectional Ports

IEEE 1687 standard does not describe how a bi-directional port should be specified in ICL,
and hence there is no standard syntax to define bi-di ports in ICL. Modus supports defining
bi-directional ports by specifying the same port name twice in ICL, once as DataInPort and
second time as DataOutPort.
Note: Only DataInPort and DataOutPort port types are supported for bi-di ports in this
release.

You can control the Enable signal for the bi-di ports via PDL or Mode Initialization. In case you
want Modus to set the enable signal, specify the ENABLE_SIGNAL attribute (optional) in ICL.
Salient features of this attribute:
■ Identifies the signal name/port name in ICL that needs to be set to enable the desired
port direction. The signal should be controllable from TOP (that is, it should have a proper
connection till top level)
■ Whenever Enable_Signal is specified, the port type is assumed to be functional only
when Enable_Signal is set to 1. When the signal is not specified in the second port type,
the tool will set it to 0 to enable the port type.
❑ Example: If Enable_Signal is specified for DataInPort, but not specified for
DataOutPort, the tool will set the Enable_Signal to 1 for DataInPort and will set it to
0 for DataOutPort.
■ The Enable_Signal value will be added to the preconditioning section in MIPD and the
READ_DATA and WRITE_DATA operations will be generated as required.
■ Enable_Signal cannot be defined simultaneously in both DataInPort and DataOutPort
statements.
■ Has Active signal value of Enable = 1 to allow behavior of that port type
■ If Enable_Signal is not defined in either DataInPort and DataOutPort, it will be user
responsibility to ensure Enable Signal is set correctly in the generated patterns via PDL
or other means.
■ The tool generates a message if a port is defined as bi-di in ICL but its Enable_Signal is
not defined.
Example:
DataOutPort BiDiport_1 {
Attribute "ENABLE_SIGNAL" = "<SignalName/PortName>" ;
}
DataInPort BiDiport_1 { }
OR
DataOutPort BiDiport_2 { }
DataInPort BiDiport _2{
Attribute "ENABLE_SIGNAL" = "<SignalName/PortName>" ;
}

Generating ModeInit Events in 1687 (IJTAG) Flow

This section explains how you can generate ModeInit events, such as Start_Osc, Stim_PPI,
and Pulse_PPI in 1687 flow, similar to other Modus flows such as LBIST and OPCG.
migrate_pdl_tests supports the option -generatemodeinit to generate

ModeInitSequences from the PDL patterns, one for each pdl entry function.
Generating Start_Osc Event

Add the ToClockPort statement and below-mentioned optional ICL attributes to the ICL file
wherever an OSC clock needs to be defined.
Syntax:
ToClockPort <PortName> {
[Attribute OSC_UPTIME = “timeValue”]
[Attribute OSC_DOWNTIME = “timeValue”]
[Attribute OSC_PULSESPERCYCLE = “Number”]
[Attribute OSC_POLARITY = “+/-”]
Period timeValue;
}
The syntax of ToClockPort statement is as per 1687 standard.
The Period option is mandatory for setting up an OSC clock. The Period timeValue can
be specified in units of ‘ms’, ‘us’, ‘ns’, and ‘ps’. The default is ‘ns’.
As shown in the syntax above, ToClockPort statement has the following optional attributes:
■ OSC_PULSESPERCYCLE
❑ Indicates number of oscillator pulses per tester cycle, when the oscillator is to be
synchronous with the tester. Default is 1.
■ OSC_UPTIME
❑ Indicates the time to be spent in the positive portion of the oscillator cycle. Default
duty cycle is 50%.
■ OSC_DOWNTIME
❑ Indicates the time to be spent in the negative portion of the oscillator cycle. Default
duty cycle is 50%.
■ OSC_POLARITY
❑ Indicates the pulse polarity. Default is +.

Note: If conflicting attribute values are specified, an appropriate error message is generated.
A sample ToClockPort statement is given below:

ToClockPort FCLK {
Attribute OSC_UPTIME = “2400 ps”
Attribute OSC_PULSESPERCYCLE=“1”;
Attribute OSC_POLARITY=“-”;
Period 3600ps;
}
In PDL, if you use an iClock command, such as shown below, with the clockName used
in the ICL ToClockPort statement, Modus adds a Start_Osc event in the output ModeInit.
iClock FCLK;
In MIPD syntax, attributes are added to their respective operations, as shown in the following
example. Correspondence from ToClockPort is not required; it is identified by 0.
OPERATION = chip_OSC;
PINGROUPS = FCLK ;
CORRESPONDENCE = (
“FCLK" = “0”; //0 implies ToClockPort with Period defined
)
ATTRIBUTES FCLK = ( // New section to be added
OSC_UPTIME=“100 ns”;
OSC_DOWNTIME=“100 ns”;
OSC_POLARITY=“+”;
OSC_PULSESPERCYCLE=“1” ;
)
Note: Period is sum of uptime and downtime.
Generating Stim_PPI Event

In ICL:
■ Define the PPI port as DataInPort in chip-level ICL.
■ Add Attribute PPI_PORT to indicate a pseudo primary input port.
Syntax:
Attribute PPI_PORT = “YES”
Example:
DataInPort MyPPI1 {Attribute PPI_PORT = “YES";}
In PDL, when you use the iWrite command to stim the port, Modus automatically generates
the STIM_PPI event.
Example:

iWrite MyPPI1 1;
MIPD file has a new section to define the attribute, as shown below:
PINGROUPS = MyPPI ;
CORRESPONDENCE = (
MyPPI = "Pin.f.l.chip.nl.MyPPI";
}
ATTRIBUTES MYPPI= ( // New section to be added
PPI_PORT=“YES”;
)
Generating Pulse_PPI Event

Define the PPI port as ClockPort in chip-level ICL and add attribute PPI_PORT to indicate
a pseudo primary input port.
Syntax:
Attribute PPI_PORT = “YES”
Example:
ClockPort MyCLKPPI {Attribute PPI_PORT = “YES";}
In PDL, when you use the iRunLoop command to pulse the port, Modus automatically
generates the PULSE_PPI event.
Example:
iRunLoop MyCLKPPI 1;
MIPD file has a new section to define the attribute, as shown below:
PINGROUPS = MyCLKPPI ;
CORRESPONDENCE = (
MyCLKPPI = "Pin.f.l.chip.nl.MyPPI“;
}
ATTRIBUTES MYCLKPPI= ( // New section to be added
“PPI_PORT”=“YES”;
)
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 Modus 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
■ Partial read/write to a scan register or a vectored port is not supported in this release.
■ Scan chains spanning multiple macros is not supported in the current 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.
■ -chain, –stable, and -ir options for iScan command are not supported in the
current release.

2
Hierarchical Test
This chapter covers the following topics:

■ Hierarchical Test - Core Level Flow
❑ Building Core Migration Model
❑ Build Testmode on Core to be used in Hierarchical Test
❑ Prepare Core Migration Data
■ Hierarchical Test - Chip Level Flow
❑ Build Core Migration Testmode
❑ Migrate Core Tests
❑ Migrating Non-identical Cores
❑ Build Testmode for Chip EXTEST Mode

Hierarchical Test
Hierarchical Test - Core Level Flow

At the core level, once we have completed the atpg flow and generated test data, the
hierarchical flow is required to prepare out-of-context information of the core. The following
steps are used to generate this information and can be used at the chip level.
Building Core Migration Model

The core migration model is the model you build for migrating core data for use in hierarchical
test. The input to this application is the workdir you used to process the core. The output of
this application is referred to as the out-of-context core migration model. The model is built in
a directory formed from the specification for the coremigrationdir option and the name
of the top Verilog module name. This directory is used as input when building the model for
the chip (SOC).
Refer to Build Core Migration Model in the Modus: Reference: GUI for information on
running the command using the graphical user interface.
Refer to build_core_migration_model -H or man build_core_migration_model

for information on command syntax and supported options.
Example of build_core_migration_model:
build_core_migration_model -workdir /hierTest/core1 \ -coremigrationdir /hierTest/
core1migr
If the name of the module for the top level in Verilog is coreTop, then the output model will be
in directory:
/hierTest/core1migr/coreTop
Example: Building Core Model for Hierarchical Test
When you are building the model for a core that is going to be used for hierarchical test you
must specify the core option. This lets Modus know that data generated on this model will
be converted for use on a higher level (Chip).
build_model -workdir /hierTest/core1 -designsource /hierTest/core1.v \ -techlib
tsmc13.v:techlib1.v <other options normally specified> \
-core yes
Example: Building Chip (SOC) Model for Hierarchical Test
When you are building the model for a chip that contains cores that have been processed for
hierarchical test, you must point to the coremigrationdir/VerilogModuleName

Hierarchical Test
output from build_core_migration_model for each core. There are no special options
for this purpose, you simply include these directories in the techlib or designsource
path.
build_model -workdir /hierTest/chip -designsource /hierTest/chip.v \ -techlib /
hierTest/core1migr/coreTop,/hierTest/core2migr/coreTop,techlib1.v \ <other
options normally specified>
Build Testmode on Core to be used in Hierarchical Test

The initial processing of a core prior to preparing it for hierarchical test migration uses the
commands in the standard flow. For build_testmode there are no command line changes
required; use the information available in Build Testmode in Modus:Guide 2: Testmodes.
However, in anticipation of defining a core migration model and migrating the patterns you
must provide the following types of testmodes:
■ INTEST - this is a testmode that includes the internal logic on the core. The tests for this
logic will be migrated. On the SCAN statement in your mode definition file include
BOUNDARY=MIGRATE to indicate that the tests for the active logic in this testmode are to
be migrated.
■ BYPASS - this is a testmode that defines the state that allows this core to be bypassed
when it is included on the chip. At the chip level, where there are multiple cores and/or
multiple instances of a core, you will need to define the core instance to be tested; the
rest of the core instances will need to be bypassed (see Build Core Migration Testmode).
On the SCAN statement in your mode definition file include BOUNDARY=BYPASS to
indicate that this testmode defines the bypass state.
■ EXTEST - this is a testmode that includes the external logic on the core. The active logic
in the EXTEST testmodes will be the only logic included in the core migration model; the
only logic that will be included in the core when it is instanced on the chip (SOC). On the
SCAN statement in your mode definition file include BOUNDARY=EXTERNAL,MODEL to
indicate the active logic in this testmode is to be included in the core migration model.
Note: You may have multiple EXTEST testmodes to include all the necessary logic for
the core on the chip (SOC).
Refer to TEST_TYPES in Modus:Guide 2: Testmodes in for the syntax of the SCAN

statement.
You likely will need to include the following statement in the mode definition or assign file as
well. It identifies the maximum number of pipeline stages that will affect the length of the scan
chains when the core is included on the top level (Chip or SoC). This defaults to 5, so if you
will not have any pipeline stages on the top level, you need to specify it to 0. The statement is:

Hierarchical Test
COREMAXPIPEDEPTH=<number of pipeline stages>
When migrating only identical cores at chip level, at the core-level the coremaxpipedepth
specification in the core testmode assign file accounts for chip-level pipelines above the core.
The chip-level pipelines can be from 0 up to the number specified by coremaxpipedepth
in the core testmode assign file.
At the chip level, when migrating non-identical cores at the same time, the maximum shift
length for the non-identical cores must be aligned. In this case, the core testmode assign files
use coremaxpipedepth option to align the maximum shift lengths between non-identical
cores. For example:
The maximum core shift length includes the:

■ Longest core scan chain
■ Core-Level Scan Pipelines
■ Chip-Level Scan Pipelines
Core A COMPRESRESSION_DECOMP testmode has a maximum shift length of 100:

■ Longest core scan chain = 90
■ Core-Level Scan Pipelines = 5
■ Chip-Level Scan Pipelines = 5
Core B COMPRESSION_DCOMP testmode has a maximum shift length of 150:

■ Longest core scan chain = 130
■ Core-Level Scan Pipelines = 10
■ Chip-Level Scan Pipelines = 10
In this case, the minimum aligned shift length for cores A and B would be 150.
Core A COMPRESION_DECOMP assign file would define

coremaxpipedepth=50; # Accounts for chip-level pipelines and maximum shift length
difference from Core B
Core A COMPRESION_DECOMP assign file would define

coremaxpipedepth=10; # Accounts for chip-level pipelines and this core is the
longest maximum shift length of Cores A and B
For additional information on core testmode assign file coremaxpipedepth specification,

refer to refer to COREMAXPIPEDEPTH in Modus: Guide 2: Testmodes.

Hierarchical Test
Prepare Core Migration Data

The prepare_core_migration_data command prepares all the out-of-context
information required to process migrated core at chip level. This is a three-step process that
prepares out-of-context core migration information, core fault-model that can be used at the
chip level, and test data information about the committed core tests. These steps are core
level processes and do not apply at the chip level.
Note: This command replaces the need for individually running
prepare_core_migration_info, prepare_core_migration_faults, and
prepare_core_migration_tests commands, though you can still run these commands,
if required. However, these commands will be obsolete in the next major MODUS release,
and only prepare_core_migration_data command will be supported.
Sample usage syntax for prepare_core_migration_data command is shown below:

prepare_core_migration_data -coremigrationdir /hierTest/core1migr -testmode
COMPRESSION_INTEST
This command is run for each INTEST testmode to get the out-of-context core and can be
identified by checking the mode definition file for the testmode that should include
BOUNDARY=MIGRATE. This indicates that the tests for the active logic in this testmode are to
be migrated.
The process of preparing core migration data includes following steps.
Step 1: Preparing Core Testmode Information
This step derives information from the core testmodes that will be used when the core
migration testmode is built at the chip level. It writes the out-of-context core migration
information into the core migration directory.
The output of this step (in the <coremigrationdir>/

<Verilog_Module_for_Core_Top>) is used as input to
build_core_migration_testmode when processing the chip (SOC). Refer to “Build
Core Migration Testmode” on page 75 for more information.
Step 2: Preparing Core Fault Data
This step derives information from the core faultModel that will be used when the faultModel
is built at the chip level. The information it gathers is for faults that are associated with logic
that is not included in the core migration model (that is, the faults that are in the INTEST
testmodes but not in the EXTEST testmodes - refer to “Build Testmode on Core to be used in
Hierarchical Test” on page 71 for more information). The information includes total number of
faults and the number of detected faults in the logic that is not included in the core migration

Hierarchical Test
model. It writes the out-of-context core fault information into the core migration directory as a
fault rule file that is read in during build_faultmodel at the chip (SOC) level.

<Verilog_Module_for_Core_Top>) is used as input to build_faultmodel when
processing the chip (SOC). Refer “Build Fault Model Example for Hierarchical Test - Chip
Level” on page 76 for more information.
Step 3: Preparing Core Test Data (Hierarchical Test - Core Level)
This step converts committed core tests into a format that allows them to be migrated at the
chip (SOC) level. As the internal logic does not exist in the core migration model that will be
used when the tests are migrated to the chip (SOC), all events in the vectors that stim or
measure internal nets/pins must be converted to equivalent events on the I/O of the core. For
example, a scan_load that stims individual latches on the scan chain must be converted to
an event which applies the correct values on scan input for the core. The prepared tests are
written out in binary format. This step is processed only when there is new test data. For
example, if you already have test data and run prepare_core_migration_data again,
the new test data will not be written out as it is already exists in the migration directory.

<Verilog_Module_for_Core_Top>) is used as input to migrate_core_tests
when processing the chip (SOC). Refer to “Migrate Core Tests” on page 77 for more
information.
As the above-mentioned steps must be performed for each testmode that has tests to be
migrated on the out-of-context core, running this command is critical at the core level. As
mentioned earlier, this command is threefold process and can be run individually using the
commands discussed in “Legacy Core-Level Processing” on page 85.
Note: The prepare_core_migration_data command allows you to control the
execution of each of three steps discussed above, by using the options
(preparetestmodeinfo, preparefaultdata, preparetestdata) provided for the
command. These options can be useful when you want to limit the runs to generate specific
migration data.
Hierarchical Test - Chip Level Flow

The chip level hierarchical test flow uses the out-of-context information of the core, generated
by following the steps discussed at the core level flow, to migrate migrate core test data.
Following steps are used at the chip level to perform the test data migration.

Hierarchical Test
Build Core Migration Testmode

This process builds a core migration testmode for the chip (SOC). Each core migration
testmode identifies the instances of the core for which tests are to be migrated and the other
instances that are to be bypassed. This identification is done with the COREINSTANCE mode
definition statement which is typically included in the assignfile. The output of DFT insertion
will include these statements in the assignfile.
This process checks input and output pin correspondence between the chip level and each
core. This verification after the mode initialization ensures:
■ Core inputs and outputs with test functions are activated and controlled (or observed)
from corresponding chip inputs and outputs with compatible test functions
■ Core Wrapper Instruction Registers (WIRs) defining the core testmode are set to the
same state as specified by the COREINSTANCE assign file specification
The following figure shows WIR registers that are verified by

build_core_migration_testmode. The WIR values are checked against the test mode
state specified in COREINSTANCE statements in the assign file.
The build_core_migration_testmode takes all options from build_testmode in

addition to the coremigrationpath option that is used to identify the location of the output
data from prepare_core_migration_info for each core on the chip (SOC).
Refer to Build Core Migration Testmode in the Modus: Reference: GUI for information on
Refer to build_core_migration_testmode -H or man

build_core_migration_testmode for information on command syntax and supported
options.
Example of build_core_migration_testmode:

Hierarchical Test
build_core_migration_testmode -workdir /hierTest/core1 -testmode

dlx1_1 \ -modedef COMPRESSION -assignfile select_dlx1_1.assign \
-coremigrationpath /hierTest/core1migr:/hierTest/core2migr
In addition to the test function pin assignments required to set up the testmode, the
assignfile would also include coreinstance statements such as:
coreinstance = Block.f.l.DLX_CORE1.nl.DLX1_1 testmode=COMPRESSION_INTEST;
coreinstance = Block.f.l.DLX_CORE1.nl.DLX1_0 testmode=COMPRESSION_BYPASS;
Note: In this release you can select multiple instances of one core per testmode; all other
cores must be in BYPASS as defined by the core's BYPASS testmode.
During build_core_migration_testmode, the -seqdef option is used to specify the

chip-level mode initialization sequence. The mode initialization sequence programs each
core instance to a specific targeted testmode based on the desired active cores in the core
migration testmode being built.
The specified assign file includes information to specify the intended testmode of each core
instance. This allows build_core_migration_testmode and migrate_core_tests
to verify that the provided mode initialization sequence correctly achieves the testmode state
defined in the assign file. The examples shown below set both CORE_A_INST0 and
CORE_B_INST0 into an INTEST testmode so that both cores can be tested at the same time.
coreinstance = CORE_A_INST0 testmode=COMPRESSION_DECOMP_INTEST;
coreinstance = CORE_B_INST0 testmode=COMPRESSION_DECOMP_INTEST;
For more information on the assign file core instance specification, refer to COREINSTANCE
in Modus: Guide 2: Testmodes.
Build Fault Model Example for Hierarchical Test - Chip Level
Build Fault Model supports hierarchical test with the coremigrationpath option. This
option is used to identify the location of the core migration directory for each core that is
instanced on the chip (SOC). The output from prepare_core_migration_faults is
found in these directories and is used to provide a count of core internal faults that are not
visible in the chip model due to use of core migration models for the cores. These counts are
added into the totals for the chip (SOC).
An example of the command line for this purpose is:

build_faultmodel -coremigrationpath /hierTest/core1migr:/hierTest/core2migr
Refer to Build Fault Model in Modus: Reference: GUI

Hierarchical Test
Migrate Core Tests

This process migrates prepared core migration tests from the instances of the core (that were
identified as the target for migration with the coreinstance statement in the assignfile
during build_core_migration_testmode) to the chip I/O. During
prepare_core_migration_tests, the tests were converted to events that can be
applied at the I/O of the core. Now with migrate_core_tests, these tests are mapped to
the I/O and scannable latches of the chip (SOC).
Refer to Migrate Core Tests in Modus: Reference: GUI for information on running the
command using the graphical user interface.
Refer to migrate_core_tests -H or man migrate_core_tests for information on

command syntax and supported options.
Example of migrate_core_tests:
migrate_core_tests -workdir /hierTest/core1 -coremigrationpath /hierTest/core1migr
-testmode COMPRESSION_INTEST -experiment output_exp
Note: This release only supports migrating tests for one core so the coremigrationpath
will only include the directory for the core for which the tests are being migrated.
Migrating Non-identical Cores

Chip-level processing allows instances of non-identical core types to be migrated
concurrently. The following figure shows an example configuration where instances of the
same core type share their scan inputs and scan outputs, but the scan bus is partitioned
across core types.
Figure 2-1 Sample configuration of cores to be migrated concurrently

Hierarchical Test
Rules for Concurrent Migration on Non-identical Cores
The following figure represents some of the DFT rules to be considered in a Hierarchical Test
methodology. When concurrently migrating non-identical cores, some additional rules need
to be considered beyond what may already be in place for identical cores. Some of these
considerations are shown in the figure below and are explained in this section.
Figure 2-2 DFT features and considerations for migration of non-identical cores
The following pin sharing rules apply to non-identical core instances targeted within a chip-
level migration testmode created using build_core_migration_testmode:
■ Non-identical core instances cannot share pins with the these test functions - SI, SO,
OLI, CME and CMI.
The scan, mask and OPCG data for non-identical cores will be different, hence they
cannot share these pins and broadcast the same data to these different core types.
Similarly, the scan outs cannot be shared when concurrently migrating different core
types, as the chip-level response data that is computed will be incorrect if one core has
fewer tests than the other. When one core is done with its tests, its output will be at an
unknown state and cannot be XORed with the good tests from the other core. There is
currently no way for Modus to know how to turn off a core once its tests are complete.
■ Scan Enable can be shared across non-identical cores
During migration, scan operation sequences across cores are merged to create a single
scan operation at the chip level. Hence, when the scan enable is shared, all cores will
enter and exit the scan state at the same time. Furthermore, if one core has empty cycles

Hierarchical Test
(wait cycles) before transitioning out of the scan state or after entering the scan state,
then these delays will be included when transitioning the chip-level scan state as well.
Note: Sharing chip-level scan enable across non-identical cores should be done with
caution. If ATPG (at core-level) makes the scan enable active during a test, then that test
cannot be merged with a test from another core whose scan enable was inactive during
the capture cycles.
Currently, no automatic enforcement is done at core level to keep the scan enable
inactive during the capture cycles. Conflict checking is done at the chip-level during
pattern migration, and the conflicting tests are skipped after issuing a severe warning,
potentially causing bad data. Hence, if you plan to test non-identical cores and share the
scan enable, it is recommended to constrain the core-level ATPG such that it does not
stim the scan enable during capture cycles. This can be done either via a linehold file or
by adding a Test Constraint on the scan enable pin in the core-level testmode.
■ CMLE and CML test function pins can be shared across non-identical cores.
Irrespective of whether the CMLE and CML pins are shared or not, the channel mask
load sequences across cores are merged to create a single channel mask load operation
at the chip level. If a test from a specific core requires its mask registers to be loaded,
then other cores also will have to participate in the channel mask load operation even if
they do not need their mask registers to be loaded in that specific test. Note that the
values shifted into these other cores' mask registers are not consequential as their CME
will be held at the no-mask state during that test. This is based on a fundamental
requirement of test patterns for wide1 and wide2 masking, that is, a
Channel_Mask_Load() event is always accompanied by a Use_Channel_Masks() event;
if a test does not have a Channel_Mask_Load() event, then the Use_Channel_Masks()
event is also absent and the CME is held to its no-mask state.
Note: Sharing the chip-level CMLE across non-identical cores should be done with
caution. If ATPG (at the core-level) makes the CMLE active during a test, then that test
cannot be merged with a test from another core whose CMLE was inactive during the
capture cycles. As with scan enable, if you plan to test non-identical cores and share the
CMLE at chip level, it is advisable to constrain the core-level ATPG such that it does not
stim the CMLE during capture cycles.
■ OLE and OLC test function pins can be shared across non-identical cores.
Irrespective of whether the OLE and OLC pins are shared or not, the OPCG load
sequences across cores are merged to create a single OPCG load operation at the chip
level. This will cause OPCG sidescan chains to be simultaneously operational for all
cores that have OPCG in them. Cores with shorter OPCG sidescan chains are
automatically padded at the beginning to match the longest sidescan chain across cores.
OPCG setup sequences in the tests will also be merged and attached to the
test_procedure in the retargeted patterns.

Hierarchical Test
Though not desirable, it is possible to concurrently retarget tests from non-identical cores
even if some of them do not have OPCG active in the migration testmode. This is feasible
only under the conditions listed below, as otherwise, the cores without OPCG would have
their scan chains disturbed during the OPCG load cycles.
❑ Cores with OPCG have a dedicated OLC clock, in which case, any clocks from cores
without OPCG will not show up in the merged OPCG load sequence
❑ Cores with OPCG have separate scan clocks from the cores without OPCG. The
scan clocks on the cores with OPCG would have the test function of "EC,OLC” and
the scan clocks on the other cores would be just "EC". The clocks on non-OPCG
cores will, thus, not show up in the OPCG load sequence.
Note: As with scan enable and CMLE, if you plan to test non-identical cores and share
the OLE at the chip level, it is advisable to constrain the core-level ATPG such that it does
not stim the OLE during capture cycles.
■ Pins shared across non-identical cores must have identical test function values.
While this is a broad rule, it could potentially lead to bad patterns when violated. For
example, let us assume a chip pin is shared across non-identical cores and connects to
a "EC,CML" test function on one core and "EC" on another core. Unless the second core
has a CMLE pin that gates the "EC" clock inside the core, performing chip-level mask
load operation will corrupt the scan chains in the second core. Note that the second core
would work fine at a stand-alone level, even if there was no gating done inside the core,
as the EC clock would never be pulsed in the core-level mask load sequence. However,
as the pin is now shared at the chip level, it will be pulsed during chip-level mask load
sequence, which makes the gating essential. A similar scenario exists when sharing the
"OLC,EC" clock of one core with the "EC" only clock on the other core. The migration
process cannot identify whether the EC clock was gated inside the core or not, hence
this rule. At the same time, you may have implemented the gating appropriately and this
check may be an overkill, in which case, the message issued by the tool can be ignored.
Yet another problem scenario is where a pin with "SE,GO" test function on one core is
shared with a pin with "GO" test function on another core. The core with the "SE,GO" test
function pin will have the proper delays built into the Trigger macro to ensure there is
sufficient time for the slow scan enable to transition throughout the design. If this pin were
shared at the top level, the "GO" signal on the second core would potentially be
transitioning earlier than expected.
■ Tester-controlled system clocks cannot be shared across non-identical core instances
(FE)
❑ +/-SC clocks (capture-only) must be disjoint
❑ +/-ES clocks (scan and capture) must be disjoint

Hierarchical Test
❑ +/-EC (scan only) can be shared

❑ Need to add +/-TC to avoid use by ATPG in testgen state
It is expected that the ATPG clocking sequences will be different across core types. If
system clocks are shared, then the re-targeting process may run into tests where the
(shared) clock needs to be pulsed for one core but not the other.
■ OPCG (domain macro and trigger macro) must exist inside the core
When core-level ATPG patterns are generated for OPCG testmodes, the patterns need
to be aware not only of the clocking sequences that are capable of being generated by
the OPCG logic, but also of how to program the OPCG registers. The migration process
will simply take these tests and retarget them to the chip pins. If the OPCG logic was
present at chip level, the migration process would have to understand how to program
the chip-level OPCG to generate clocking sequences embedded within the core patterns,
which may be infeasible in cases where core-level ATPG was run unconstrained.
■ OPCG GO signals can be shared across non-identical cores
If the chip-level GO signal is shared across non-identical cores, migrate_core_tests
must detect and issue a warning when the GO signal does not transition across all the
cores' tests at the same time. It is also allowed to share a pin with "SE,GO" test function
with a pin with the same test function on another core, even if their in-built delays within
the Trigger macros are different.
If the GO signals are disjoint across the cores, then migrate_core_tests must line
up the wait_time() events to wait for the longest one before starting the scan operation.
Pipeline Considerations
As with identical cores, chip-level pipelines are allowed on the scanin, scanout, OLI and CME
pins when dealing with non-identical cores. Some basic considerations for the pipeline
construction and clocking are given below:
■ chip-level pipeline depths may be unequal across cores of different types.
■ The clock to a pipeline must also be a clock that exists on the core. This requirement
stems from the fact that only the clocks present in core patterns will be pulsed at the chip
level; there is no chip-level scan protocol that will be used. Hence, if a dedicated clock
pin on the chip is used, it will not be part of the core patterns, and the chip pipeline will
not be clocked during the scan, mask and OPCG load states.
■ The clock to the chip pipeline must be one of the scan clocks of the core type that is
driven by that pipeline. Hence, the pipeline for core type A must be connected to one of
the scan clocks from core type A, and pipeline for core type B must be connected to one

Hierarchical Test
of the scan clocks from core type B. This allows the flexibility that if core type A was
retargeted independently of B, the pipelines on A would still shift correctly.
❑ If a pipeline is shared across groups of cores (partitions), then it needs to be able to
shift when either group is shifting (each group is a separate migration mode at chip
level). It also needs to be able to shift when all groups (partitions) are shifting, which
is likely the chip-level mode where all cores are in EXTEST.
■ If a core has multiple scan shift clocks, the clock to the chip pipeline can be any one of
these clocks, as all these scan clocks will anyway be pulsing simultaneously during the
core's scan operation.
■ If a chip pipeline is on the scan (SI), mask load (CMI) and opcg load (OLI) paths, it needs
to clock in all these states. For example, if the core has separate scan and mask clocks,
they need to be ORed and sent to the pipeline.
■ Chip pipelines on the scan path must hold their values during test generation state. This
requirement stems from the need for the padding values (because of -
coremaxpipedepth option) to be present in the chip-level pipelines at the beginning of
scan operation.
Note: There is currently no check in the tool for this scenario.
■ CME pipelines must clock during the scan and mask load states, to allow priming of the
CME data. CME pipelines must also hold their values outside of these states.
The following additional considerations apply when dealing with cores having 2D-Elastic
compression. Note that there are no verification checks for these conditions.
■ Chip-level scan input pipelines must be negedge flops, similar to the core-level input
pipelines.
■ Chip-level scan output pipelines must be posedge flops, similar to the core-level output
pipelines.
■ Chip-level scan input and output pipelines must be resettable by the elastic_reset signal,
similar to the core-level pipelines.
■ Chip-level CME pipelines must be posedge flops. Similar to their core-level counterparts,
the CME pipelines must NOT get reset by the elastic_reset signal.
Existing Limitation
Currently, OPMISR tests are not supported for concurrent retargeting of non-identical cores.

Hierarchical Test
Build Testmode for Chip EXTEST Mode

At chip level, the top-level logic between cores is tested using standard non-hierarchical test
ATPG. The logic at the top-level and core boundaries is visible to the tool and can be directly
tested without the need to migrate patterns.
The top-level test typically occurs in an EXTEST testmode, where the core IEEE 1500
wrappers are placed in an EXTEST configuration to allow testing of the logic above the cores.
This process involves running build_testmode as would be done for non-hierarchical test
ATPG. The mode initialization sequence specified to build_testmode places the cores and
the top-level logic into the EXTEST mode.
Building a Chip-level EXTEST Assign File
At chip-level, EXTEST testmodes utilizing core-level compression, pattern generators, or

Multiple-Input-Shift-Registers (MISRs) require the core-level information to be specified in the
chip-level assign file to build_testmode. The output of DFT insertion writes out assign file
snippets for the chip-level EXTEST mode containing the required chip-level definitions.
However, this snippet is incomplete without the additional core-level information provided by
the build_extest_assignfile command.
Note: Refer to the chapter Hierarchical Test in Genus Design for Test Guide for
information on Genus-DFT Hierarchical Test methodology.
The build_extest_assignfile command generates a complete chip-level EXTEST

assign file by appending the required core-level EXTEST information to the chip-level
EXTEST assign file generated by DFT insertion and provided via the -inputfile option.
A sample usage of the build_extest_assignfile command is shown below.

build_model \
-designsource [list [get_db workdir]/coremigrationdir \
[get_db workdir]/chip.netlist.v ] \
-techlib [get_db workdir]/library.v
build_extest_assignfile \
-coremigrationpath [get_db workdir]/coremigrationdir \
-coreinstancefile [get_db workdir]/user_extest_testmode.coreinstancefile \
-inputfile [get_db workdir]/dft_chip_extest_testmode_snippet.pinassign \
-outputfile [get_db workdir]/complete_extest_testmode.pinassign
build_testmode \
-testmode CHIP_COMPRESSION_EXTEST \
-modedef COMPRESSION \
-assignfile [get_db workdir]/complete_extest_testmode.pinassign \
-seqdef [get_db workdir]/CHIP_COMPRESSION_EXTEST.seqdef
The -coreinstancefile option specifies a user-defined file with the following information
to define how each core is configured in the desired chip-level EXTEST testmode.

Hierarchical Test
■ Core Module Name

■ Core Instance
■ Core Testmode
A sample core instance file syntax is given below:

module=CORE_A coreinstance=core_a_instance_1 testmode=COMPRESSION_DECOMP_EXTEST;
module=CORE_A coreinstance=core_a_instance_2 testmode=COMPRESSION_DECOMP_EXTEST;
module=CORE_B coreinstance=core_b_instance_1 testmode=COMPRESSION_EXTEST;
The -outputfile option specifies the name and location of the output file created by the
command. The command merges assign file information to define a chip-level EXTEST
testmode specified by the user. This option is mandatory, and it is recommended that the
chosen name should clearly identify the EXTEST chip-level testmode configuration being
defined by the information specified to the -coreinstancefile option.
The -inputfile option is not mandatory. If specified, the relevant core-level information will
be appended to the information given in this file. If not specified, the output will only contain
the core-level information.
The build_extest_assignfile command must be run at the chip level before

build_testmode for the EXTEST testmode, which requires the assignfile information
output by this command.
The command does not check the validity of the coreinstance= value specified in the
coreinstance file. If an invalid coreinstance= value is specified, build_testmode
generates an error that it could not find the instance specified in the file created by
build_extest_assignfile.
build_extest_assignfile command does verify the module= and testmode=

specifications in the coreinstance file exist in the directory specified for the -
coremigrationpath option.

A
Legacy Core-Level Processing
Prior to the introduction of prepare_core_migration_data command, Modus core

migration flow included three commands that were executed individually to prepare the
required migration data of the core. Each one of these commands create respective out-of-
context information of the core and generate necessary files to read migrated core data at the
chip level. This section explains these commands.
Note: Though you can still execute these commands individually to data migration, it is
recommended to use the new command prepare_core_migration_data as these
commands will become obsolete in the next major modus release.
Prepare Core Migration Information

This preparation process derives information from the core testmodes that will be used when
the core migration testmode is built at the chip level. It writes the out-of-context core migration
information into the core migration directory.
Refer to Prepare Core Migration Info in the Modus: Reference: GUI for information on
Refer to prepare_core_migration_info -H or man

prepare_core_migration_info for information on command syntax and supported
options.
Example of prepare_core_migration_info:
prepare_core_migration_info -workdir /hierTest/core1 \ -coremigrationdir /
hierTest/core1migr -testmode COMPRESSION_INTEST
The output of this command (in the <coremigrationdir>/

<Verilog_Module_for_Core_Top>) is used as input to
build_core_migration_testmode when processing the chip (SOC). Refer to “Build
Core Migration Testmode” on page 75.
Note: This command is run for each testmode on the out-of-context core.

Prepare Core Migration Faults

This preparation process derives information from the core faultModel that will be used when
the faultModel is built at the chip level. The information it gathers is for faults that are
associated with logic that is not included in the core migration model (that is, the faults that
are in the INTEST testmodes but not in the EXTEST testmodes - refer to “Build Testmode on
Core to be used in Hierarchical Test” on page 71). The information includes the total number
of faults and the number of detected faults in the logic that is not included in the core migration
model. It writes the out-of-context core fault information into the core migration directory as a
fault rule file that is read in during build_faultmodel at the chip (SOC) level.
Refer to Prepare Core Migration Faults in Modus: Reference: GUI for information on
Refer to prepare_core_migration_faults -H or man

prepare_core_migration_faults for information on command syntax and supported
options.
Example of prepare_core_migration_faults:
prepare_core_migration_faults -workdir /hierTest/core1 \ -coremigrationdir /

<Verilog_Module_for_Core_Top>) is used as input to build_faultmodel when
processing the chip (SOC). Refer to “Build Fault Model Example for Hierarchical Test - Chip
Level” on page 76.
Note: This command is run for each testmode on the out-of-context core.
Preparing Core Migration Tests

This preparation process converts committed core tests into a format that allows them to be
migrated at the chip (SOC) level. As the internal logic does not exist in the core migration
model that will be used when the tests are migrated to the chip (SOC), all events in the vectors
that stim or measure internal nets/pins must be converted to equivalent events on the I/O of
the core. For example, a scan_load that stims individual latches on the scan chain must be
converted to an event which applies the correct values on the core's scan input. The prepared
tests are written out in binary format.
Refer to Prepare Core Migration Tests in Modus: Reference: GUI for information on running
the command using the graphical user interface.

Refer to prepare_core_migration_tests -H or man

prepare_core_migration_tests for information on command syntax and supported
options.
Example of prepare_core_migration_tests:
prepare_core_migration_tests -workdir /hierTest/core1 \ -coremigrationdir /

<Verilog_Module_for_Core_Top>) is used as input to migrate_core_tests
when processing the chip (SOC). Refer to “Migrate Core Tests” on page 77.
Note: This command is run for each testmode that has tests to be migrated on the out-of-
context core.


Index
A
active faults 108
analyze faults
input files 75, 77
overview 76
performing 74
restrictions 74
analyze random resistance
concepts 80, 91
input files 80
inserting test points 84
performing 91
test points 82
analyzing race conditions with MEG
rrfa 82
C
circuit values, viewing 94
CO (controllability/observability) analysis 78
comets
cross-mode markoff 116, 117
overview 116
statistics-only 117
composite fault 138
compound fault 138
concepts
analyze random resistance 80, 91
fault analysis 69
testability measurements 76
controllability/observability (CO) analysis 78
create a fault model
output files 17
customer service, contacting 13
D
detected faults file 42
diagnostics procedure
composite faults 138

Index
driver/receiver objectives 101

dynamic pattern faults 98, 116
dynamic pin faults 98
F
fault
driver/receiver 101
dynamic pattern 98
dynamic pin 98
fault models 115
pattern 93
pattern, shorted net 98
possibly testable at best 107
slow-to-disable 120
stuck driver 119
types 91
fault analysis
deterministic 76
overview 69
process 69
fault list and fault subset
reading and creating 36
fault model
creating 15
fault rule file elements 128
fault rule file example 136
fault rule file, specifying shorted net fault 140
fault types 91
driver/receiver objectives 101
dynamic pattern 98
dynamic pin 98
shorted nets 98
slow-to-disable objectives 120
static pattern 93
static pin 91
stuck driver and shorted net objectives 119
fault-free AND gate 92
faults
dynamic pattern 116
pattern 116
pin 116
shorted net 116
static pattern 116
stuck-at 92
stuck-At faults 116
transition 116

Index
G
global attributes
possibly testable at best (PTAB) 107
global term 0 112
H
help, accessing 13
I
ignore faults file 40
inactive faults 108
L
latch tracing 79
linehold 111
M
message analysis, interactive
N
newlink gui_tfahints 75
newlink uxs 111
non-contacted pin
sequential conflict 112
O
objectives
driver/receiver
slow-to-disable 120
stuck driver 119
stuck driver and shorted net 119
P
pattern fault 93
pattern faults 116

Index
pin faults 116

possible value set (PVS) 77
possibly testable at best faults 107
PTAB (possibly testable at best) faults 107
PVS (possible value set) 77
R
read fault list and create fault subset
input files 37
manually created input 38
output files 39
output from view fault list 37
removing scan faults from consideration
overview 40
S
S-A-1 AND gate 92
scan faults 40
removing from consideration 40
sequential depth 79
shorted net faults 116
shorted net faults, creating 140
shorted nets pattern fault 98
single port latch 97
slow-to-disable objectives 120
static pattern faults 116
stuck driver and shorted net objectives 101
stuck driver objectives 119
stuck-At faults 116
stuck-at faults 92
T
test points
recommendations 82
test points, inserting 84
testability measurements
controllability/observability 78
latch tracing 79
overview 76
performing 77
possible value set (PVS) 77
sequential depth 79
tg state 112
tracing, latch 79

Index
transition faults 116
U
untestable faults
global term 0 112
linehold 111
testable domain 112
tg state 112
using Modus
online help 13
W
write detected faults file
output file
write ignore faults file
creating 40
X
x-source 111


Modus: Guide 7: Hierarchical Test: Product Version 18.11 August 2018

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

Modus: Guide 7: Hierarchical Test: Product Version 18.11 August 2018

Uploaded by

Copyright:

Available Formats

Modus: Guide 7: Hierarchical Test

Product Version 18.11

August 2018 3 Product Version 18.11

Generating Stim_PPI Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

August 2018 4 Product Version 18.11

Typographic and Syntax Conventions

August 2018 5 Product Version 18.11

Modus Documentation Roadmap

Getting Help for Modus and Diagnostics

August 2018 6 Product Version 18.11

2. For command and message help, use man <command_name> or man

Contacting Customer Service

Modus and Diagnostics Tutorials

August 2018 7 Product Version 18.11

Modus And Diagnostics Licenses

What We Changed in This Release

August 2018 8 Product Version 18.11

This document covers the following topics:

IJTAG IEEE 1687 Macro Test Generation Flow

August 2018 9 Product Version 18.11

Figure 1-1 IJTAG Macro Test Generation Flow

Building Modus Model and Testmode(s)

August 2018 10 Product Version 18.11

A sample mode initialization file is shown below:

August 2018 11 Product Version 18.11

The corresponding 1149.1 testmode assign file may look like:

Type man read_icl or read_icl help for information on the command.

August 2018 12 Product Version 18.11

August 2018 13 Product Version 18.11

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

August 2018 14 Product Version 18.11

Netlist Name ICL Name

Handling ScanInterfaces and ScanRegisters

Handling of ScanInterfaces requires the following information to be passed to the pattern

August 2018 15 Product Version 18.11

The following is a sample MIPD syntax generated by read_icl:

■ The SCANPRECONDITIONING section has the following features:

August 2018 16 Product Version 18.11

❑ There can be one or more Chain statements in the ScanSequence section.

Here AccessLink is a option and EntityName, InstructionName,

Performing 1687 Verification Checks

August 2018 17 Product Version 18.11

August 2018 18 Product Version 18.11

This attribute is only supported on DataInPort port types.

This attribute is only supported on DataInPort port types.

Defining Enumerations in ICL

Enum definition syntax:

Usage examples are shown below.

August 2018 19 Product Version 18.11

iWrite mode blue

iWrite enable Yes

iRead done Yes

iRead okay Pass

Migrating PDL Tests

August 2018 20 Product Version 18.11

Type man migrate_pdl_tests or migrate_pdl_tests help for more information on the

An iRead/iWrite to ScanRegisters is represented in the generated TBDbin vectors as a serial

IJTAG Description File

The IJTAG description file consists of the following elements:

Here Algorithm is the option and PDL_Entry_iProcName represents the actual

August 2018 21 Product Version 18.11

TAP_INSTRUCTION_OPCODE : This is a required option and is not case sensitive.

Here TAP_PORTS, TAP_SCAN_IN, TAP_SCAN_MODE, TAP_SCAN_OUT,