0% found this document useful (0 votes)

227 views96 pages

Modus Ug Testvectors

The document is a guide for Cadence Design Systems' Modus® software, specifically focusing on Test Vectors in version 21.11, published in February 2022. It includes sections on writing test data, specifying tester timings, and various output file formats, along with licensing and legal notices. The guide provides detailed instructions and considerations for users to effectively utilize the software for testing purposes.

Uploaded by

Rathnambiga Unnikrishnan

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

227 views96 pages

Modus Ug Testvectors

Uploaded by

Rathnambiga Unnikrishnan

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 96

Modus®: Guide 6: Test Vectors

Product Version 21.11

February 2022
© 2003–2022 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
Modus: Guide 6: Test Vectors

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Typographic and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Modus Documentation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Getting Help for Modus and Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Extended Command and Message Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Contacting Customer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Modus and Diagnostics Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Modus And Diagnostics Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
What We Changed in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
21.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
21.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1
Writing Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Specifying Tester Timings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Tester Timing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Specifying Tester Timing using STIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Write Test Data Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Write Test Data Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Write Test Data Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Default Timings for Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Adding Extra Timing Set for Initialization Sequences . . . . . . . . . . . . . . . . . . . . . . . . . 32
Processing Dynamic Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Changing Default Pin Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Limiting Dynamic Timeplates for Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Creating Cycle Map for Output Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

February 2022 5 Product Version 21.11

Adding Wait Cycles to Output Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Output Vector Considerations for ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Asynchronous Oscillators with ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Writing Standard Test Interface Language (STIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
STIL Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
STIL Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Writing Waveform Generation Language (WGL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
WGL Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
WGL Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Writing Test Description Language (TDL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
TDL Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
TDL Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Writing Verilog ........................................................ 44
Parallel vs Serial Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Verilog Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Verilog Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Xcelium Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Using the TB_VERILOG_SCAN_PIN Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Test Pattern Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Debugging Miscompares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Using Watch List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
SimVision Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Performing Test Pattern Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Understanding the Test Sequence Coverage Summary . . . . . . . . . . . . . . . . . . . . . . 55
Parallel Verilog Simulation for LBIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Comparing Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Writing System Verilog for Hardware Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Supported Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
System Verilog Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Simulating with Palladium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

February 2022 6 Product Version 21.11

2
Reporting Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Input Files for Reporting Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Output Files for Reporting Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3
Reading Test Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Prerequisite Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Read Vectors Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Reading Modus Pattern Data (TBDpatt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Modus Pattern Data Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Reading Standard Test Interface Language (STIL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Support for STIL Standard 1450.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Support for STIL Standard 1450.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
STIL Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Identifying Scan Tests in STIL Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Identifying Mode Initialization Sequences in STIL Vectors . . . . . . . . . . . . . . . . . . . . . 73
Reading Extended Value Change Dump (EVCD) File . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
EVCD Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
EVCD Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4
Reporting Test Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Input Files for Reporting Sequence Definition Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Output Files for Reporting Sequence Definition Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Reporting a Structure-Neutral TBDbin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Input for Reporting Structure-Neutral TBDbin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Output for Reporting Structure-Neutral TBDbin ............................ 79

5
Reading Test Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Prerequisite Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Sequence Definition Data Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

February 2022 7 Product Version 21.11

6
Test Data Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Create Vector Correspondence Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Create Vector Correspondence Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Test Data for Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Test Vector Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Viewing Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Reporting Test Sequence Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Converting Patterns from Compression to Fullscan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

February 2022 8 Product Version 21.11

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.

February 2022 9 Product Version 21.11

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 Legacy GUI Stylus Common UI
Documents
Test Pattern Formats GUI Glossary

Commands Messages

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.

February 2022 10 Product Version 21.11

❑ 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.
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.

Extended Command and Message Help

Messages
■ Display extended help information for a message by entering one of the following
commands either directly on the command line or in the GUI Command Input field:
❑ msgHelp <message_prefix-error_number1> <message_prefix-
error_number1> ...
For example,
msgHelp TSV-001 TSV-315

displays interactive help information for messages TSV-001 and TSV-315.

❑ Clicking on a highlighted message in the GUI Log pops up a window with the
extended help information. Refer to Using the Session Log to View Message Help
in the Modus: Reference: GUI for details.
■ Use man XXXmessages where XXX is the message id prefix. These man pages contain
all the messages for XXX. For example, man TSVmessages.
■ Use man MessageInfo to display general information about the format, severity codes,
and return codes for Modus messages.

February 2022 11 Product Version 21.11

Commands
■ Use help command to find all the available command lines. You can simply type help or
use help all to get the complete list. You can give help a portion of the command to find
all the commands that contain that string (for example, help fault will give you all the
commands that contain "fault" in the name; build_faultmodel, report_faults,
and prepare_fault_subset would all be included in the list along with other
commands that include "fault" in their name).
help <command_name>

will display the purpose of the command.

■ command -help / command -h / command -H reports all standard keywords that are
available for use. The result is a list of options with valid values, the default in parenthesis
(if any), and a very brief description.
■ man <command_name> provides a man page with all help text for the command and
its options (standard and advanced). For example, man build_testmode or man
report_chains.
■ command -help {option option}... provides the help for any valid option that
you request. For example, build_model -help {designsource designtop} will
display the help for the designsource and cell options.
■ help_option <option_name> gives the list of commands for which the specified
option is valid along with syntax and default value.
■ <command_name> -help advanced provides help for all the advanced options of
the command.
■ For help on Perl Extension methods, use man perlext to display the list of all Perl
methods and man perlext_<method_name> to display help for a specific method.

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.

February 2022 12 Product Version 21.11

■ 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 Modus ATPG from All Products.

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

21.11
There are no changes to this version of the document.

21.10
There are no significant changes to this version of document.

February 2022 13 Product Version 21.11

February 2022 14 Product Version 21.11

1
Writing Test Data

Overview
Modus writes the following vector formats to meet the manufacturing interface needs of IC
manufacturers:
■ Standard Test Interface Language (STIL): an ASCII format standardized by the IEEE.
■ Waveform Generation Language (WGL): an ASCII format from Fluence Technology, Inc.
■ Verilog: an ASCII format from Cadence Design Systems., Inc.
■ Test Description Language (TDL)
■ System Verilog for hardware emulation

Refer to Modus: Reference: Test Pattern Formats for detailed descriptions of these formats.

To write vectors using the graphical interface, refer to “Write Vectors” in the Modus:
Reference: GUI.

To write vectors using commands, use write_vectors -H or man write_vectors for

information on command syntax and supported options.

The syntax for the write_vectors command is given below:

write_vectors -workdir <directory> -testmode <modename> -inexperiment <name>
-language <type>
where:
■ -workdir - name of the working directory
■ -testmode - name of the testmode of experiment to export pattern
■ -inexperiment - name of the experiment from which to export data
■ -language stil|verilog|wgl|tdl|verilog_hw - Type of patterns to export

The following table lists the commonly used options for write_vectors for all languages:

February 2022 15 Product Version 21.11

Language Parameter Description

STIL -signalsfile Create a file containing
yes|no common elements
(signals). Default is yes.
-singletimeplate Create a single timeplate
no|yes per file. Default is
conditional.
WGL -signalsfile Create a file containing
yes|no common elements
(signals). Default is yes.
-singletimeplate Create a single timeplate
no|yes per file. Default is
conditional.
Verilog -scanformat Select the format of the
serial|parallel scan in the output
vectors.
-singletimeplate Create a single timeplate
no|yes per file. Default is
conditional.
-includenetnames Include net name in scan
no|yes out miscompare
messages. Default is no.

February 2022 16 Product Version 21.11

Language Parameter Description

-latchnametype Specify whether to
primitive | cell report the output vectors
at the primitive level or at
the cell level.
If a Verilog model does
not have the cells and
macros correctly marked
and you specify
-latchnametype
cell, then the instance
names might match and
be invalid. If the model
does not have a cell
defined, then
write_vectors uses
primitive level for the
instance name.
TDL -scanformat Select the format of the
serial|parallel scan in the output
vectors.
-singletimeplate Create a single timeplate
no|yes per file. Default is
conditional.
-configfile Specify the file that
<filename> contains the TDL design
configuration information
verilog_hw -scanformat serial Format of the scan in the
output vectors.
All languages -testperiod Global test timing - Set
(except
verilog_hw) <decimal 0.000000 the test period
or greater>
-scanperiod Global scan timing - Set
<decimal 0.000000 the scan period
or greater>
-scanoverlap Overlap the scan out
yes|no with the scan in. Default
is yes.

February 2022 17 Product Version 21.11

Language Parameter Description

-EXPORTDIR Directory to include
<outdir> export data (default is
part directory)
-outputfilename Change the default
<string> output file name to be
based on this name.

Specifying Tester Timings

Overview
This section explains the concepts and related command options to specify and control tester
timing.

A test clock is a clock responsible for shifting of data during Scan Mode operation (that is,
when Scan Enable (SE=1)). Its frequency is determined as follows:
■ For Static test, frequency of test clock is dependent on tester used, and generally is in
range of hundreds of Mega Hertz.
■ For at-speed or delay testing, frequency of the test clock is equal to the functional clock
frequency. As functional frequency is required for logic, to achieve this two consecutive
pulses of required functional frequency are used during capture mode.
■ In built-in-self-test (BIST) environment (such as LBIST and PMBIST), the test clock is
generated through PLL and controlled by BIST macro. Here, the test clock frequency can
be higher and can match functional frequency.

The frequency of test clock is controlled via -scanperiod and -testperiod options of
write_vectors command. Regardless of whether it is a scan or a test cycle, there are
three events happening in every cycle - stim, pulse, and measure.

February 2022 18 Product Version 21.11

Figure 1-1 Scan Cycle and Test Cycle

Scan Cycle

In scan cycle, the DUT is in scan mode (SE=1) and logic is bypassed. Typically, the tool shifts
in and shifts out data in this mode using test clock. Hence, it can be said that scan cycle
typically determines the test clock frequency.

Following three events happen during scan cycle:

■ Set Scan Data
■ Measure Scan Data
■ Pulse Scan Clock

The order in scan shift operation is Set scan data/stim PI > measure scan data/strobe > pulse
scan clock.

The three events (stim, measure/strobe, pulse) occur in a single tester cycle. One tester cycle
cannot have repeated events, which means you cannot have two stim events or two pulse
events in one tester cycle. So, if you want to pulse one more time or one more stim, it can
happen only in a new tester cycle.

Thus, by default, the tool does not measure the output pin in the same tester cycle where the
scan shift clock is issued, but in next tester cycle (as shown in the figure below)

February 2022 19 Product Version 21.11

Figure 1-2 Measuring Output Pin

Test Cycle

In test cycle, the DUT is in capture mode (SE=0) and logic is captured.

Following three events happen during test cycle:

■ Set Test Data
■ Pulse Test Clock
■ Measure Test Clock

The order of events is stim PI > pulse > measure.

Controlling Tester Timing through write_vector Options

Scan Cycle

You can control the event timings for a scan cycle through write_vectors options
scanpioffset, scanperiod, scanpulsewidth, and scanstrobeoffset.

The following figure represents what these options signify.

February 2022 20 Product Version 21.11

Figure 1-3 Timing Switches for Scan Cycle

If not specified, following are the default values for these options:
■ Scan period = 80ns
■ Scan pulse width = 10% of period i.e. 8ns
■ Scanpioffeset = 0ns
■ Scan strobe offset = scan pi offset + scan pulse
■ Start scan clock pulse = pulse width + larger of (strobe offset vs pi offset)

Test Cycle

You can control the event timings for a test cycle through write_vectors options
testpioffset, testperiod, testpulsewidth, and teststrobeoffset.

The following figure represents what these options signify.

Figure 1-4 Timing Switches for Tester Cycle

If not specified, following are the default values for the options:
■ Test period = 80ns

February 2022 21 Product Version 21.11

■ Test pulse width = 10% of period i.e. 8ns

■ Testpioffeset = 0ns
■ Test strobe offset = testperiod - testpulsewidth
■ start scan clock pulse = testpioffset + testpulsewidth

Some other important timing options for write_vectors are:

■ -Singletimeplate yes
If you specify this option, all the timings of scan cycle (such as scanpioffset,
scanbidioffset, scanstrobeoffset, scanperiod) will be used for test cycle as well, and test
cycle timings will be ignored.
For example, if you define timings as below:
Scanperiod=2ns
Scanstrobeoffset=0.5ns
Scanpulsewidth=0.5ns
Testperiod=5ns

The resulting values will be:

Teststrobeoffset=4.5ns
Testpulsewidth=0.5ns

Note: Test offset for clock = scan offset for clock = 1ns (clock pulse for both scan and
test cycle will start at 1ns).
In TVE-005 message, only scan cycles are reported and there will be "0" test cycle (as
timeplate of scan is used).
■ Removepins
Either specify the pins to be removed from the output vector files or specify automatic
to automatically remove all pins that are not contacted or used in the vectors.
If the pin is required to generate vectors, TVE-702 warning is issued (once per pin),
which states that:
❑ The pin was removed from vectors using removepins option.
❑ The pin was specified in test data at odometer 'x.y.z.a.b.c'; it will be removed from
the event and may result in invalid simulation results.
■ Pinasdata

February 2022 22 Product Version 21.11

Specify a pin or a list of pins to be considered as data pin. This option is applicable on
clock pins to be treated as data pin. If the pin is already a data pin, TVE-315 warning
message is issued stating that the pin is already a data pin.

Tester Timing Examples

If you do not specify any option with write_vectors command, following will be the default
values:
■ Tester Cycle = 80ns (for both scan and test mode, that is, when SE=1 and when SE=0)
■ Test offset for clock =8ns (pulse starts at 8ns)
■ Scan offset for clock =16ns (pulse starts at 16ns)
■ Takes two tester cycles for test mode

Following examples represent scenarios to explain how changing an option impacts other
timing options.

Example 1

Changing scanperiod to 40ns will generate following information:

■ Test offset for clock =8ns (pulse starts at 8ns)
■ Scan offset for clock=8ns (pulse starts at 8ns)
■ Scanstrobeoffset=4ns
■ Scan pulse width = 4ns
■ Test pulse width = 8ns
■ Testercycle (scan mode) =40ns
■ Testercycle (test mode) = 80ns (but one tester cycle overlaps the period where SE=1,
hence contradicts the definition of scan cycle where SE=1)

Example 2

Changing scanperiod to 30ns will generate following information (testperiod value is default):
■ Scanstrobeoffset=3ns
■ Scanpulsewidth=3ns

February 2022 23 Product Version 21.11

■ Testpulse width=8ns
■ Test offset for clock=8ns (pulse starts at 8 ns)
■ Scan offset for clock=6ns (pulse starts at 6ns)
■ Testercycle (scan mode)=30ns
■ Testercycle (test mode)=80ns

Example 3

Changing scanperiod to 10ns will generate following information (testperiod value is default):
■ Scanstrobeoffset=1ns
■ Scanpulsewidth=1ns
■ Testpulse width=8ns
■ Test offset for clock =8ns (pulse starts at 8 ns)
■ Scan offset for clock=2ns (pulse starts at 2ns)
■ Testercycle (scan mode) =10ns
■ Testercycle (test mode) = 80ns
Note: TVE-005 informs you about the total cycles created while writing vectors and mentions
the number of scan cycles and test cycles.

Example 4

Changing scanperiod to 5ns will generate following information (testperiod value is default):
■ Scanstrobeoffset=.5ns
■ Scanpulsewidth=.5ns
■ Test pulse width=8ns
■ Test offset for clock =8ns (pulse starts at 8ns)
■ Scan offset for clock=1ns (pulse starts at 1ns)

Example 5

Changing scanperiod to 5ns and test period=10ns will generate following information:

February 2022 24 Product Version 21.11

■ Teststrobeoffset = 9ns
■ Testpulsewidth=1ns
■ Scanstrobeoffset=.5ns
■ Scanpulsewidth=.5ns
■ Test offset for clock =1ns (pulse starts at 1ns)
■ Scan offset for clock=1ns (pulse starts at 1ns)

Example 6

Changing scanperiod to 5ns and test period to 5ns will generate following information:
■ Teststrobeoffset=4.5ns
■ Testpulsewidth=.5ns
■ Scanstrobeoffset=.5ns
■ Scanpulsewidth=.5ns
■ Test offset for clock =.5ns (pulse starts at .5ns)
■ Scan offset for clock=1ns (pulse starts at 1ns)

Example 7

In the above examples, only scanperiod and testperiod values were changed and rest of the
timing-related switches were default.

In this example, scanperiod is set as 5ns and testperiod is set as 5ns. As seen in previous
examples, if you do not change other timing-related switches, the default values are as
follows:
■ Teststrobeoffset=4.5ns
■ Testpulsewidth=0.5ns
■ Scanstrobeoffset=0.5ns
■ Scanpulsewidth=0.5ns
■ Test offset for clock =0.5ns (pulse starts at 0.5ns)

February 2022 25 Product Version 21.11

■ Scan offset for clock =1ns (pulse starts at 1ns)

You can alter the timing by using write_vectors options, as shown below:
Scanstrobeoffset=4ns

This means the clock pulse will come at 4.5ns, adding a clock pulse width of .5ns.

Modus will generate warning TVE-309 stating that it is recommended that a pulse width of
settling time be allowed between the end of clock pulse and scan period. Hence, this means
at maximum, you can strobe at a point which is = (scanperiod - 3*testpulsewidth).

By default, after strobe, there should be a gap of one pulse width (before origin of clock pulse)
+ clockpulse width + (pulsewidth for settling time), hence 3*testpulse width.

To address warning TVE-309 (when scanstrobeoffset=4ns), set scanstrobeoffset as 3.5ns,

which generates the following timing values:
■ Teststrobeoffset=4.5ns
■ Testpulsewidth=0.5ns
■ Scanpulsewidth=0.5ns
■ Test offset for clock =0.5ns (clock starts at 0.5ns)
■ Scan offset for clock =4ns (clock starts at 4ns)

February 2022 26 Product Version 21.11

Example 8

As seen in Example 7, it is possible to reduce the scan cycle to 2ns (increasing test clock
frequency) and vectors can be generated on that. For that, set the following values:
■ Scanperiod=2ns
■ Scanpulsewieth=0.5ns
■ Scanstrobeoffset=0.5ns
■ testperiod=5ns
■ Rest of the test cycle timing related switches at their default value.

This will generate the following output:

■ Teststrobeoffset=4.5ns
■ Testpulsewidth=0.5ns
■ Test offset for clock =0.5ns (clock starts at 0.5ns)
■ Scan offset for clock =1ns (clock starts at 1ns)

Specifying Tester Timing using STIL

By specifying convert_stil_to_modedef -stiltimings yes, you can read STIL
timing data from the STIL waveform data file (specified via -stilmodefile option), and
generate timing data (in the file tbdata/TIStimingData.<testmode>) that is passed
on to write_vectors via -timingfile option.

A sample STIL waveform file data file is given below.

Timing {
WaveformTable "_scan_WFT_" {
Period '240ns';

February 2022 27 Product Version 21.11

Waveforms {
"_default_In_Timing_" { 0 { '0ns' D; } }
"_default_Clk0_Timing_" { P { '0ns' D; '120ns' U; '200ns' D; } }
"_default_Out_Timing_" { H { '0ns' Z; '100ns' H; } }
"DFT_misr_clk" { 01ZP { '0ns' P/P/P/P; '2.000000ns' D/U/Z/U; '3.000000ns' D/U
Z/D; } }
"clk_in" { 01ZS { '0ns' P/P/P/P; '5.000000ns' D/U/Z/U; '10.000000ns' D/U/Z/D;
} }
} } }

When you specify convert_stil_to_modedef -stiltimings yes, the parser will read
the data from the above file and generate the following write_vectors timing options:
scanperiod=240
scantimeunits=ns
scanstrobetype=edge
scanpioffset=120.000000
scanpulsewidth=80.000000
scanstrobeoffset=100.000000
scanpioffsetlist=DFT_misr_clk=2.000000,clk_in=5.000000
scanpulsewidthlist=DFT_misr_clk=1.000000,clk_in=5.000000

Note: The above example will import scan-specific timings. Wherever scan is used in these
options, it is also possible to define test and init options of the same kind.
■ Period '240ns' generates scanperiod=240 and scantimeunits=ns
■ If the timing data contains pins with the string default, it will define the option types,
scanpioffset and scanpulsewidth
Entry:
"_default_Clk0_Timing_" { P { '0ns' D; '120ns' U; '200ns' D; } }

generates
scanpioffset=120.000000
scanpulsewidth=80.000000

■ Any non-default pin names will generate a set of list keywords with an entry for each
pin.
"DFT_misr_clk" { 01ZP { '0ns' P/P/P/P; '2.000000ns' D/U/Z/U; '3.000000ns' D/
U/Z/D; } }
"clk_in" { 01ZS { '0ns' P/P/P/P; '5.000000ns' D/U/Z/U; '10.000000ns' D/U/Z/D;
} }

will generate
scanpioffsetlist=DFT_misr_clk=2.000000,clk_in=5.000000

February 2022 28 Product Version 21.11

scanpulsewidthlist=DFT_misr_clk=1.000000,clk_in=5.000000

scanpioffset/scanpioffsetlist is gathered as the first non-zero element of type

D, U, or Z
scanpulsewidth/scanpulsewidthlist is gathered as the last difference of
elements of type D, U, or Z
■ On encountering an uppercase H, T, or L, the appropriate strobe type is defined as edge.
On encountering a lowercase h, t, or l, the appropriate strobe type is defined as
window. These output elements also define the scanstrobeoffset
■ "_default_Out_Timing_" { H { '0ns' Z; '100ns' H; } } generates
scanstrobeoffset=100.000000
scanstrobetype=edge

scanstrobeoffset is gathered as the last value of H/h, T/t, or L/l.

Note: Currently, options initbidioffset, scanbidioffset, and testbidioffset are
not supported for specifying the tester timings using STIL. These options can, however, be
specified on the write_vectors command line when specifying the supported STIL tester
timings.

Write Test Data Restrictions

Restrictions differ depending on the selected language format. Refer to subsequent STIL,
WGL, Verilog, and TDL, and System Verilog sections for details.

Write Test Data Input Files

Write Vectors uses a Modus Experiment or Committed Test Data as input. The command also
uses an nonmandatory option removepinsfile, which allows removal of the specified pins
from the output test vector files (by default, all pins are written to the output test vectors).

When writing TDL output, you need to specify the configfile option to define the TDL
design configuration information. Refer to subsequent TDL section for more information.

Write Test Data Output Files

The output differs depending on the selected language format. Refer to subsequent STIL,
WGL, Verilog, and TDL, and System Verilog sections for details.

February 2022 29 Product Version 21.11

To limit the number of test vector output files, specify -combinesections yes, which
combines multiple test sections based on test types and creates a maximum of four files, one
each for storing static scan tests, static logic tests, dynamic scan tests, and dynamic logic
tests.

In this case, by default, the files are named as language.testmode.testtype, which

can be overridden using the outputfilename option. If the outputfilename option is
specified, the output file is named as outfilename.testtype, where testtype is
static_scan, dynamic_scan, static_logic, or dynamic_logic to indicate the type of test vectors
contained within the output test vector file.
Note: The write_vectors command does not write the PPIs used for test generation in
the output vector.

Default Timings for Clocks

For all vector formats, default placement of test clocks within the test cycle (specified by the
value for testperiod) is based on the following algorithm:
■ clockoffset is initialized to: (the higher value of either testpioffset or
testbidioffset) + testpulsewidth
■ If, and only if, there are A_SHIFT_CLOCKs and/or pure C-clocks (not ES or BS):
❑ They are placed at clockoffset for a duration of the value specified for
testpulsewidth
❑ clockoffset is incremented by 2 times the testpulsewidth value
■ If, and only if, there are E-clocks:
❑ They are placed at clockoffset for a duration of the testpulsewidth value
❑ clockoffset is incremented by 2 times the testpulsewidth value
■ If, and only if, there are B-SHIFT_CLOCKs and/or P-clocks:
❑ They are placed at clockoffset for a duration of the testpulsewidth value
❑ clockoffset is incremented by 2 times the testpulsewidth value
■ Note that clockoffset is incremented only if a particular clock type exists. This means
that clock placement is dependent on the type of clocks used in the design.
■ Final clockoffset time must be <= testperiod to enable all clocks to fit within the
specified test cycle.

February 2022 30 Product Version 21.11

■ Default placement of scan clocks within the scan cycle is identical except that
scanperiod, scanpioffset, scanbidioffset and scanpulsewidth values are
used and only A, E, and B clocks are placed (no C or P clocks).
■ Any clock may be explicity placed by using testpioffsetlist or
scanpioffsetlist.

The default timing for scanpioffset, scanbidioffset, and scanstrobeoffset

varies depending on the order of the Set_Scan_Data and Measure_Scan_Data events in
the scan sequences. The following defaults apply for designs without compression:
■ If the Measure_Scan_Data event precedes the Set_Scan_Data event, the defaults
are the following:
❑ scanstrobeoffset=0
❑ scanpioffset=scanbidioffset =0+2 * scanpulsewidth
■ If the Set_Scan_Data event precedes the Measure_Scan_Data event, the default are
the following:
❑ scanpioffset=scanbidioffset =0
❑ scanstrobeoffset=0+scanpulsewidth

If Set_Scan_Data and Measure_Scan_Data events do not exist in all test modes, the
default timing is the following:
■ scanpioffset=scanbidioffset=scanstrobeoffset=0

Specify testpioffset=CLK_1=120 testpulsewidth=80 to generate the timing shown

in the following figure:

February 2022 31 Product Version 21.11

Specify testperiod=80 pioffset=0 bidioffset=0 strobeoffset=72

pulsewidth=8 pioffsetlist=EC=16 to generate the timings shown in the following
figure, where EC is the Edge Triggered Scan Clock that is pulsed.

Note that Stim signals are not pulses, therefore, they do not return to their original values
within the tester cycle.

Adding Extra Timing Set for Initialization Sequences

By default, the timing of the modeinit sequence matches the timing of the test sequences.
However, you can change the modeinit timing by using any of the following options and
specifying a value different than the current timing value for the test sequences:

February 2022 32 Product Version 21.11

■ initbidioffset
■ initperiod
■ initpioffset
■ initpioffsetlist
■ initpulsewidth
■ initstrobeoffset
■ initstrobetype
■ inittimeunits

Use write_vectors -H or man write_vectors for information on command syntax and

supported options.

write_vectors uses the modeinit timings only if they are different from the test sequence
timings. In case of different modeinit timings:
■ The modeinit timings replace the test timings for all the processed modeinit sequences.
■ The modeinit timings are used for all events encountered within the init Test_Sequence
except for Scan_Load events. write_vectors uses scan timings to process any
Scan_Load event it encounters.
■ Using the modeinit timings, write_vectors writes out accumulated values
immediately after processing the modeinit sequence, prior to processing the first test. In
other words, write_vectors does not compress patterns when transitioning between
modeinit timings and test timings.
■ write_vectors prints the modeinit timings in the header area for each output vector
file.

Processing Dynamic Sequences

While processing dynamic sequences, write_vectors only creates dynamic timeplates
that are unique. In other words, if a cycle of a dynamic sequence matches an already existing
dynamic sequence then the first dynamic sequence is used. For example, if the release cycle
of a dynamic sequence matches the capture cycle of any dynamic sequence, then the first
encounter cycle of the dynamic sequence is used and referenced throughout the output
vector files. In addition, if the option limittimeplates is specified to yes and the release
timeplate matches the capture timeplate then write_vectors defines only the capture
timeplate.

February 2022 33 Product Version 21.11

Specify -compressdynamictimeplates no to disable the automatic compression of

dynamic timeplates.

Changing Default Pin Order

As an optional input, you can provide a file that includes the order in which to sequence pin
data while creating test data. Use the write_vectors option -pinorder <pinorder
file name> to specify a pin order file.
Note: If you do not specify a pin order file, the command writes the pin data in the order they
were configured in the Modus model (PIentry and POentry order).

Define the order of pins in the file by including the pin names separated by one or more blank
spaces. Block and line comments are supported in the file.

Tip
If the pin order specified for an invocation of write_vectors differs from the
previously used order, you must recreate the test vectors for the previously exported
Test_Sections.

Limiting Dynamic Timeplates for Vectors

Specify -limittimeplates yes to limit the number of timeplates for the test vectors. When
you set -limittimeplates yes, Modus defaults the singletimeplate option to yes,
which limits the test and scan timeplates to 1. If dynamic timings exist, then two additional
dynamic timeplates are created, the Release timeplate and the Capture timeplate.

Specifying the options as mentioned above results in the following dynamic timeplate
configuration for write_vectors:
■ The dynamic clock events use the timeplates in the order of Release and Capture. For
example, the first dynamic clock event goes in the Release timeplate, the second
dynamic clock event goes in the Capture timeplate, the third event in the Release
timeplate, and so on.
■ The dynamic Stim_PI events are included in the timeplate associated with the next
dynamic clock event.
■ All Measure PO events are in the Capture timeplate.

February 2022 34 Product Version 21.11

Creating Cycle Map for Output Vectors

Use the cyclemap option to generate cycle information for the output vectors.
The cyclemap option can have any of the following values:
■ yes (default) - creates the cycle map file for all scan and PO measures. All output vectors
will be created.
■ only - creates the cycle map only for all scan measures. No output vectors will be
created.
■ measures - creates the cycle map file for all scan and PO measures. No output vectors
will be created.
■ no - does not create a cycle map file

The generated cycle map file is named as

cycleMap.<testmode>|.<inexperiment> and saved in the workdir/
testresults/EXPORTDIR directory.
// Total Relative Relative Test CPP Pattern Event Cycle Scan Relative
// Cycle Cycle Simulation Seq Test Odometer Type Offset Length Scan
// Count Count Time(ns) Number Number Number
//----------------------------------------------------------------------------------
// The vector file output name: STIL.FULLSCAN.IDDq.ex1.ts1.stil
3 3 160 1 1 1.1.1.2.1.1 Scan_Load 0 4 1
6 6 480 1 1 1.1.1.2.1.1 end_of_scan 3 0 1
8 8 560 1 1 1.1.1.2.1.3 Measure_Current 8 0 1
9 9 640 2 2 1.1.1.3.1.1 Scan_Load 0 4 2
12 12 960 2 2 1.1.1.3.1.1 end_of_scan 3 0 2
14 14 1040 2 2 1.1.1.3.1.3 Measure_Current 6 0 2
15 15 1120 3 3 1.1.1.4.1.1 Scan_Load 0 4 3
18 18 1440 3 3 1.1.1.4.1.1 end_of_scan 3 0 3
20 20 1520 3 3 1.1.1.4.1.3 Measure_Current 6 0 3
21 21 1600 4 4 1.1.1.5.1.1 Scan_Load 0 4 4
24 24 1920 4 4 1.1.1.5.1.1 end_of_scan 3 0 4
26 26 2000 4 4 1.1.1.5.1.4 Measure_Current 6 0 4
28 28 2160 5 5 1.1.1.6.1.1 Scan_Load 0 4 5
31 31 2480 5 5 1.1.1.6.1.1 end_of_scan 3 0 5
33 33 2560 5 5 1.1.1.6.1.3 Measure_Current 7 0 5
34 34 2640 6 6 1.1.1.7.1.1 Scan_Load 0 4 6
37 37 2960 6 6 1.1.1.7.1.1 end_of_scan 3 0 6
39 39 3040 6 6 1.1.1.7.1.3 Measure_Current 6 0 6
...................
...................
...................

The cycle map file has the following columns:

■ Total Cycle Count - write_vectors starts from the top of TBDbin with value zero
and continues to count the cycles across all output files.
■ Relative Cycle Count - Beginning from the top of each output vector file,
write_vectors starts the cycle count at zero on every new output file.
■ Relative Simulation Time - The simulation time relative to the specific file.

February 2022 35 Product Version 21.11

■ Test Sequence Number - The test sequence number in the TBDbin.

■ Pattern Odometer - The odometer value of the reported test sequence in the TBDbin.
■ Event Type - The event type associated with the reported test sequence in the TBDbin.
■ Cycle Offset - This is zero at the start of the scan event and the end of the scan event,
the value is scan length - 1. For all measure_PO events, this value is -1.
■ Scan Length - The number of clock shifts during a scan operation.
■ Relative Scan Number - Number of scan operations processed at the specific point
relative to the file.

Adding Wait Cycles to Output Vectors

Use the options that start with waitcycle to add time at various points in the output vectors.
Depending on the option, the cycles added may be test cycles, scan cycles, or init cycles. If
the sequence is optional, then the waitcycle associated with that sequence is only used if the
sequence exists.

The following topics show the order of the sequences and where the wait cycles would be
added if the associated waitcycle* option was specified.
■ Order of Scan Sequences with Wait Cycle Locations
■ Order of Sequences in Test Vector for Basic Static Tests
■ Order of Sequences in Test Vector for Basic Delay Tests

February 2022 36 Product Version 21.11

Order of Scan Sequences with Wait Cycle Locations

Scan Operation (scanop) - Consists of the following
■ Scan Section (scansection) - sequence to unload/load subset, of scan flops
❑ Scan Entry (scanentry)1 - set up special state (e.g., TAP controller state) for scan
waitcyclebeforescanprecond (test cycles) (if scan load in modeinit; init cycles)
❑ Scan Section Preconditioning (scanprecond)1 - set the design state to initialize scan
❑ Channel Mask Load (channnelmaskload)2 - load compresion channel mask registers
❍ Channel Mask Preconditioning (channelmaskprecond)1 - enable load from CMI
waitcyclebeforemaskload (scan cycles)
❍ Channel Mask Cycle (channelmaskcycle)
❍ Channel Mask Exit (channelmaskexit)1
waitcycleaftermaskload (scan cycles)
waitcyclebeforescan (scan cycles)
❑ Scan Sequence (scansequence) - clock sequence to unload/load flops
❑ Non-looped Scan Sequence (scanlastbit)2 - scan the last bit if needed
❑ MISR Observe (misrobserve)2 - for opmisr; observe values in MISR at MO pins
❍ Events to get to MISR observe state
waitcyclemisrobserve (scan cycles)
❍ Measure MISR Data
❑ Endup Sequence (endup)2 - for BIST; deactivate PLL or quiesce state prior to read MISR
❑ Signature Observe (sigobs)2 - for bist or opmisr no MO;observe the values in the MISR
❑ MISR Reset (misrreset)2 - sequence to reset the MISR values
❑ Scan Section Exit (scansectionexit)1 - end a scan section
waitcyclebeforescanexit (scan cycles)
❑ Scan Exit Sequence (scanexit)1 - leave scan state and set up state for test (capture)
waitcycleafterscan (test cycles) (if scan load in modeinit; init cycles)
❑ Load Suffix Sequence (loadsuffix)2 - move scanned values to connected non-scan flops

See Modus: Reference: Test Pattern Formats for more information about sequences.
Note:
1
■ Optional part of sequence
■ 2 Optional sequence depending on your methodology

February 2022 37 Product Version 21.11

Order of Sequences in Test Vector for Basic Static Tests

■ Test Mode Init Sequence
■ Setup Sequence2
❑ OPCG Load2 - Load_OPCG_Controls not loaded via scan has a separate opcgload sequence
consisting of the following:
❍ opcgprecon1
waitcyclebeforeopcgscan (scan cycle)
❍ opcgcycle
❍ opcgexit1
waitcycleafteropcgscan (test cycle)
■ Test Sequence
❑ 1st Scan Load - see Order of Scan Sequences with Wait Cycle Locations for sequences
❑ Stim PI / Wait Osc
waitcyclebeforepulse (test cycle)
❑ Pulse
waitcyclebeforemeasurepo (test cycle)
❑ Measure PO
❑ Scan Unload / Scan Load for next test (or Channel Scan) - see Order of Scan Sequences with Wait
Cycle Locations for sequences

See Modus: Reference: Test Pattern Formats for more information about sequences.
Note:
■ 1 Optional part of sequence
2
■ Optional sequence depending on your methodology

February 2022 38 Product Version 21.11

Order of Sequences in Test Vector for Basic Delay Tests

■ Test Mode Init Sequence
■ Setup Sequence2
❑ OPCG Load2 - Load_OPCG_Controls not loaded via scan has a separate opcgload sequence
consisting of the following:
❍ opcgprecon1
waitcyclebeforeopcgscan (scan cycle)
❍ opcgcycle
❍ opcgexit1
waitcycleafteropcgscan (test cycle)
■ Test Sequence
❑ 1st Scan Load - see Order of Scan Sequences with Wait Cycle Locations for sequences
❑ Stim PI / Wait Osc
waitcyclebeforedynamic (test cycle)
❑ Pulse (release)
❑ Pulse (capture)
waitcycleafterdynamic (test cycle)
❑ Scan Unload / Scan Load for next test (or Channel Scan) - see Order of Scan Sequences with Wait
Cycle Locations for sequences

See Modus: Reference: Test Pattern Formats for more information about sequences.
Note:
■ 1 Optional part of sequence
2
■ Optional sequence depending on your methodology

Output Vector Considerations for ATE

The Automated Test Equipment (ATE) has the following formats:
■ Standard Test Interface Language (STIL)
■ Waveform Generation Language (WGL)
■ Test Description Language (TDL)

February 2022 39 Product Version 21.11

Asynchronous Oscillators with ATE

Synchronous oscillators are explicitly pulsed as many times as required in each tester cycle.

Asynchronous Oscillators are oscillators running independently of tasks.

Examples of both types of oscillators are given below:

# Synchronous Oscillator – refclk is +OSC
[ Pattern;
Event Start_Osc (pulses_per_cycle=1,up 25.00ns): "refclk"=+;
] Pattern;

# Asynchronous Oscillator – refclk is +OSC

[ Pattern;
Event Start_Osc (up 25.00ns): "refclk"=+;
] Pattern;

In this release, STIL or WGL does not clearly support asynchronous oscillators as they do not
contain Start_OSC event for those oscillators. write_vectors generates the error message
TVE-389 when that occurs.

Comments in STIL/WGL data files, as shown below, indicates that you must have manually
started asynchronous oscillator by this point.
Comment in STIL/WGL data file.
// Start asynchronous oscillator on pin CLK2

Writing Standard Test Interface Language (STIL)

Write Vectors accepts either a committed vectors or an uncommitted vectors file for a
specified test mode and translates its contents into files that represent the TBDbin test data
in STIL format.
■ To write STIL vectors via the GUI, select STIL as the Language option on the Write
Vectors form
■ To write STIL vectors using commands, specify -language stil for write_vectors.

STIL Restrictions
The following restrictions apply:
■ Test data created for an assumed scan chain test mode cannot be written.
■ Overlapping is not allowed when using diagnostic measure events.

February 2022 40 Product Version 21.11

STIL Output Files

Write Vectors creates the following output files in STIL format:
■ An uncommitted input TBDbin.testmode.inexperiment file results in one or
more files named
STIL.testmode.inexperiment.testsectiontype.ex#.ts#.stil in the
specified directory.
■ A committed input TBDbin.testmode vectors file results in one or more files named
STIL.testmode.inexperiment.testsectiontype.ex#.ts#.stil in the
specified directory.
■ Input of either uncommitted vectors or committed vectors results in a file named
STIL.testmode.inexperiment.signals.stil in the specified directory if the
option to generate this file is selected.
The testmode and inexperiment fields contain the testmode and uncommitted
test names from the source TBDbin file.

The testsectiontype field contains the test section type value from the TBDbin and is
used to identify the type of test data contained within the STIL file, for example, logic.

The ex#, ts#, and optional tl# fields differentiate multiple files generated from a single
TBDbin. The TBDbin hierarchical element id is substituted for #, i.e., ex# receives the
uncommitted test number within the TBDbin, ts# receives the test section number within the
uncommitted test, and tl# receives the tester loop number within the test section.

Committed and uncommitted TBDbins contain test coverage and tester cycle count
information for each test sequence.

The optional signals file contains declarations common to the STIL vector files, for example,
I/O signal names, in order to eliminate redundant definition of these elements.

The preceding files represent default names if option outputfilename (or Write Vectors
form field Set the output file names) is not specified. If a value for outputfilename is
specified, multiple output files are differentiated by the presence of a numeric suffix appended
to the file name. For example, multiple committed vectors files are named
outputfilename_value.1.stil, outputfilename_value.2.stil, and so on.
The signals file is named outputfilename_value.signal.stil.

February 2022 41 Product Version 21.11

Writing Waveform Generation Language (WGL)

Write Vectors accepts either a committed vectors or an uncommitted vectors file for a
specified test mode and translates its contents into files that represent the TBDbin test data
in WGL format.
■ To write WGL vectors via the GUI, select WGL as the Language option on the Write
Vectors form
■ To write WGL vectors using commands, specify -language wgl for write_vectors.

WGL Restrictions
The following restrictions apply:
■ Test data created for an assumed scan chain test mode cannot be written.
■ Overlapping is not allowed when using diagnostic measure events.

WGL Output Files

Write Vectors creates the following output files in WGL format:
■ An uncommitted input TBDbin.testmode.inexperiment file results in one or
more files named
WGL.testmode.inexperiment.testsectiontype.ex#.ts#.wgl in the
specified directory.
■ A committed input TBDbin.testmode vectors file results in one or more files named
WGL.testmode.inexperiment.testsectiontype.ex#.ts#.wgl in the
specified directory.
■ Input of either uncommitted vectors or committed vectors results in a file named
WGL.testmode.inexperiment.signals.wgl in the specified directory if the
option to generate this file is selected.
The testmode and inexperiment fields contain the testmode and uncommitted
test names from the source TBDbin file.

The testsectiontype field contains the test section type value from the TBDbin and is
used to identify the type of test data contained within the WGL file, for example, logic.

The ex#, ts#, and optional tl# fields differentiate multiple files generated from a single
TBDbin. The TBDbin hierarchical element id is substituted for #, i.e., ex# receives the

February 2022 42 Product Version 21.11

uncommitted test number within the TBDbin, ts# receives the test section number within the
uncommitted test, and tl# receives the tester loop number within the test section.

Committed and uncommitted TBDbins contain test coverage and tester cycle count
information for each test sequence.

The optional signals file contains declarations common to the WGL vector files, for example,
I/O signal names, in order to eliminate redundant definition of these elements.

The preceding files represent default names if option outputfilename (or Write Vectors
form field Set the output file names) is not specified. If a value for outputfilename is
specified, multiple output files are differentiated by the presence of a numeric suffix appended
to the file name. For example, multiple committed vectors files are named
outputfilename_value.1.wgl, outputfilename_value.2.wgl, and so on.
The signals file is named outputfilename_value.signal.wgl.

Writing Test Description Language (TDL)

Write Vectors accepts either a committed vectors or an uncommitted vectors file for a
specified test mode and translates its contents into files that represent the TBDbin test data
in TDL format.

To write TDL vectors using commands, specify -language tdl for write_vectors.

TDL Restrictions
The following restrictions apply:
■ Test data created for an assumed scan chain test mode cannot be written.
■ Overlapping is not allowed when using diagnostic measure events.

TDL Output Files

Write Vectors creates the following output files in TDL format:
■ Input of either uncommitted vectors or committed vectors results in a file named
<pattern_set_name>_#.tdl in the specified directory.
■ Input of either uncommitted vectors or committed vectors results in a signals file named
<pattern_set_name>.signals.tdl in the specified directory if the option to
generate this file is selected.

February 2022 43 Product Version 21.11

The optional signals file contains declarations common to the TDL vector files, for
example, I/O signal names, in order to eliminate redundant definition of these elements.
pattern_set_name is the pattern set name specified in the input config file and # is
the test section number within the test.

The preceding files represent default names if option outputfilename (or Write Vectors
form field Set the output file names) is not specified. If a value for outputfilename is
specified, multiple output files are differentiated by the presence of a numeric suffix appended
to the file name. For example, multiple committed vectors files are named
outputfilename_value.1.tdl, outputfilename_value.2.tdl, and so on.
The signals file is named outputfilename_value.signal.tdl.

Writing Verilog
Write Vectors accepts either a committed vectors or an uncommitted vectors file for a
specified test mode and translates its contents into files that represent the TBDbin test data
in Verilog format.
■ To write Verilog vectors via the GUI, select Verilog as the Language option on the Write
Vectors form
■ To write Verilog vectors using commands, specify -language verilog for
write_vectors.

Parallel vs Serial Timing

Parallel Verilog patterns always measure the nets at the time frame 0 as opposed to serial
patterns that measure the nets at other poissible times. Overriding the Test or Scan Strobe
Offsets must have the measures before any stimulus to get the correct parallel simulation
results.

Miscompares in parallel mode result are reported on internal nets at the beginning of the scan
cycle and are not flagged on a specific scan out pin.

Parallel Simulation of Vectors Generated with -simshifts Option

ATPG can be run with the -simshifts option to improve coverage in specific situations.
Refer to Simulating Values of Non-scan Flops in Modus: User Guide: ATPG for more
information.

February 2022 44 Product Version 21.11

When ATPG vectors are generated with -simshifts, then parallel simulation must account
for this using the -explicitshifts option for write_vectors.

write_vectors automatically adjusts the -explicitshifts value to at least the -

simshifts value. This may slightly increase the parallel simulation runtime. In such case,
the message TVE 318 is issued.

You can override the -explicitshifts value to add more explicit shifts. If you override the
-explictshifts value and specify a value too low then the tool issues warning message TVE-
319.

Pattern Simulation with Cadence OPCG Logic

Simulation miscompares of the serial or parallel patterns with Cadence OPCG enabled may
occur when the duration of the scan phase (loading/unloading of the scan chains) does not
provide sufficient time for the OPCG logic to reset. OPCG requires a minimum amount of time
to be spent in the scan phase to allow the OPCG logic to reset. The OPCG reset time
depends on frequency and ensures that sufficient oscillator clock cycles have occurred for a
number of operations within the OPCG logic to have completed. So, if the duration of the scan
phase is shorter than the OPCG reset time (due to a slow PLL or due to short scan chains),
then the scan phase needs to be extended by a number of idle wait cycles to reach the
minimum number of required OPCG reset cycles.

The required OPCG reset time will be automatically computed and applied by
write_vectors. If needed, it can be overridden by using write_vectors option
waitcyclebeforescanexit.

Computation of the OPCG reset time is not needed for the following scenarios:
■ If your slowest PLL output clock is 3x or faster than the scan clock, there will likely be no
issues with parallel pattern simulation.
■ Serial simulation is in general less likely to exhibit such issues, unless the maximum scan
chain length in the design is extremely short.

Verilog Restrictions
The following restrictions apply:
■ Test data created for an assumed scan chain test mode cannot be written.
■ Overlapping is not allowed when using diagnostic measure events.

February 2022 45 Product Version 21.11

Verilog Output Files

Write Vectors creates the following output files in Verilog format:
■ An uncommitted input TBDbin.testmode.inexperiment file results in one or
more files named
VER.testmode.inexperiment.testsectiontype.ex#.ts#.verilog in
the specified directory.
■ A committed input TBDbin.testmode vectors file results in one or more files named
VER.testmode.inexperiment.testsectiontype.ex#.ts#.verilog in the
specified directory.
■ Input of either uncommitted vectors or committed vectors results in a file named
VER.testmode.inexperiment.signals.verilog in the specified directory if the
option to generate this file is selected.
The testmode and inexperiment fields contain the testmode and uncommitted
test names from the source TBDbin file.

The testsectiontype field contains the test section type value from the TBDbin and is
used to identify the type of test data contained within the Verilog file, for example, logic.

Committed and uncommitted TBDbins contain test coverage and tester cycle count
information for each test sequence.

The optional signals file contains declarations common to the Verilog vector files, for example,
I/O signal names, in order to eliminate redundant definition of these elements.

The preceding files represent default names if option outputfilename (or Write Vectors
form field Set the output file names) is not specified. If a value for outputfilename is
specified, multiple output files are differentiated by the presence of a numeric suffix appended
to the file name. For example, multiple committed vectors files are named
outputfilename_value.1.verilog, outputfilename_value.2.verilog,
and so on. The mainsim file is named outputfilename_value.mainsim.v.

Xcelium Considerations
When using Write Vectors for subsequent simulation by Xcelium, the following options may
be specified for Xcelium:

February 2022 46 Product Version 21.11

+DEBUG Specify this option to trace the process flow.

+HEARTBEAT Specify this option to produce progress status messages.
+FAILSET Specify this option to produce a Chip-Pad-Pattern record for
each miscomparing vector. Refer to “Reading Failures” in the
Modus: Guide 9: Diagnostics.
+START_RANGE Specify an odometer value to indicate the beginning of a
pattern range to be simulated.
+END_RANGE Specify an odometer value to indicate the end of a pattern
range to be simulated.
+TESTFILEnum=filename
Specify an input data file to Xcelium. Specify multiple files by
incrementing the num string. For example, specify
+TESTFILE1=data1 +TESTFILE2=data2.
+DEFINE+sdf_annotate
Write_vectors Verilog output includes conditional code to invoke
SDF timing annotation. Include this code through the above
compiler directive. Be careful to ensure that the correct SDF file
name is referenced. (Edit the Verilog testbench or use xmelab
-SDF_FILE <file name>, if necessary).
+DEFINE+<SDF_Minimum|SDF_Typical|SDF_Maximum>
If you request sdf_annotate you then must choose between
Min, Typical, and Max timing data within the SDF file.
+DEFINE+simvision Specify this optional compiler directive option to compile code
proprietary to Cadence Design Systems., Inc. Do not include
this for non-Cadence simulators. This command enables the
automatic dump of waveform data but does not invoke a
waveform dump.
+simvision Specify this nonmandatory option to invoke the SimVision dump
of waveform data during simulation.
+vcd Specify this nonmandatory option to invoke the SimVision dump
of VCD data during simulation.

The following is an example syntax:

February 2022 47 Product Version 21.11

xmxlmode \
+DEFINE+simvision \
+simvision \
+vcd \
+HEARTBEAT \
+FAILSET \
+START_RANGE=1.1.1.1.1.1. \
+END_RANGE=1.1.14.1.8 \
VER.${TESTMODE}*mainsim.v \
+TESTFILE1=VER.testmode.data.testsection.ex.ts1 \
+TESTFILE2=VER.testmode.data.testsection.ex.ts2

Another Xcelium option is to set SEQ_UDP_DELAY+<delay in ps> during elaboration state

to allow Modus to add some delay to the sequential elements. This option can help fix many
miscompares when running in a zero delay simulation mode.

An example to add 50ps delay is given below:

If using Xcelium Verilog command line:
xmverilog \
+ncseq_udp_delay+50ps \

Specify the following if using the Xcelium Elaboration command line:

xmelab \
-seq_udp_delay 50ps \

Using the TB_VERILOG_SCAN_PIN Attribute

The TB_VERILOG_SCAN_PIN model attribute is used to control the selection of scan, stim,
and measures points in exported Verilog test vectors when specifying the write_vectors
scanformat=parallel option, or via the graphical user interface, selecting a Scan
Format of parallel.

The TB_VERILOG_SCAN_PIN attribute may be placed on any hierarchical pin on any cell.
However the pin must be on the scan path (or intended to be on the scan path if used within
a cell definition).

When encountered on input pins, the parent net associated with the attributed pin is selected
as a stimuli net. When encountered on output pins, the associated parent net is selected as
a measure net. This attribute may be selectively used, i.e., default net selection takes place
if no attribute is encountered for a specific bit position.

The following example depicts the placement of the TB_VERILOG_SCAN_PIN attribute on an

instance within a cell:
DESFQ
\$blk_DESFQ$14
(.Q ( \$net__G001 ) //! TB_VERILOG_SCAN_PIN="YES"

February 2022 48 Product Version 21.11

,.C ( \$net__H05 )
,.D ( \$net__H01 ) //! TB_VERILOG_SCAN_PIN="YES"
,.R ( \$net_NET$1 )
,.S ( \$net_NET$2 )
);

Test Pattern Analysis

Test Pattern Analysis is the process of:
■ Taking data from manual patterns or a test generation process;
■ Simulating the patterns to determine if the expected responses match the actual values;
and then
■ Analyzing any miscompares to determine the cause of the problem.

Debugging Miscompares
Miscompares can be caused by various factors, some of which are given below:
■ The model is logically incorrect
■ The model does not account for the delay mode requirements of the simulator that
generated the original data (or the one that is being used for the re-simulation). For
example, if the cell description has some extra blocks to model some logical
configuration, the unit delay simulator may find that signals do not get through the logic
on time since it assigns a unit of delay to each primitive in the path. This might work better
with a zero delay simulation.
■ The input patterns are incorrect (either due to an error in the manually generated
patterns; or due to a problem with the original simulation).

The following are some recommended considerations while analyzing the patterns:
1. The first thing to consider is where the “expected responses” come from.
❑ If you are writing manual patterns, the expected responses are included in these
patterns as an Expect_Event (see “TBDpatt and TBDseqPatt Format” in the Modus:
Reference: Test Pattern Formats).
❑ If you are analyzing a TBD from a test generation process, the simulation portion of
that process creates measures to indicate that the tester should measure a
particular set of values on primary outputs and/or latches. When you resimulate the

February 2022 49 Product Version 21.11

test data, the simulator compares its results with the previous results specified by
measure events (Measure_PO and Scan_Unload).
2. The next thing to consider is the analysis technique you plan to use. This choice will
influence the type of simulation to use for the re-simulation. Using the Test Simulation
application, you may select a variety of simulation techniques. In addition, there is an
interactive simulation technique specifically aimed at test pattern analysis (and
diagnostics).

Some analysis techniques are given below:

1. Use the following process to view the miscomparing patterns in a waveform display:
❑ Create a Watch List containing all the nets, pins, and/or blocks you want to include
in the analysis. This Watch List can be created:
❍ Interactively through the Modus View Schematic window or the Watch List
window (refer to Watch List in the Modus: Reference: GUI)
❍ Manually (refer to “Using Watch List” on page 51 for more information)
❑ Select either the General Purpose Simulation or the Good Machine Delay
Simulation options from the Simulate Vectors windows since they are the only ones
that support this type of analysis. Set the appropriate simulation run parameters to
specify the watch list you are using, the specific test data during which simulation
should be saved for viewing, and any other desired options.
❑ When the simulation ends, click either the View Waveforms icon or Windows -
Show - Waveforms. The Select Optional Transition File dialog is displayed.
❑ Select the transition file (.trn) for the test mode and experiment run at the time of
simulation and click the Open button. A SimVision window is displayed with a set of
signals that define the correspondence between the Modus vector format and the
waveform window timeline.
❑ Use SimVision facilities to select and display design signals of interest. Refer to
“SimVision Overview” on page 53 for additional information.
2. To view the miscomparing patterns on the graphical view of the design, use View
Vectors to select a test sequence analyze and invoke View Circuit Values to see the
values displayed on the View Schematic window.
See “SimVision Overview” on page 53 and “General View Circuit Values Information” in
the Modus: Reference: GUI for more information.
3. If you are satisfied after viewing the patterns and the model and making your own
correlation of the data or, if you are limited to this choice by the data you are analyzing,
then use the following process:

February 2022 50 Product Version 21.11

a. Select your choice of simulation.

b. View the resulting patterns using View Vectors.

c. View the logic on the Modus View Schematic window and manually analyze the
problem.

Using Watch List

You can use a watch list to create and customize a list of design objects for input to various
Modus applications using either the graphical interface or by manually specifying it. See
“Watch List” in the Modus: Reference: GUI for details.

February 2022 51 Product Version 21.11

To manually create a watch list, use the following syntax and semantics:
■ Each line in the file is a statement, which can be of one of the following types:
Model Object Statement
Each Model Object Statement identifies one Modus Model Object by type and name. It
also allows you to specify an alias name for the Object. The syntax of the statement is
the Model Object name optionally followed by the alias name. The Model Object name
in the full name or short name format. The simple name should have a type specified
before the name. The types are NET, PIN, or BLOCK. If a type is not specified, then net
is assumed first, then pin, and then block. The alias name can be any combination of
alpha-numeric or the following special characters:
!#$%&()+,-.:<=>?@[]^_`|~.
Note: If an entry is a BLOCK, Modus will create a watch list for all ports/pins on that
block. Refer to “expandnets” on page 52 for information on how to identify signals within
a BLOCK.
Facility Start Statement
The Facility Start statement marks the beginning of a group of Model Objects that will be
associated together. The statement syntax is the word FACILITY followed by white space
followed by a facility name and ending with an open brace '}'. The facility name must start
with an alphabetic character. It may contain alpha-numeric characters or underscores. It
cannot end in an underscore nor have more than one underscore repeated. These are
the same rules for identifiers in VHDL. The name will always be folded to upper case and
is therefore case insensitive. When the same facility name appears more than once in
the file, only one facility by that name is created containing all the Model Objects
associated with the facility. It is an error to nest facilities. Here is an example Facility Start
Statement:
FACILITY TARGET {

Facility End Statement

The Facility End Statement marks the end of the group of Model Objects defined by the
previous Facility Start Statement. It is simply a close brace ’}’ character as the first
character of a line. It is an error to have a Facility End without a corresponding Facility
Start. It is an error to nest facilities.
expandnets
Use this syntax to direct Modus to record net switching for all nets within the specified
level or hierarchy. This facility must be named expandnets. For example,
facility expandnets {
block xyz
block abc
}

February 2022 52 Product Version 21.11

directs Modus to record net switching activities for all nets within block xyz and block
abc.
Comments
The characters ’//’ and ’/*’ begin a comment. Comments are allowed at the end of a
statement or on a line by itself. Once a comment is started, it continues to the end of the
line.
■ An example of a watch list:
facility unit_a_buss_byte_0 {
"unit_a.buss_out[7]"
"unit_a.buss_out[6]"
"unit_a.buss_out[5]"
"unit_a.buss_out[4]"
"unit_a.buss_out[3]"
"unit_a.buss_out[2]"
"unit_a.buss_out[1]"
"unit_a.buss_out[0]"
}

facility expandnets {
block unit_b
block unit_c
}

"sys_clock"
"a_clock"
"b_clock"
"init_a.sys_clock"

There can be only one statement per line. Each statement must be on a single line.

SimVision Overview
You can use SimVision to analyze simulation results. Its capabilities include:
■ Displaying digital waveforms
■ Displaying values on nets during any time period in a simulation
■ Arranging signals (move, copy, delete, repeat, show, hide) in the window for easy
viewing, enabling better interpretation of results
■ Multiple waveform graphs per window
■ Multiple windows that allow you to organize data and to view multiple test data segments
■ Annotating waves with text
■ Performing logical and arithmetic operations on waveforms

February 2022 53 Product Version 21.11

A .dsn or .trn file can be input to SimVision for waveform analysis. The files can be created
by either running test generation or simulation applications or from View Vectors by selecting
a test section with scope data then clicking the custom mouse button to invoke Create
Waveforms for Pin Timing. Refer to the description for the View Vectors “View Pull-down”
in the Modus: Reference: GUI.

To view Modus patterns in SimVision, perform the following steps:

1. Click the View Waveforms icon on the main toolbar. Start SimVision by entering
simvision at the command prompt.
2. Open a .trn file for the experiment on the resulting Select Optional Transition File
dialog.

The following is an alternative method:

1. Invoke Simvision using this syntax: simvision -input showall.sv.
showall.sv is a Simvision script file that contains:
❍ database open path/TBscope.testmode.experiment.trn
❍ browser new
❍ waveform new
❍ set waves [browser find -name *]
❍ waveform add -signals $waves

Refer to the SimVision User Guide for additional details.

Performing Test Pattern Analysis

For details on using the graphical interface for analyzing and viewing test data, refer to
“Viewing Test Data” in the Modus: Reference: GUI.
Note: You can perform Test Pattern Analysis only through graphical user interface.

Prerequisite Tasks
■ Select an experiment.
■ Create a Vectors file by running a test generation or simulation application.

February 2022 54 Product Version 21.11

Input Files

An existing Modus experiment, sequence definition files, and failure data (if existing).

Output Files

If Create Minimum Vectors is selected on the Test View window, a new Vectors file is
created as output.

Understanding the Test Sequence Coverage Summary

The following is a sample Test Sequence Coverage Summary Report produced by
write_vectors:
--------- -------- -------- -------- -------- -------- ---------- ------
Test Static Static Dynamic Dynamic Sequence Overlapped Total
Sequence Total Delta Total Delta Cycle Cycle Cycle
Coverage Coverage Coverage Coverage Count Count Count
--------- -------- -------- -------- -------- -------- ---------- ------
1.1.1.1.1 0.00 0.00 0.00 0.00 1 0 1
1.1.1.2.1 38.31 38.31 24.14 24.14 17 7 18
1.1.1.2.2 54.55 16.24 32.18 8.04 10 7 28
1.1.1.2.3 64.94 10.39 35.63 3.45 11 0 39

The preceding report is produced for STIL, Verilog, and WGL vectors.

Figure 1-5 on page 56 shows a graphical representation of the scan cycles for the reported
vectors:

February 2022 55 Product Version 21.11

Figure 1-5 Scan Cycle Overlap in Test Sequence Coverage Summary Report

The output log includes the following columns:

■ Test Sequence - shows the sequence for which the test coverage and tester cycle
information is reported
■ Static Total Coverage - shows the static fault coverage for the test sequence
■ Static Delta Coverage - shows the difference in static fault coverage between the
current and the preceding vector. For example, the static fault coverage for vector
1.1.1.2.2 is 54.55 while the coverage of the preceding vector 1.1.1.2.1 is 38.31.
Therefore, the difference in the coverage by the two vectors is 16.24, which is reported
in the Static Delta Coverage column.
■ Dynamic Total Coverage - shows the dynamic fault coverage for the test sequence
■ Dynamic Delta Coverage - shows the difference in dynamic fault coverage between
the current and the preceding vector. For example, the dynamic fault coverage of vector
1.1.1.2.2 is 32.18 and the coverage of the preceding vector 1.1.1.2.1 is 24.14. Therefore,
the difference in the coverage by the two vectors is 8.04, which is reported in the
Dynamic Delta Coverage column.
■ Sequence Cycle Count - shows the clock cycles taken by the test sequence

February 2022 56 Product Version 21.11

■ Overlapped Cycle Count - shows the cycles that are overlapping with the next
reported vector. For example, for vector 1.1.1.2.1, out of 17 cycles, 7 cycles overlap with
the next vector 1.1.1.2.2.
While calculating the Sequence Cycle Count for a vector, the cycles overlapping with
the preceding vector are ignored.
For example, as shown in the figure, out of the 17 cycles taken by vector 1.1.1.2.2, 7
cycles overlap with the preceding vector 1.1.1.2.1. Therefore, though vector 1.1.1.2.2
takes total of 17 cycles, the 7 cycles that overlap with the preceding vector 1.1.1.2.1 are
ignored and not reported in the Sequence Cycle Count column for the vector.
■ Total Cycle Count - shows the cumulative sequence cycle count of the current and
all preceding vectors. For example, the total cycle count reported for vector 1.1.1.2.2 is
the combination of the cycle count for this vector (10) and all the vectors reported before
it, i.e, 1.1.1.2.1 (17) and 1.1.1.1.1 (1). Therefore, the reported cycle count for the vector
is 28.

Parallel Verilog Simulation for LBIST

LBIST requires Serial Verilog Simulation. In serial simulation you can have millions of cycles
and it takes long simulation time.

Parallel Verilog Simulation verifies the functional logic paths exercised in LBIST in lesser time
and ensure that there are no design issues.

In Parallel Verilog Simulation flow, patterns are converted from LBIST to XOR format. In this
process, parallel loading is done and each test is observed. The OPCG clock is directly forced
on the outputs, to pulse the capture clocks. It simulates the load and unload values for all the
tests. This flow verifies the functional logic paths (for example: SDC) and does basic scan. It
does not verify the logic not participating in LBIST parallel simulation (for example: LBIST
controller, OPCG, PRPG and Mask).

February 2022 57 Product Version 21.11

Figure 1-6 LBIST Parallel Verilog Simulation Flow

create_lbist_tests command simulates user specified LBIST test sequences.

covert_vectors_to_stored_pattern command breaks each of the signature based

test vectors individually and converts them to stored pattern format.
The following is a recommended command string:
convert_vectors_to_stored_pattern -TESTMODE <string> -WORKDIR <string> -EXPERIMENT
<string> -INEXPERIMENT <string> -choppers safe|risky -parentmode yes|no

where:
■ -WORKDIR <string> specifies the top level directory that contains data for the design.
■ -TESTMODE <string> specifies the name of the test mode to be processed.
■ -EXPERIMENT <string> identifies the name associated with the output of test
generation or simulation process
■ -INEXPERIMENT <string> identifies the data to be processed. The name specified is
the name used for the -EXPERIMENT option in the program that created the data.
■ -parentmode yes|no specifies whether or not to convert lbist patterns to stored
patterns in parent mode.

Refer to covert_vectors_to_stored_pattern -h or man

covert_vectors_to_stored_pattern for the command syntax and supported options.

February 2022 58 Product Version 21.11

write_vectors command is used to write out the test vectors in the specified language.

A sample command invocation for the flow, is shown below:

write_vectors -testmode LBIST -inexperiment lbist -language verilog -scanformat
serial
convert_vectors_to_stored_pattern -testmode LBIST -inexperiment lbist -experiment
lbist_parallel
write_vectors -testmode LBIST -inexperiment lbist_parallel

Comparing Output
In Figure 1-7 on page 59, the left column shows the report_vectors command output
after create_lbist_tests command and the right column shows the report_vectors
command output after create_vectors_to_stored_pattern command.

Figure 1-7 Comparing outputs of report_vectors command

Limitation
■ You cannot use the parallel simulation with SDF annotated simulation, because the
OPCG domain clocks are pulsed by the testbench and not the OPCG logic.
■ It is recommend to run enough patterns in a Serial simulation to verify the functional
logic.

February 2022 59 Product Version 21.11

Writing System Verilog for Hardware Simulation

To write System Verilog vectors using commands, specify -language verilog_hw for
write_vectors.

The option -language verilog_hw creates a System Verilog test bench and test data files
for Cadence Hardware emulation based simulation.

Supported Options
Common write_vectors options supported for -language verilog_hw are:
■ -testmode
■ -inexperiment
■ -waitcycles*
■ -exportdir
■ -limitcomments

System Verilog Output Files

By default, the System Verilog vectors are stored in workdir/testresults/verilog_hw.

Test Bench File

The Test Bench filename is *.mainsim_hw.sv, where * is the same naming convention as
the standard Verilog test bench:

VER.<testmode_name>.<optional_experiment_name>.mainsim_hw.sv

Test Data Files

These are groups of files for each test section for a testmode/experiment. Multiple verilog_hw
files are generated per pattern set.

February 2022 60 Product Version 21.11

*.mainsim_hw.sv performs a $readmem on all files in the set and loads all pattern data
into memory

Sample Output

The command usage:

write_vectors -testmode FULLSCAN -language verilog_hw -scanformat serial

generates the following sample output:

Simulating with Palladium

This section explains the steps for simulation and defining PLL’s for Palladium.

Simulation Steps
1. Setup and compile. Sample specification is given below.
export XCELIUM_INCISIVE_COMPATIBILITY_MODE = 1
export XE_HOST = sw-scd1
export XE_BOARDS = 5.0-5.1

February 2022 61 Product Version 21.11

XEHOME = /lan/cva_rel/vxe165/16.5.09
TOP_MODULE = CHIP_COMPRESSION_DECOMP
ixcom:
xrun -c -hw -ua -64 \
+dut+${TOP_MODULE} +bc+${TOP_MODULE} \
+gfifoDisp+${TOP_MODULE} +enableDispInLoop+${TOP_MODULE} \
\
-ixcomargs "-vaelabargs -parallel -vaelabargs 10" \
+xmtimescale+1ns/1ps +xmoverride_timescale \
-log ixcom.log \
\
-v./library.v
./chip_top.test_netlist.v \
\
-v ${XEHOME}/share/vxe/etc/ixcom/IXCclkgen.sv \
./pll_clocks_ixcom.sv \
./testresults/verilog_hw/VER.COMPRESSION_DECOMP.mainsim_hw.sv

❑ Lines starting with export... represent host machine and number of boards to
target the compile for.
❑ 2 boards in same cluster are specified
❑ Simulation can use any machine with same configuration
❑ Simulation will run any available boards meeting this configuration
❑ -hw and -ua and required options for Palladium compile and simulation
❑ Line -ixcomargs "-vaelabargs -parallel -vaelabargs 10"
❑ Includes optional arguments for distributed compile
❑ Remove this line to compile using 1-processor
❑ Current settings use 10-processors for compile
❑ Line -v ${XEHOME}/share/vxe/etc/ixcom/IXCclkgen.sv
❑ IXCclkgen.sv is required to identify Palladium clock functions that are used. This
file is loaded from VXE installation directory
❑ Line ./pll_clocks_ixcom.sv \
❑ pll_clocks_ixcom.sv is the Palladium model for PLL’s (generated based on
user input). Refer to “Using PLL’s with Palladium” on page 63 for more information.
❑ Line ./testresults/verilog_hw/
VER.COMPRESSION_DECOMP.mainsim_hw.sv
❍ *.mainsim_hw.sv is the Palladium Test Bench from write_vectors
❍ TOP_MODULE must be set to this Test Bench Module name

February 2022 62 Product Version 21.11

2. Simulate. Sample specification is shown below.

xrun -xedebug -host sw-scd1 -R -64 -input xrun.script

❑ -host option is used to simulate on specified Palladium machine (sw-scd1 in the

example)
❑ xrun is the input script to start simulation in batch mode. If not specified, simulation
will not occur. A sample xrun script is shown below:
sim -restart +HEARTBEAT -log
sim.verilog_hw.COMPRESSION_DECOMP.scan.ex1.ts1.log \ +COMMANDFILE=.
testresults/verilog_hw/VER.COMPRESSION_DECOMP.scan.ex1.ts1
xc on -xt0 -zt0 –tbrun
run
sim -restart +HEARTBEAT -log
sim.verilog_hw.COMPRESSION_DECOMP.logic.ex1.ts2.log \
+COMMANDFILE=./testresults/verilog_hw/VER.COMPRESSION_DECOMP.logic.ex1.ts2
xc on -xt0 -zt0 –tbrun
run
exit

❍ + HEARTBEAT is the optional *.mainsim_hw.sv setting and prints

odometer being simulated
❍ The script simulates one COMMANDFILE prefix at a time; all individual files are
read based on this prefix and separate logs (-log) are created for each
simulation
❍ -xt0/-zt0 is specified to treat X’s and Z’s as 0’s (Palladium requires only 0 or
1 values)

Using PLL’s with Palladium

write_vectors handles free-running PI Clocks (Modus OSC pins). PLL simulation models
cannot be compiled to Palladium and must be specified and used to generate a Palladium
model for the PLL clock outputs.

Steps to generate Palladium PLL clock output models:

1. Create a file to define PLL’s to Palladium. Definition for a sample file,
pll_clocks_ud.qel, is shown below:
clockOption -add { technology CAKE 2}
clockFrequency -add
{CHIP_COMPRESSION_DECOMP_OPCG_top_compression.top_inst.n_608 1000 MHz}
clockFrequency -add
{CHIP_COMPRESSION_DECOMP_OPCG_top_compression.top_inst.n_609 500 MHz}

where n_608/n_609 represents the nets connected to each PLL output clock, and 1000
MHz/500 MHz is the PLL output clock frequency.
2. Generate Palladium PLL models for simulation using the following command:

February 2022 63 Product Version 21.11

ixclkgen –input <user-defined file with PLL definitions> –output <file to

save PLL model> –module <module>

For example, the following command generates PLL model using the file
pll_clocks_ud.qel defined in step 1 and saves the generated model in
pll_clocks_ixcom.sv:
ixclkgen –input pll_clocks_ud.qel –output pll_clocks_ixcom.sv –module
clock_ixcom

3. Compile the PLL model for simulation using the xrun command. For example
xrun … \
./pll_clocks_ixcom.sv \

Restrictions
This section discusses limitations related to hardware emulation-based simulation and
current scope of support in Modus.

Hardware Emulation-based Simulation Limitations

■ Patterns are applied in a fixed order:
Initial Block -> Stim/Measure -> @posedge(fast_clk) -> Stim/Measure ->
@posedge(fast_clk) -> …

❑ fast_clk is the hardware emulator’s free running master clock

❑ Stim and Measure of 0 and 1 - there are no X and Z logic states
■ verilog_hw requires 0-delay simulation / Unit Delay and SDF annotation are incompatible
❑ Hardware simulation is event driven. Advancing time is based on posedge of
fast_clk
❑ SDF annotation and unit delay simulation setting are incompatible with hardware
emulation
■ write_vectors options to specify timings are not supported:
❑ Timing of inputs clocks - for example “init*”, “scan*”, “test*”, “release*”, “capture*”, …
❑ Timing of Stims and Measures/Strobes - for example *offset*
❑ Timing length of a tester cycle - for example “*period”
❑ Timing templates - for example “limittimeplates”, “usedelaytimings”, “timingfile”

February 2022 64 Product Version 21.11

Current Scope of Support in Modus

■ Parallel simulation on hardware emulation is not allowed (write_vectors -language
verilog_hw -scanformat parallel). Serial simulation using hardware emulation
is supported (write_vectors -language verilog_hw -scanformat serial).
Serial simulation is used for hardware emulation because it performs extremely well and
leaves little room to reduce simulation time. For parallel simulation on hardware
emulation, the simulation time reduction is offset by a significantly greater increase in
compile time for parallel simulation.
■ Only following testmodes are supported in the current release:
❑ FULLSCAN and XOR Compression
❑ OPCG
❑ Pipelines - SI/SO, CME
■ Following are not supported:
❑ 2D Elastic, SmartScan, 1149, MBIST, LBIST Testmodes
❑ OPMISR testmodes, ‘diagnosticmode’ or ‘sigobs’ testmodes for measuring MISR
values
❑ Parallel Simulation (write_vectors -language verilog_hw -scanformat
parallel). This is because it requires significantly more hardware resources and,
therefore, more compile time to map the millions of internal parallel load and unload
points.
■ write_vectors -language verilog_hw should only be used for Palladium-based
simulation. For Xcelium-based simulation, use write_vectors -language
verilog.

February 2022 65 Product Version 21.11

February 2022 66 Product Version 21.11

2
Reporting Test Data

You can report the binary TBDbin test vectors generated by Modus into an ASCII (TBDpatt)
file. This is useful when you need to understand how the generated test vectors exercise your
design.

To verify cell models created to run with Modus, you can simulate vectors created by our
system with other transistor level simulators. To do this, it is necessary to expand the scan
chain load and unload data into individual PI stims, clock pulses, and PO measures. Select
the Expand scan operations option on the Report Vectors Advanced form or specify the
option pair expandscan=yes on the command line to expand any scan operations found in
the test data.

To report Modus vectors using the graphical interface, refer to “Report Vectors” in the Modus:
Reference: GUI.

To report Modus vectors using command line, refer to report_vectors -H or man

report_vectors for information on command syntax and supported options.

The syntax for the report_vectors command is given below:

report_vectors -workdir <directory> -testmode <modename> -experiment <name>

where:
■ workdir - name of the working directory
■ testmode - name of the testmode of experiment to export pattern
■ experiment- name of the experiment from which to export data

The commonly used options for the report_vectors command are:

■ -format vector|node - Specify the pattern format. Vector produces a smaller file
but requires vector correspondence to find individual bit information. Default is vector.
■ -vectorcor yes|no - Whether to include vector correspondence data. Default is no.
■ -outputfile STDOUT|<outfilename> - Output file name or STDOUT. Default is
output file name which is written to the testresults directory.

February 2022 67 Product Version 21.11

■ -testrange <odometerRange> - Select a range of tests. Default is all patterns.

Input Files for Reporting Test Data

report_vectors requires a valid model and experiment or committed test data as input.

Output Files for Reporting Test Data

The report_vectors command produces the following default output files:
■ Reporting committed vectors results in a file named TBDpatt.testmode in the
<workdir>/testresults directory.
■ Reporting expanded committed vectors results in a file named
TBDpatt.testmode.experiment.EXPANDSCAN in the in the <workdir>/
testresults directory.
■ Reporting uncommitted vectors results in a file named
TBDpatt.testmode.experiment in the <workdir>/testresults directory.
■ Reporting expanded uncommitted vectors results in a file named
TBDpatt.testmode.experiment.EXPANDSCAN in the <workdir>/
testresults directory.
■ The output file name can be changed by specifying the outputfile=<filename>
option for the report_vectors command or by entering the file name in the GUI
Output file name entry field.

February 2022 68 Product Version 21.11

3
Reading Test Data

Test vectors from other formats can be read into Modus. Test vectors are read and stored into
the Modus format called TBDbin. You can then use these test vectors in TBDbin format as
input to any Modus command that takes existing experiments.

You can read from the following types of formats:

■ Modus Pattern Data (TBDpatt)
■ Standard Test Interface Language (STIL)
■ Extended Value Change Dump (EVCD) file

To read Modus Pattern Data using the graphical interface, refer to “Read Vectors” in the
Modus: Reference: GUI.

To read Modus Pattern Data using command lines, use read_vectors -H or man
read_vectors for information on command syntax and supported options.

The syntax for the read_vectors command is given below:

read_vectors -workdir <directory> -testmode <modename> -experiment <name>
-language <type> -importfile <filename>
where:
■ workdir = name of the working directory
■ testmode= name of the testmode for dynamic ATPG
■ experiment= name of the output experiment resulting from simulation
■ language= type of patterns to be imported
■ importfile= location of patterns to be imported

The most commonly used options for the read_vectors command are:
■ -language stil|tbdpatt|evcd - Type of language in which the patterns are being
read

February 2022 69 Product Version 21.11

■ -importfile STDIN|<infilename> - Allows a filename or piping of data

■ -uniformsequences no|yes - STIL import options to create test procedures with
uniform clocking sequences. Default is no.
■ -identifyscantest no|yes - STIL import options to identify a scan integrity test, if
exists.

Prerequisite Tasks
Complete the following tasks before running Test Simulation:
1. Import a design into the Modus model format. Refer to “Performing Build Model” in the
Modus: Guide 1: Models.
2. Create a Test Mode. Refer to “Performing Build Test Mode” in the Modus: Guide 2:
Testmodes.
3. Have the test patterns in the supported format.

Read Vectors Restrictions

The following restrictions apply to conversion of all test data formats:
■ TBDpatt that contains Load or Unload events, most likely created by Convert Vectors
for Macro Tests, cannot be read.
■ Conversion of vectors produced from designs with grandparent test modes is not
supported. Refer to "Building Multiple Test Modes" in the Modus: Guide 2: Testmodes
for related information.

Reading Modus Pattern Data (TBDpatt)

You can read TBDpatt files into Modus. TBDpatt data files produced by writing test data
can be edited and resimulated by Modus. This gives you the ability to perform uncommitted
test with test vectors as you work to achieve additional fault coverage on a design. For
information on how to create TBDpatt format data, refer to Writing Test Data on page 15.

TBDpatt is the recommended format for entering manually generated test vectors into
Modus because the following reasons:
■ TBDpatt format translates directly into TBDbin format

February 2022 70 Product Version 21.11

The probability of information loss is less when translating between TBDpatt and
TBDbin formats.
■ TBDpatt format can be easily created
You can create a TBDpatt file for input to Modus by first generating test vectors (even
just random ones) and then converting the resulting TBDbin file into a TBDpatt file. You
can then edit the TBDpatt file to reflect the desired primary input and latch stimulus
values.

To read Modus Pattern Data using the graphical interface, refer to “Read Vectors” in the
Modus: Reference: GUI.

To read Modus Pattern Data using command lines, use read_vectors -H or man
read_vectors for information on command syntax and supported options..

Modus Pattern Data Output Files

Modus Pattern Data stores test vectors in an uncommitted vectors file with the format
TBDpatt.testmode.experiment. You must specify an uncommitted test name, which
will identify the read test vectors.

Reading Standard Test Interface Language (STIL)

Modus reads data that conforms to the IEEE 1450-1999 STIL, Version 1.0 standard. The
TBDbin produced by STIL can be used by any Modus simulation or conversion tool that
accepts TBDbin format.

Initial support for STIL that conforms to the IEEE 1450.1 standard is available. Refer to
“Support for STIL Standard 1450.1.”

Modus reads, parses, and performs semantic checks on the constructs found in the input
STIL file in addition to validating structural references and test vector data.

For information on Modus STIL pattern data, refer to the following sections of the Modus:
Reference: Test Pattern Formats.
■ “STIL Pattern Data Format”
■ Appendix E, “STIL Pattern Data Examples”

February 2022 71 Product Version 21.11

Support for STIL Standard 1450.1

Modus currently supports reading the IEEE P1450.1 standard constructs as follows:
■ The WFCmap construct within the Signals Block
■ X (cross-reference) statements
■ Useroptions statement extension
■ resource_id tags (1450.3)
■ InheritWaveForTable
■ Specify block with multiple Category definitions
■ WaveFormTable with signal blocks having definitions for waveform characters
■ Parse-only support for the following constructs:

ActiveScanChains, AllNames, CellIn, CellOut, Constant, Cycle, Data, Design, E,

Else, Enumeration, Enumerations, Environment, Equivalent, Extend, Fixed,
FileFormat, FileReference, FileType, FileVersion, Format, If, Independent,
InitialValue, Instance, Iteration, InheritEnvironment, InheritNameMap, Integer,
IntegerConstant, IntegerEnum, Lockstep, NameMaps, Offset, ParallelPatList,
PatSet, PatternOffset, Real, ScanChainGroups, ScanEnable, SignalVariable,
SignalVariableEnum, SyncStart, TagOffset, Type, Usage, Values, Variables,
Version, Wait,While

Support for STIL Standard 1450.2

Modus currently has parse-only support for the following IEEE 1450.2 standard constructs:
■ DCLevels
■ Environment

STIL Restrictions
It is strongly recommended that the STIL data that you read should be in a Modus-generated
file, produced by Writing Standard Test Interface Language (STIL) on page 40. The results
for STIL data generated outside of Modus are not guaranteed.

February 2022 72 Product Version 21.11

STIL scan protocol must match the scan procedures automatically generated by Modus.
Custom Scan Protocol procedures are not supported. If you do use custom scan protocol, we
recommend that the read tests be simulated prior to sending data to the tester.

Modus does not support reading STIL data for designs with scan pipelines in compression
testmodes.

Identifying Scan Tests in STIL Vectors

A sequence is a scan test if the following conditions are present:
1. The first event in the sequence is the Scan_Load event.
2. The Scan_Load event loads all scan strings with alternating pairs of 1’s and 0’s. Note
that this may start at any point (for example, 00110011..., 011001100..., 11001100..., or
1011001100...).
3. There may be optional Stim_PI and Measure_PO events after the first event and before
the last event.
4. If there are any pulse events after the first event and before the last event, these pulse
events may only pulse clocks flagged as scan clocks.
5. The last event in the sequence is the Scan_Unload event. The Scan_Unload event
measures alternating pairs on each scan chain.

Identifying Mode Initialization Sequences in STIL Vectors

The read_vectors command, when working on STIL input data, compares the initial
patterns in the input STIL data against the mode initialization sequence as identified while
creating the test mode.

This comparison helps identify the mode initialization sequence even when the end of the
sequence is merged with the first real test pattern in the STIL data.
Note: The read_vectors command compares only the events directly controlled by the
tester. Internal events in the mode initialization sequence, such as the stimulation of pseudo-
primary inputs or the pulsing of pseudo-primary input, clocks will be ignored in this
comparision.

If the first few STIL vectors match the mode initialization sequence, then read_vectors
replaces the matching vectors with the mode initialization sequence identified for this test
mode.

February 2022 73 Product Version 21.11

This replacement enables the resulting TBDbin (binary file of TBDPatt) to correctly identify
any internal events associated with the mode initialization. This enables read_vectors to
support the automatic creation of internal events for the mode initialization sequence, but not
for normal test patterns.

If the first few patterns in the STIL data do not match the mode initialization sequence
identified in the test mode, then the read_vectors command explicitly adds a mode
initialization sequence from the TBDseq file to the output patterns before converting any of
the STIL vectors. This makes sure that the mode initialization sequence occurs before the
patterns in the STIL data in the resulting test pattern file.

As the mode initialization sequence is taken from the TBDseq file, this comparision will also
correctly identify it as a mode initialization sequence in the resulting TBDbin file. When you
resimulate the patterns, the simulator will not insert another copy of the mode initialization
sequence.
Note: The read_vectors command does not identify a mode initialization sequence that
is functionally equivalent to the mode initialization sequence of the test mode, but does not
exactly match the test mode initialization sequence.

Reading Extended Value Change Dump (EVCD) File

Xcelium-Verilog creates extended value change dump (EVCD) files that conform to the IEEE
1364-2001 Verilog standard. You can then read the EVCD file into Modus for creating Verilog
test vectors, simulating and fault grading functional vectors, and detecting and analyzing
miscompares.

An EVCD file is an ASCII file that contains information about value changes on selected
variables in the design. The file contains header information, variable definitions, and the
value changes for all specified variables. Modus accepts EVCD files through the Read
Vectors application.

To produce EVCD output from the Cadence Xcelium Simulator, add the following code in the
Verilog testbench.
initial $dumpports (< instance > ,"My_Functional_Patterns.EVCD",,2) ;

where:

<instance> = The instance name of the logic block whose ports are to be dumped. This is
usually the chip under test.

My_Functional_Patterns.EVCD = ASCII file that Xcelium Simulator will produce.

Specifying quotes is mandatory. This file will be imported into Modus.

February 2022 74 Product Version 21.11

,,2 = Formatting place holders for $dumpports. 2 produces the specific variation of the
EVCD output that Modus accepts. This format conforms to the IEEE standard.

For more information on creation and content of the files, refer to the following sections in
Cadence® Xcelium-Verilog® Simulator Help:
■ Generating a Value Change Dump (VCD) File
■ Generating an Extended Value Change Dump (EVCD) File for a Mixed-Language Design
■ Generating an Extended Value Change Dump (EVCD) File

Tip
It is recommended to follow some rules while reading EVCD:
❑ Ensure that the input data only changes when the clock(s) are OFF.
❑ Do not have the data and clock signals changing at the same time.
❑ Do not have overlapping clocks (unless they are correlated).

To read the generated EVCD file into Modus using the graphical interface, refer to “Read
Vectors” in the Modus: Reference: GUI. Select EVCD for Input Format.

To read the generated EVCD file into Modus using command lines, specify read_vectors
-language evcd.

Tip
The TBDbin consists of a single Experiment, Test_Section, and Tester_Loop. The
type of Test_Section created in the TBDbin depends on the specified value for
testtype or Test section type if using the GUI. The default Test_Section type is
logic. Refer to Test Data for Manufacturing on page 85 for more information.
The termination option sets the tester termination value to be assumed for the
Test_Section. The default termination setting is none.
The inputthreshold option defines the input threshold. Signals less than or equal to
the specified threshold are interpreted as Z.
The outputthreshold option defines the output threshold. Signals less than or equal
to the specified threshold are interpreted as X.
The measurecyclesboundary option is used to insert a Measure_PO event on a
cycle boundary when no measure exists in the EVCD input.

February 2022 75 Product Version 21.11

EVCD Restrictions
When a user requests that Modus import EVCD patterns, it usually is with the expectation
that functional test patterns will be fault simulated. However, the following limitations are to be
considered:
■ The functional patterns are imported as STATIC patterns. You cannot fault simulate and
have Modus detect DELAY or PATH Delay faults. Fault simulation will only detect STATIC
faults.
■ Static fault detection may be disappointing. Note that a fault is detected only when it
reaches a measure point. For functional patterns only the chip output pins are measure
point. Faults that propagate to internal Register, Parity and Error checking logic are not
declared detected. Those faults must further propagate to an output pin.
■ The concept of an internal strobe point similar to $fs_strobe for Cadence Verifault is
not available.
■ The write_vectors output of these captured patterns, by default, has static fault
timing. The tester cycle is 80ns and the Stim, Pulse and Measure events are widely
spaced. Users who want to run these patterns at functional clock speeds need to adjust
the timings via write_vectors parameters and verify with SDF annotate timing in
Xcelium.
■ Modus supports only the single variable type of port. A message is issued if a port of any
other variable type is detected.

EVCD Output
EVCD values that refer to Primary Inputs are translated to Stim_PI or Pulse events.
Primary Output values are translated to Measure_PO events. Refer to “Event” in the Modus:
Reference: Test Pattern Formats for descriptions of these events.

February 2022 76 Product Version 21.11

4
Reporting Test Sequences

Modus supports the reporting of sequence definitions. The report_sequences command

reports sequence definitions in TBDpatt format. Sequence definitions identify the patterns
used to establish the testmode initialization state and to perform the scan operation. These
are not used by themselves to drive a tester, but are useful in the ASCII TBDpatt format for
analysis or to be used as a basis for writing custom mode initialization or scan sequences.
For more information about test mode initialization or custom sequences, refer to “Mode
Initialization Sequences (Advanced)” and Defining a Custom Scan Sequence in the Modus:
Guide 2: Testmodes.

To report sequence definition data using the graphical interface, refer to “Report Sequences”
in the Modus: Reference: GUI.

To report sequence definition data using command line, refer to report_sequences -H or

man report_sequences for information on command syntax and supported options.

The syntax for the report_sequences command is given below:

report_sequences -workdir <directory> -testmode <modename>

where:
■ workdir = name of the working directory
■ testmode= name of the testmode to report the sequences on

The commonly used options for the report_sequences command are:

■ -format vector|node - Specify the pattern format. Vector produces a smaller file
but requires vector correspondence to find individual bit information. Default is node.
Node format is required if the file is used for future build_testmodes processes.
■ -outputfile STDOUT|<outfilename> - Output file name or STDOUT. Default is
output file name which is written to the testresults directory.

February 2022 77 Product Version 21.11

Input Files for Reporting Sequence Definition Data

report_sequences requires a valid model and testmode as input.

Output Files for Reporting Sequence Definition Data

Reporting Modus sequence definitions results in a file named TBDseqPatt.testmode in
the <workdir>/testresults directory.

The output file name can be changed by specifying the -outputfile <filename> option
for the report_vectors command or by entering the file name in the GUI Output file
name entry field.

Reporting a Structure-Neutral TBDbin

The structure-neutral file can be printed using the command
report_vectors_for_macro_tests.

The output of convert_vectors_for_macro_tests can be reported and viewed using

the report_vectors_for_macro_tests command. Performing
convert_vectors_for_macro_tests is a prerequisite to executing
report_vectors_for_macro_tests.
Note: report_vectors_for_macro_tests reads only the data produced by
convert_vectors_for_macro_tests.

Use report_vectors_for_macro_tests -H or man

report_vectors_for_macro_tests for information on command syntax and supported
options.

The syntax for the report_vectors_for_macro_tests command is given below:

report_vectors_for_macro_tests -workdir <directory> -inputfile <file>

where:
■ workdir - name of the working directory
■ inputfile - file name of exported data

February 2022 78 Product Version 21.11

Input for Reporting Structure-Neutral TBDbin

The output from convert_vectors_for_macro_tests, TBDtdm.cellname, is the input
to report_vectors_for_macro_tests.

Output for Reporting Structure-Neutral TBDbin

Specify any meaningful path/filename to write the output.
Note: This output is disallowed as input to read_vectors (tbdpatt) or
read_sequence_definition_data.

February 2022 79 Product Version 21.11

February 2022 80 Product Version 21.11

5
Reading Test Sequences

Besides reading tests in the form for direct application, Modus also supports reading test
sequence definitions. Tests are patterns that you want to capture and apply as part of
manufacturing pattern set. Sequence defintions are used to define specific custom
operations within a pattern set. These custom operations are then used by Modus ATPG. For
example, you may have a sequence that uniquely initializes the circuit to a starting state. Or
you may have a set of sequences that define a set of complicated transition from functional
mode to scan shift mode and from scan shift to back to functional mode. Modus allows a set
of robust sequences to be incorporated into the ATPG pattern set.

There are two broad categories of sequence definitions:

■ Test
This type of sequence defines the clocking template for a set of tests in terms of which
clocks are to be pulsed, and in what order. The test sequence also specifies any other
events that are to be applied, such as the scan operation and stims, on any pins that do
not vary across tests.
■ Others
A sequence definition of any type other than test is used for operations that prepare for
a test or read out the results of a test. There are many different such types, for example
scan preconditioning (scanprecond) and scansequence. Refer to Define_Sequence in
the Modus: Reference: Test Pattern Formats to know more about the sequence
definition types recognized by Modus.

A sequence definition is similar to a subroutine in programming. It is not necessary for every

sequence definition to have a recognized type. User-written sequence definitions can, in
general, invoke other sequence definitions might not have an identified 'type'.

After reading the test vector, you can use the Test Simulation application to simulate the
vectors. You can choose to perform good machine or fault machine simulation and forward or
reverse vector simulation.

To read Sequence Definition Data using the graphical interface, refer to “Read Sequence
Definition” in the Modus: Reference: GUI.

February 2022 81 Product Version 21.11

To read Sequence Definition Data using command lines, use

read_sequence_definition -H or man read_sequence_definition for information
on command syntax and supported options.

The syntax for the read_sequence_definition command is given below:

read_sequence_definition -workdir directory> -testmode <modename> -importfile
<filename>

where:
■ workdir = name of the working directory
■ testmode= name of the testmode for dynamic ATPG
■ importfile= location of sequences to import

The most commonly used option for the read_sequence_definition is:

-importfile STDIN|<infilename> - Allows a file name or piping of data

Sequence Definition Data Output Files

Sequence definition data produces the file TBDseq. testmode that contains the
initialization sequences.

February 2022 82 Product Version 21.11

6
Test Data Utilities

Create Vector Correspondence Data

When the input TBDpatt file contains vector format data, there must exist a specification of
the correspondence between vector bit positions and design pins and blocks. This
correspondence data is contained in a file (TBDvect) that is separate from the TBDpatt data.
The data is maintained separately since it is concerned only with formatting, and not data
content. The same vector format file is used both for importing TBDpatt data and for printing
a TBDpatt file.

There is a single vector correspondence file per test mode. The intent is that there be only
one set of vector correspondence data ever used for a given mode. Making changes to the
vector correspondence file should be undertaken only with utmost caution. If you want to
import a TBDpatt file that was produced by Modus, the vector correspondence must not be
altered during the interim.

You can change the ordering within vectors by changing the positions of pins or latches in the
vector correspondence file. This may be useful if you are going to use TBDpatt as an
intermediate interface to some other format which requires that the vectors be defined in a
specific way. In such a case, you might be able to modify TBDvect in such a way as to avoid
re-mapping the vectors in another conversion program.

Test data written in vector format contains a Vector_Correspondence section consisting of

commented lines. Vector correspondence data is stored in the TBDvect file. The vector
correspondence lists define each position of the vectors that are used in stim events, measure
events, and weight events. For example, the fifth position in a Stim_PI vector is the value to
be placed on the fifth input in the primary input correspondence list.

The vector correspondence data includes the following lists:

■ Primary Input Correspondence List
■ Primary Output Correspondence List
■ Stim Latch Correspondence List

February 2022 83 Product Version 21.11

■ Measure Latch Correspondence List

■ MISR Latch Correspondence List
■ PRPG Latch Correspondence List

A scan design in Modus, even if composed of flip-flops is always modeled using level-
sensitive latches. Each latch that is controlled by the last clock pulse in the scan operation
must necessarily end up in the same state as the latch that precedes it in the register. In rare
circumstances, the preceding latch may also be clocked by this same clock, and then both
latches have the same state as the next preceding latch (and so on). Some latches may be
connected in parallel, being controlled by the same scan clock and preceded by a common
latch. These latches also must end up at a common state. Modus identifies all the latches that
have common values as the result of the scan operation, and each such set of latches is said
to be “correlated”. TBDpatt does not explicitly specify the value for every latch, but only for
one latch of each group of correlated latches. This latch in each group is called a
“representative stim latch” or “representative measure latch”, depending upon whether the
context is a load operation or an unload operation. The Stim Latch Correspondence List is a
list of all the latches that can be independently loaded by a scan or load operation. This
consists mainly of the representative stim latches, but contains also “skewed stim latches”
which require special treatment for the Skewed_Scan_Load event described in the Modus:
Reference: Test Pattern Formats. The Measure Latch Correspondence List is a list of the
representative measure latches.

In the case of PRPG and MISR latches, used for built-in self test, similar correlations may
exist; the representative latches for these are called “representative cell latches”. The PRPG
and MISR correspondence lists include the representative cell latches for the PRPGs and
MISRs respectively.

See TBDpatt and TBDseqPatt Format in the Modus: Reference: Test Pattern Formats for
information on vector correspondence language definition.

To perform Create Vector Correspondence using the graphical interface, refer to “Write Vector
Correspondence” in the Modus: Reference: GUI.

To perform Write Vector Correspondence using command line, refer to

write_vector_correspondence -H or man write_vector_correspondence for
information on command syntax and supported options.

The syntax for the write_vector_correspondence command is given below:

write_vector_correspondence -workdir <directory> -testmode <modename>

where:
■ workdir = name of the working directory

February 2022 84 Product Version 21.11

■ testmode= name of the testmode

Create Vector Correspondence Output

If creating the vector correspondence file, the output will be written into tbdata/
TBDvect.<TESTMODE NAME>.

Specify -vectorcor yes to include the output in TBDpatt files.

Test Data for Manufacturing

There is no one vector format accepted by all component manufacturers. Therefore, Modus
provides these vector formats that can be used for interfacing with various manufacturers.
1. TBDbin - the compact binary format used by Modus applications can also be used as a
manufacturing interface. The TBDbin, together with various other Modus files are
packaged into a Modus Manufacturing Data (TMD) file which is accepted by
manufacturing sites.
2. Waveform Generation Language (WGL)** - this format can be translated to many tester
formats using Fluence Technologies, Inc. WGL In-Convert applications. Also, some
manufacturers have their own translators for WGL.
See “WGL Pattern Data Format” in the Modus: Reference: Test Pattern Formats for
more detail.
3. Verilog** - this format is used by many manufacturers to drive a “sign off” simulation of
the vectors against the component model prior to fabrication. It can also be translated into
many tester formats by the manufacturers.
See “Verilog Pattern Data Format” in the Modus: Reference: Test Pattern Formats
for more detail on Verilog.
4. Modus Pattern Data (TBDpatt) - The TBDpatt that is output from Modus contains all
the same “manufacturing data” as the TBDbin, WGL, and Verilog forms. The TBDpatt
is an ascii form of the TBDbin.
See “TBDpatt and TBDseqPatt Format” in the Modus: Reference: Test Pattern
Formats for additional information.
5. STIL data - Modus exports test vectors in STIL format, conforming to the IEEE Standard
1450-1999 Standard Test Interface Language (STIL), Version 1.0 standard.
See “STIL Pattern Data Format” in the Modus: Reference: Test Pattern Formats for
additional details.

February 2022 85 Product Version 21.11

Note: See “Writing Test Data” on page 15 for information about creating (exporting) these
test data forms.

Test Vector Forms

Test vectors may be created in any of the following forms:

Static

Static tests are structured to detect static (DC) defects. The detection of DC defects does not
require transitions, so the design is expected to settle completely before the next event is
applied.

Dynamic

Dynamic tests are structured to create a rapid sequence of events. These events are found
inside the dynamic pattern and are identified as release events (launch the transition),
propagate events (propagate the transition to the capture latch) and capture events (capture
the transition). Within the dynamic pattern the events are expected to be applied in rapid
succession. The speed is at the discretion of the manufacturing site, since there are no
timings to describe how fast they can be applied.

Dynamic Timed

Dynamic timed tests are dynamic tests that have associated timings. In this case the speed
with which the events are expected to be applied at the tester is explicitly stated in the timing
data.

Tests for Sorting Product

It is possible to create tests that can be used to sort the product by applying the test at several
rates of speed. Not all manufacturers support this, so you must contact your manufacturer
before sending them test data with several different sets of timing data.

The manufacturing process variation curve is a normal distribution. Sorting the tests is done
by selecting a point on the process variation curve through the setting of the coefficients (best,
nominal, worst) of a linear combination.

February 2022 86 Product Version 21.11

Viewing Test Data

View the test pattern data created by Modus by displaying the hierarchy of a Vectors or
TBDseq file. To access this tool, select Window - Show - Vectors from the main window.
Enter the information as described in “View Vectors Window” in the Modus: Reference:
GUI to display the patterns.

The Vectors hierarchy consists of the following entities:

Experiment
Test_Section
Tester_Loop
Test_Procedure
Test_Sequence
Pattern
Event

See “Test Data for Manufacturing” on page 85 for information about each level of the
hierarchy.

You can perform a variety of tasks using the hierarchy. Its capabilities include:
■ Moving interactively up and down a hierarchy.
■ Expanding and collapsing levels of a Vectors file.
■ Displaying a design view with simulation values.
■ Displaying Details about specific objects in a Vectors file. This consists of information
also available in a TBDpatt file, including data, an audit summary, and a listing of the
contents of the Vectors file for the selected object.
■ Creating a minimum Vectors file containing the minimal amount of data needed to
perform simulation.
■ Displaying Attributes of specific entities in a Vectors file.
■ Displaying simulation results requiring special analysis (for example, miscompare data).
■ Display of failing patterns based on the currently selected failures. See Reading Failures
in the Modus: Guide 9: Diagnostics for more information.

For additional information, refer to:

■ “Viewing Test Data” in the Modus: Reference: GUI.
■ “Test Pattern Analysis” on page 49.

February 2022 87 Product Version 21.11

Reporting Test Sequence Summary

The report_vector_summary program generates a summary of the test sequences
during a test. The summary is in the form of a table containing event types for each test
sequence and the information on the effectiveness in detecting faults.

The vector information is collected and summarized according to test sequences having
similar stream of patterns, events, and clock used. The report considers each unique event
stream as a template and displays it as a string of characters, with each character
representing a different event type.

If you set the vectors option to yes, the report displays the short form of vectors in the
summary. Set the key option to yes to print the description for each character used in the
template string.

The following is a sample vector summary generated for a test pattern by using the
report_vector_summary command with -key yes and -vectors yes:

Key for string format of Test Sequence report

-----------------------------------------------------
S - Stim PI
I - Stim PPI
s - Scan Load
a - Skewed Scan Load
P - Pulse Clock (P is followed by name of the clock is being pulsed)
C - Stim Clock
Q - Pulse PPI (P is followed by name of the clock is being pulsed)
M - Measure PO
m - Scan Unload
b - Skewed Scan Unload
c - Channel_Scan
D - Diagnostic Skewed Scan Unload
d - Diagnostic_Scan_Unload
F - Force
O - Product MISR Signature
X - Any other events

#Sequences %Det #Static #Dynamic 1st Seq Template

---------- ---- ------- -------- ------ --------
#1 1 51.4 338 0 1 scan
#2 23 47.9 315 0 2 sSP(CLOCK)Mm
#3 4 0.6 4 0 25 sSS(CLOCK)MM(CLOCK)
#4 1 0.2 1 0 29 sSMm
#5 2 0.0 0 0 0 init

February 2022 88 Product Version 21.11

----Template #1---- scan

Scan_Load
Stim_PI
Stim_PI
Stim_PI
Pulse(CLOCK)
Measure_PO
Stim_PI
Pulse(CLOCK)
Measure_PO
Stim_PI
Pulse(CLOCK)
Measure_PO
Stim_PI
Pulse(CLOCK)
Measure_PO
Stim_PI
Pulse(CLOCK)
Measure_PO
Scan_Unload
----Template #2---- logic
Scan_Load
Stim_PI
Pulse(CLOCK)
Measure_PO
Scan_Unload
----Template #3---- logic
Scan_Load
Stim_PI
Stim_Clock(CLOCK)
Measure_PO
Stim_Clock(CLOCK)
Scan_Unload
----Template #4---- logic
Scan_Load
Stim_PI
Measure_PO
Scan_Unload
----Template #5---- init

February 2022 89 Product Version 21.11

Stim_PI

The sample report contains three sections:

■ The first section is the key describing the format of the summary. It lists the characters
used in short form of the vectors in the summary and the event type that each character
represents.
■ The second section is the summary of test vectors. The summary contains the following
columns:
❑ #Sequences - shows the number of sequences with event stream matching the
template in the Template column
❑ %Det - shows the percentage of faults detected by the specific sequence. The
percentage is calculated by dividing the number of faults detected by a specific
sequence by the total number of faults detected by all sequences in the experiment.
❑ #Static - shows the number of static faults detected by the sequences
❑ #Dynamic - shows the number of dynamic faults detected by the sequences
❑ 1st Seq - shows the location of the first matching sequence in the pattern set
❑ Template - shows the string describing the template. For the init, scan, and flush
sequences, the summary lists the event type instead of the string. The Key section
describes the characters representing the template string.
■ The third section describes the vectors in each template listed in the summary.

Use report_vector_summary -H or man report_vector_summary for information on

command syntax and supported options.

February 2022 90 Product Version 21.11

Converting Patterns from Compression to Fullscan

This capability allows patterns generated in a compression testmode to be re-targeted for
application in an equivalent fullscan testmode. A typical use of this is to generate
compression patterns for high-volume production and convert these to fullscan for initial
silicon bring-up and ease of debugging miscompares in silicon. This ensures the patterns
applied via fullscan are similar to the final compression patterns instead of re-running ATPG
from scratch in the fullscan mode which can generate different patterns than the final
compression patterns. The command for this capability, convert_comp_to_fullscan,
maps the internal load data from the compression patterns to the respective Fullscan chains
and re-simulates the measure data to adjust the output accordingly.

This command supports both XOR and Elastic based decompressor networks. The following
configurations are not supported:
■ MISR’s compression and architectures that make use of MISR’s, such as OPMISR/
OPMISR+ or LBIST
■ Structure neutral patterns, such as those used in SmartScan, Migrated Hierarchical Test
patterns, and Multiple-Scan Section architectures.
■ If the source testmode makes use of OPCG, the resulting Fullscan testmode will need to
make use of the same OPCG.

As this command does pattern simulation to determine the unload data, the distributed
options present for ATPG are supported by this command. For more details on this, refer to
Distributed Processing (D-ATPG) in the ATPG Guide.

There can be structural differences between the Compression and the Fullscan mode that
require the patterns to be adjusted to prevent miscompares in silicon. Some examples are,
the scan chain order, the presence of pipelines, the bits that make up the Elastic register, and
registers that are controllable or observable in one mode but not the other. To account for
these differences the command re-simulates the data in the FULLSCAN mode to calculate
valid measure data. Because of these differences, the patterns will be similar but not identical
between the two modes. Depending on how much the structures differ, these differences may
also cause differences in test coverage between the two modes.

Example
convert_comp_to_fullscan -testmode <Compression Testmode> -fullscantestmode
<Fullscan Testmode> -inexperiment <Compression Testmode Experiment> -experiment
<The destination exp in the Fullscan mode>

Note: This command will work on committed data in the Compression mode if desired. In
such a case do not specify the inexperiment option.

February 2022 91 Product Version 21.11

February 2022 92 Product Version 21.11

Index

Numerics
1450.1 IEEE standard 60

A
analysis techniques
for test patterns 92

C
circuit values, viewing 93
commit test data 45, 46
commit tests
overview 45
customer service, contacting 15

E
Modus pattern data, exporting
export files 39
input files 39
overview 38
Modus pattern data, importing
output files 59
overview 59
evcd (extended value change dump) data, reading 63
exporting test data
Modus pattern data 38
printing structure-neutral TBDbin 42
sequence definition data 40
standard test interface language (STIL) 27
test data migration (TDM) 41
verilog format 31
waveform generation language (WGL) 28
extended value change dump (evcd) data, reading 63

February 2022 93 Product Version 21.11

F
fault simulation
tasks 78

H
help, accessing 15

I
importing test data
Modus pattern data 59
overview 57
sequence definition data 65
standard test interface language (STIL) 60
infiniteX simulation 87

M
multiclock 84
multipulse 84

O
odometer 51

P
pattern data, importing 59
perform uncommitted tests 46

S
sequence definition data, exporting
sequence definition data, importing
output files 66
overview 65
simulating existing patterns 75
simulating non-Modus patterns 75
simulation 67
simvision, using 99
standard test interface language (STIL), exporting 27
standard test interface language (STIL), importing

February 2022 94 Product Version 21.11

overview 60
restrictions 61
STIL (standard test interface language), importing 60
structure-neutral TBDbin, printing
output file 42
overview 42

T
tb_verilog_scan_pin property 34
TBDbin, structure-neutral 42
TBDpatt format 75
creating vector correspondence 36
TDM (test data migration), exporting
input files 42
output files 42
overview 41
termination values, resolving 88
Test 57
test data
Define_Sequence 51
Event 53
Pattern 53
Test_Procedure 52
Test_Section 52
Test_Sequence 53
Tester_Loop 52
Timing_Data 52
uncommitted test 51
test data migration (TDM), exporting 41
test data, saving 45
test pattern analysis
input files 100
output files 100
performing 100
prerequisite tasks 100
simvision 99
viewing test data 95
test simulation
concepts 75
functional tests 78
infiniteX 87
OPC logic 86
test vectors, creating 54
timings for vector export 20

U
using Modus

February 2022 95 Product Version 21.11

online help 15

V
vector correspondence
creating 36
verilog format, exporting
output files 31
overview 31
restrictions 31
viewing test data 95

W
watch list, overview and syntax 93
waveform generation language (WGL), exporting 28
WGL (waveform generation language), exporting
output files 29
overview 28
restrictions 29

February 2022 96 Product Version 21.11

ICT NOTES 2022 Diploma
100% (1)
ICT NOTES 2022 Diploma
51 pages
Comau Robotics - Motion Programming
No ratings yet
Comau Robotics - Motion Programming
278 pages
Keysight I3070 In-Circuit Test System Board Test Insight: User Guide
No ratings yet
Keysight I3070 In-Circuit Test System Board Test Insight: User Guide
138 pages
Tempus UG
No ratings yet
Tempus UG
500 pages
Modus Ug Testmodes
No ratings yet
Modus Ug Testmodes
281 pages
Modus Ug Testmodes
No ratings yet
Modus Ug Testmodes
279 pages
10050-Sharing EDT Clock With Scan Clock
50% (2)
10050-Sharing EDT Clock With Scan Clock
10 pages
ETS-88 ETS-88 System Manual System Manual: ©2009 - '11 Eagle Test Systems, Inc
100% (2)
ETS-88 ETS-88 System Manual System Manual: ©2009 - '11 Eagle Test Systems, Inc
196 pages
Modus Ug Teststructures
No ratings yet
Modus Ug Teststructures
265 pages
Genus Lowpower
No ratings yet
Genus Lowpower
306 pages
Odb Inside User Mgls
No ratings yet
Odb Inside User Mgls
122 pages
Tempus Cui Ug
No ratings yet
Tempus Cui Ug
567 pages
Icc 2 Tim
No ratings yet
Icc 2 Tim
153 pages
Voltus UG
No ratings yet
Voltus UG
758 pages
Modus Ug Pmbist
No ratings yet
Modus Ug Pmbist
343 pages
Genus Messages
No ratings yet
Genus Messages
2,933 pages
Apb SVT Uvm User Guide
No ratings yet
Apb SVT Uvm User Guide
60 pages
MPD 600 TransformerTest User Manual ENU
No ratings yet
MPD 600 TransformerTest User Manual ENU
41 pages
Simulink Gui
No ratings yet
Simulink Gui
726 pages
Flexlogger - User - Manual - 2024 11 13 20 49 07
No ratings yet
Flexlogger - User - Manual - 2024 11 13 20 49 07
145 pages
Modelsim User
No ratings yet
Modelsim User
820 pages
Modelsim Se User
No ratings yet
Modelsim Se User
1,924 pages
81 1 Welcome Intro Other Editions
No ratings yet
81 1 Welcome Intro Other Editions
310 pages
Modus Ug Pmbist
No ratings yet
Modus Ug Pmbist
261 pages
Hspice Appl
No ratings yet
Hspice Appl
228 pages
In System Test
No ratings yet
In System Test
54 pages
Concept
100% (1)
Concept
162 pages
Eetop - CN Ahb SVT Uvm User Guide
No ratings yet
Eetop - CN Ahb SVT Uvm User Guide
84 pages
Eetop - CN Apb SVT Uvm User Guide
No ratings yet
Eetop - CN Apb SVT Uvm User Guide
61 pages
T-Berd Mts 8000 and T-Berd Mts 6000a
100% (1)
T-Berd Mts 8000 and T-Berd Mts 6000a
396 pages
c5g Controller Unit
No ratings yet
c5g Controller Unit
254 pages
LB RC C5e Motion - en
No ratings yet
LB RC C5e Motion - en
274 pages
SF7 - User Manual
100% (2)
SF7 - User Manual
47 pages
PTM User Manual
No ratings yet
PTM User Manual
86 pages
ORTH-3063 Merge OrthoPACS 8.1 Workstation User Guide
No ratings yet
ORTH-3063 Merge OrthoPACS 8.1 Workstation User Guide
343 pages
Img 20240313113733
No ratings yet
Img 20240313113733
154 pages
Questa Sim User PDF
No ratings yet
Questa Sim User PDF
1,978 pages
Modelsim User
No ratings yet
Modelsim User
854 pages
Simcenter Micred PWT 2400A 2305 ControlSW Guide
No ratings yet
Simcenter Micred PWT 2400A 2305 ControlSW Guide
118 pages
EPOS Command Library en
No ratings yet
EPOS Command Library en
194 pages
Service Manual: Stand and Desktop Systems
No ratings yet
Service Manual: Stand and Desktop Systems
90 pages
Vcs Quickstart
No ratings yet
Vcs Quickstart
94 pages
Allegro PCB Editor User Guide: Preparing Manufacturing Data: Product Version 16.0 June 2007
No ratings yet
Allegro PCB Editor User Guide: Preparing Manufacturing Data: Product Version 16.0 June 2007
132 pages
Eetop - CN Atb SVT Uvm User Guide
No ratings yet
Eetop - CN Atb SVT Uvm User Guide
61 pages
Controllogix High-Speed Analog I/O Module: User Manual
No ratings yet
Controllogix High-Speed Analog I/O Module: User Manual
152 pages
Cadence Design With RTL Compiler Physical PDF
No ratings yet
Cadence Design With RTL Compiler Physical PDF
108 pages
750com Um004 - en P
No ratings yet
750com Um004 - en P
88 pages
Willtek 2305 TETRA Test Set UserGuide
No ratings yet
Willtek 2305 TETRA Test Set UserGuide
194 pages
Mac 800
No ratings yet
Mac 800
122 pages
Programming Manual TDS520
No ratings yet
Programming Manual TDS520
378 pages
Autodesk Product Keys
No ratings yet
Autodesk Product Keys
1 page
POINT I/O Very High-Speed Counter Modules: User Manual
No ratings yet
POINT I/O Very High-Speed Counter Modules: User Manual
46 pages
Lenguage V+ User Guide
No ratings yet
Lenguage V+ User Guide
396 pages
Hspice Integ
No ratings yet
Hspice Integ
440 pages
Will Tek
No ratings yet
Will Tek
416 pages
MAC™ 1200/MAC™ 1200 ST: GE Healthcare
No ratings yet
MAC™ 1200/MAC™ 1200 ST: GE Healthcare
151 pages
Proficy - Logic Developer - PLC 7.0 Getting Started, GFK-1918P
No ratings yet
Proficy - Logic Developer - PLC 7.0 Getting Started, GFK-1918P
176 pages
List of Course 100 LVL To 500 LVL
No ratings yet
List of Course 100 LVL To 500 LVL
1,648 pages
Tutorial: Incisive Enterprise Specman Elite Testbench
No ratings yet
Tutorial: Incisive Enterprise Specman Elite Testbench
104 pages
Done DFT
No ratings yet
Done DFT
95 pages
Live Streaming System Setup Guide: For Small Music Venues and Houses of Worship
No ratings yet
Live Streaming System Setup Guide: For Small Music Venues and Houses of Worship
31 pages
Testing 2
No ratings yet
Testing 2
43 pages
EPOS Command Library (P. 164 - 167)
No ratings yet
EPOS Command Library (P. 164 - 167)
192 pages
Micro870 DNP3 Lab Featuring Connected Components Workbench v21 Software
100% (1)
Micro870 DNP3 Lab Featuring Connected Components Workbench v21 Software
46 pages
Assignment-1 Computer Aided Manufacturing ME-418
No ratings yet
Assignment-1 Computer Aided Manufacturing ME-418
21 pages
Modelsim Pele User
No ratings yet
Modelsim Pele User
706 pages
Augmented Reality in Education
No ratings yet
Augmented Reality in Education
8 pages
Zimulator - Requirements and Installation Guide
No ratings yet
Zimulator - Requirements and Installation Guide
8 pages
Et Ug Pmbist
No ratings yet
Et Ug Pmbist
40 pages
BK 9
No ratings yet
BK 9
137 pages
Cg101pc Labscope Manual
No ratings yet
Cg101pc Labscope Manual
62 pages
06 TM Test Compression
No ratings yet
06 TM Test Compression
7 pages
HTML Image
No ratings yet
HTML Image
11 pages
Chap 1
No ratings yet
Chap 1
15 pages
Easy Ways To Activate Windows 11 For FREE Without A Product Key - MS Guides
No ratings yet
Easy Ways To Activate Windows 11 For FREE Without A Product Key - MS Guides
21 pages
SDC File
No ratings yet
SDC File
2 pages
Fast Recompilation Application Note 1.0
No ratings yet
Fast Recompilation Application Note 1.0
17 pages
Epson RapidReceipt RR-600W Manual
No ratings yet
Epson RapidReceipt RR-600W Manual
183 pages
Chap 9
No ratings yet
Chap 9
50 pages
Neural Networks: CMR Technical Campus
No ratings yet
Neural Networks: CMR Technical Campus
30 pages
E FUSE
No ratings yet
E FUSE
2 pages
Etw9b 3
No ratings yet
Etw9b 3
4 pages
Verification Plan
No ratings yet
Verification Plan
2 pages
DFT Training Tracker Populated
No ratings yet
DFT Training Tracker Populated
2 pages
SW Cap
No ratings yet
SW Cap
19 pages
Chap 4
No ratings yet
Chap 4
23 pages
Chap 4 - D and I of Account Holders Info System For Microfinance Bank (PHP)
No ratings yet
Chap 4 - D and I of Account Holders Info System For Microfinance Bank (PHP)
14 pages
Elmer Gui Manual
No ratings yet
Elmer Gui Manual
41 pages
BC 302 PI Past Papers
No ratings yet
BC 302 PI Past Papers
15 pages
03 - TIA Selection Tool An Overview EN
No ratings yet
03 - TIA Selection Tool An Overview EN
15 pages
3 Axis Pro CAD Rev 2
No ratings yet
3 Axis Pro CAD Rev 2
24 pages
Basic Unfolding
No ratings yet
Basic Unfolding
8 pages
Illuminati Magic Brochure
No ratings yet
Illuminati Magic Brochure
17 pages
RENEEV Report
No ratings yet
RENEEV Report
2 pages
AnalytixLabs Excel Module 4 - 1654544693519
No ratings yet
AnalytixLabs Excel Module 4 - 1654544693519
12 pages
SambaNova - Accelerated Computing With A Reconfigurable Dataflow Architecture - Whitepaper - English
No ratings yet
SambaNova - Accelerated Computing With A Reconfigurable Dataflow Architecture - Whitepaper - English
10 pages
Employee Info
No ratings yet
Employee Info
2 pages
ICT Marking Scheme
No ratings yet
ICT Marking Scheme
8 pages
1st Term Datesheet 2024
No ratings yet
1st Term Datesheet 2024
7 pages
Amharic - Ethiopia Comprehension Test Guidelines-V3-20190321 - 041509
No ratings yet
Amharic - Ethiopia Comprehension Test Guidelines-V3-20190321 - 041509
3 pages
Trendnet: 8-Port Stackable Rack Mount KVM Switch With Osd
No ratings yet
Trendnet: 8-Port Stackable Rack Mount KVM Switch With Osd
2 pages
Project Proposal Waste Management PPT Powerpoint Ideas Summary CPB
No ratings yet
Project Proposal Waste Management PPT Powerpoint Ideas Summary CPB
2 pages
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
1/5 (1)
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
From Everand
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
Matthew C. Smith
No ratings yet