Tessent® MissionMode User’s Manual

Software Version 2018.3

August 2018

Document Revision 4

© 2017-2018 Mentor Graphics Corporation

All rights reserved.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.

Note - Viewing PDF files within a web browser causes some links not to function (see MG595892).
Use HTML for full navigation.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.

The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.

MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.

MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth in
the license agreement provided with the software, except for provisions which are contrary to applicable
mandatory federal laws.

TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: mentor.com/trademarks.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of
Linus Torvalds, owner of the mark on a world-wide basis.

End-User License Agreement: You can print a copy of the End-User License Agreement from:
mentor.com/eula.

Mentor Graphics Corporation

8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: mentor.com
Support Center: support.mentor.com

Send Feedback on Documentation: support.mentor.com/doc_feedback_form

 Revision History

Revision Changes Status/

Date
4 Modifications to improve the readability and comprehension of Released
the content. Approved by Lucille Woo. Aug 2018
All technical enhancements, changes, and fixes listed in the
Tessent Release Notes for this product are reflected in this
document. Approved by Ron Press.
3 Modifications to improve the readability and comprehension of Released
the content. Approved by Lucille Woo. May 2018
All technical enhancements, changes, and fixes listed in the
Tessent Release Notes for this product are reflected in this
document. Approved by Ron Press.
2 Modifications to improve the readability and comprehension of Released
the content. Approved by Lucille Woo. Mar 2018
All technical enhancements, changes, and fixes listed in the
Tessent Release Notes for this product are reflected in this
document. Approved by Ron Press.
1 Modifications to improve the readability and comprehension of Released
the content. Approved by Lucille Woo. Dec 2017
All technical enhancements, changes, and fixes listed in the
Tessent Release Notes for this product are reflected in this
document. Approved by Ron Press.

Author: In-house procedures and working practices require multiple authors for documents. All
associated authors for each topic within this document are tracked within the Mentor Graphics
Technical Publication’s source. For specific topic authors, contact Mentor Graphics Technical
Publication department.

Revision History: Released documents maintain a revision history of up to four revisions. For
earlier revision history, refer to earlier releases of documentation which are available at the
following URL:

http://support.mentor.com

Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
4 Tessent® MissionMode User’s Manual, v2018.3
August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Table of Contents

Revision History

Chapter 1
Introduction to Tessent MissionMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
What Is Tessent MissionMode?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
In-System Test Controller Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Tessent MissionMode Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Memory Access Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 2
In-System Test Controller Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
CPU-Based Access Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Direct Memory Access Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Interface Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Timing Protocol Between IST Controllers and Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
In-System Test Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 3
In-System Test IP Insertion and Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Generating and Inserting the IST Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Timing Analysis for Designs with IST Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Generating Test Patterns for In-System Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Validating the In-System Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Guidelines for Programming the CPU for In-System Test . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Appendix A
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Mentor Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Third-Party Information
End-User License Agreement

Tessent® MissionMode User’s Manual, v2018.3 5

August 2018
 Table of Contents

6 Tessent® MissionMode User’s Manual, v2018.3

August 2018
 List of Figures

Figure 1-1. In-System Test Controller Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 1-2. In-System Test Implementation Using Direct Memory Access . . . . . . . . . . . . . 13
Figure 1-3. In-System Test Implementation Using CPU-Based Access . . . . . . . . . . . . . . . . 14
Figure 1-4. Advanced Implementation for In-System Test . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 1-5. Tessent MissionMode Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 2-1. IST Controller with CPU-Based Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 2-2. IST Controller With TAP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 2-3. CPU-Based Access Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-4. Direct Memory Access Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 3-1. Verilog Testbench Representation of IR-Scan Vector . . . . . . . . . . . . . . . . . . . . 40
Figure 3-2. Composition of Data In and Data Out Words. . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Tessent® MissionMode User’s Manual, v2018.3 7

August 2018
 List of Figures

8 Tessent® MissionMode User’s Manual, v2018.3

August 2018
 List of Tables

Table 2-1. Direct Memory Instructions for the In-System Test Controller . . . . . . . . . . . . . 22
Table 2-2. Ports for CPU-Based Access Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Table 2-3. Ports for IST Controller With Direct Memory Access . . . . . . . . . . . . . . . . . . . . 23
Table 2-4. Ports for TAP Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Table 2-5. Ports for IJTAG Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Table 3-1. Opcode Instructions for TAP Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Table 3-2. Opcode Instructions for IJTAG Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Table 3-3. Instructions for Programming the CPU When Using TAP Interface . . . . . . . . . 43
Table 3-4. Instructions for Programming the CPU When Using
IJTAG Scan Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Tessent® MissionMode User’s Manual, v2018.3 9

August 2018
 List of Tables

10 Tessent® MissionMode User’s Manual, v2018.3

August 2018
 Chapter 1
Introduction to Tessent MissionMode

Within the Tessent Shell environment, you can use Tessent MissionMode to generate a
controller that allows you to control and run BIST tests—for example, LogicBIST and
MemoryBIST—within in-system test (IST) environments in addition to manufacturing test
environments. Applications include automotive and other industries in which safety
considerations are critical.
This manual describes the Tessent MissionMode functionality—flows, IST controller
architecture and timing, and procedures for inserting the IST controller and generating patterns.
In addition, you will learn the difference between the CPU-based access architecture and the
direct memory access architecture.

Note
In this manual, the terms “MissionMode controller” and “IST controller” are used
interchangeably.

What Is Tessent MissionMode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

In-System Test Controller Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Tessent MissionMode Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Memory Access Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

What Is Tessent MissionMode?

In-field circuit testing relies on built-in self-test (BIST) mechanisms, especially for safety-
critical applications such as automotive, aerospace, and medicine. Tessent MissionMode targets
IC reliability once the IC is packaged and deployed by providing advanced BIST and
monitoring capabilities. These capabilities come in the form of a Tessent MissionMode
controller (IST controller) that allows you to access the device’s chip for testing purposes while
the device is running. This type of testing is called “in-system test.”
For in-system test, you generally use BIST at power-on-power-off of a design and periodically
to check the circuitry for random or aging-related defects. In general, power-on-power-off
testing—known as power-on self-test, or POST—runs independently. For POST, Tessent
MissionMode provides the direct memory access (DMA) architecture as an optimal method.

You typically run periodic testing in an interactive manner depending on the design under test
operation mode and available time for test. These tests are most often run and controlled by a
dedicated test controller that requires a type test control to test the logic bridge. For periodic
testing, Tessent MissionMode provides the CPU-based architecture as an optimal method.

Tessent® MissionMode User’s Manual, v2018.3 11

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction to Tessent MissionMode
In-System Test Controller Implementation

Hence, given a design, in-system test can vary depending on the mode of operation, which
mandates different sets of self-tests. Tessent MissionMode provides the capabilities and
automation to design any IJTAG-compliant self-test to be run in power-on or periodic testing
modes.

The IST controller performs in-system testing using the existing IJTAG network. You can
configure the IST controller to drive either a TAP scan interface or an IJTAG scan interface.

Tessent MissionMode is part of the Mentor Safe tool suite that enables ISO 26262-compliant
designs for advanced driver-assistance systems (ADAS) and autonomous driving capabilities
for passenger cars.

In-System Test Controller Implementation

Tessent MissionMode inserts the IST controller between the device’s test/monitoring controller
and the IJTAG-based BIST components that perform testing, which can include Tessent
MemoryBIST and hybrid TK/LBIST instruments. In addition, the tool inserts the interface that
transmits data between the device’s controller and the IST controller.
You can insert a CPU-based access interface or a direct memory access (DMA) interface as
described in “Memory Access Interfaces.”

The following figure shows that the Tessent MissionMode-inserted hardware is positioned so
that it can control testing through the Tessent BIST or other IJTAG-compliant instrument when
you enter in-system test mode. The IST controller and the IJTAG-based instruments exchange
data through a TAP or IJTAG host scan interface.

Figure 1-1. In-System Test Controller Placement

12 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction to Tessent MissionMode
In-System Test Controller Implementation

The following series of figures illustrate three common implementation scenarios for Tessent
MissionMode.

The following figure shows an implementation for POST in which you use the direct memory
access interface to perform pass-fail testing.

Figure 1-2. In-System Test Implementation Using Direct Memory Access

The following figure shows an implementation with CPU-based access, in which the built-in
test controller firmware accesses the BIST logic to perform testing based on your requirements.
For example, performing tests during the device’s idle times. You program the CPU as
described in “Guidelines for Programming the CPU for In-System Test.”

Tessent® MissionMode User’s Manual, v2018.3 13

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction to Tessent MissionMode
In-System Test Controller Implementation

Figure 1-3. In-System Test Implementation Using CPU-Based Access

The following figure shows an advanced implementation in which you use both direct memory
access and CPU-based access. In this scenario, you can perform POST on the test controller to
ensure that it is functioning correctly before using the CPU to perform in-system test on the
device.

14 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction to Tessent MissionMode
Tessent MissionMode Flow

Figure 1-4. Advanced Implementation for In-System Test

Tessent MissionMode Flow

The IST controller insertion and pattern generation process integrates within the existing
Tessent Shell two-pass RTL and scan DFT insertion flow.
Tip
If you are using the Tessent MissionMode to control only MemoryBIST instruments, insert
the IST controller during the first DFT insertion pass. For other IST configurations that
include LogicBIST, you can insert the IST controller either during the first or second DFT
insertion pass. For an overview of the Tessent Shell two-pass DFT insertion flow, refer to
“Overview of the RTL and Scan DFT Insertion Flow” in the Tessent Shell User’s Manual.

The following figure shows how IST controller generation fits within a typical Tessent Shell
two-pass flow. Typically, you insert the IST controller during the first DFT insertion pass along
with the MemoryBIST instrument.

Tessent® MissionMode User’s Manual, v2018.3 15

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction to Tessent MissionMode
Tessent MissionMode Flow

Figure 1-5. Tessent MissionMode Flow

Consider the following:

• Generate and insert the IST controller: Use the DftSpecification/InSystemTest

wrapper to generate and insert the IST controller.
Define the memory access protocol to the test pattern data by specifying either
CpuInterface or DirectMemoryAccess as the protocol (within the DftSpecification/
InSystemTest/Controller wrapper).
IST controllers exist independently of the networks they drive because they are
connected to the inputs of the TAP scan interface (5 pins) or IJTAG scan interface (8
pins) that connects to the rest of the IJTAG network. That is, you can modify the
network connected to the output side of the TAP or IJTAG scan interface, as needed,
without affecting the IST controller.
For details, refer to “Generating and Inserting the IST Controller.”
• Generate patterns: To generate IST patterns for verification, use the
PatternsSpecification/InSystemTest wrapper. This wrapper specifies how Tessent Shell
will use the BIST controller (whether MemoryBIST or LogicBIST, or both) to perform
in-system testing. The wrapper specifies the particular BIST patterns you want to
convert for in-system testing.
For details, refer to “Generating Test Patterns for In-System Test.”

16 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Introduction to Tessent MissionMode
Tessent MissionMode Flow

• Verify IST controller at the RTL level: You can perform pattern generation and
verification of the IST controller at the RTL level provided you have completed
MemoryBIST controller generation and insertion as well. Synthesis is not required for
the test controllers or the design. The tool can generate MemoryBIST patterns either for
manufacturing or for in-system test through the IST controller interface. You can then
validate these patterns using logic simulation.
If you want to run LogicBIST for in-system test, you cannot validate the LogicBIST
patterns even if the Hybrid TK/LBIST controller is generated and inserted at the RTL
level. You can generate LogicBIST patterns only after the fault simulation step, which
requires a gate-level netlist with scan chains and x-bounding logic inserted.
For details, refer to “Validating the In-System Test Patterns.”
• Verify IST controller at the gate level: For gate-level designs, generate and verify the
in-system test patterns for all BIST instruments that are in your design. After first and
second pass DFT insertion and synthesis, all the test IPs are in place and connected to
the IJTAG network. Scan chain insertion and other DFT tasks necessary to make a
design BIST-ready (such as x-bounding and test point insertion) are also performed at
the gate-level. At this point, you can generate and validate the IST patterns for both
MemoryBIST and LogicBIST.
For LogicBIST pattern verification, refer to the Hybrid TK/LBIST Flow User's Manual
for details.
For details, refer to “Validating the In-System Test Patterns.”

Prerequisites
The prerequisites for using Tessent MissionMode are:

• You have IJTAG patterns for BIST (LogicBIST, MemoryBIST, or any IJTAG
instrument). Regular scan patterns cannot be applied by the IST controller. The patterns
should only use IR-scan and DR-scan to deliver the scan data, not top-level DataPorts.
In-system tests are generated using the IJTAG test pattern specification that you use for
regular BIST testing.
• Any clocks or pin constraints required outside of the IJTAG network pins should be
provided by the system.
• Some functional logic exists to start and interrupt the in-system test as needed. When
using only POST mode, you can use the global power-on-reset signal to start the in-
system test.
• For the CPU-based access version of the IST controller, a CPU or other internal logic
that can interface with the controller’s parallel data bus is required. Refer to “CPU-
Based Access Architecture” for details.

Tessent® MissionMode User’s Manual, v2018.3 17

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction to Tessent MissionMode
Memory Access Interfaces

When using the direct memory access version of the IST controller, a synchronous
clocked memory is required to store the test program data. You can share the clocked
memory with functional memory when you use a different address space, or you can use
a dedicated memory. Refer to “Direct Memory Access Architecture.”
• Perform any prerequisite actions required for running BIST prior to providing the trigger
to run the in-system test. For example, prior to running MemoryBIST tests, you must
ensure that the step for repairing memories with built-in self-repair capability has been
executed.

Memory Access Interfaces

You can generate IST controllers that access memory directly or that interface with a CPU.
Neither of these architectures requires a dedicated memory for storing the test data. Instead,
they can use a sub-space of a functional memory’s address space.
CPU-based access is suitable for designs that have a CPU with access to the memory storing the
test data. The CPU is responsible for reading test data from the memory and providing it to the
IST controller. The CPU itself cannot be tested while it is interacting with the controller. The
CPU can start the in-system test at any time after the CPU is online.

Using CPU-based access requires you to write a CPU program that will access the memory and
provide write data to the IST controller. For more information, refer to “Guidelines for
Programming the CPU for In-System Test.”

Direct memory access interfaces with the memory to read the test data and execute the test.
With this architecture, both power-on and periodic tests are possible, and you can test the entire
design, including CPU cores.

For both access interfaces, pattern generation returns a Verilog testbench and a memory file.

Refer to “In-System Test Controller Architecture” for more information.

18 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 2
In-System Test Controller Architecture

You can generate IST controllers that access memory directly or that interface with a generic
CPU bus. Neither of these architectures requires a dedicated memory for storing the test data.
Instead, they can use a sub-space of a functional memory’s address space.
CPU-Based Access Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Direct Memory Access Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Interface Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Timing Protocol Between IST Controllers and Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
In-System Test Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

CPU-Based Access Architecture

For this architecture, the tool generates an IST controller with CPU-based access as defined by
the DFT specification. The CPU accesses the pattern data from memory as part of the firmware
or similar data source, provides the data to the IST controller, and observes the test results. The
IST controller receives the pattern data as a parallel data-in bus and provides the read data from
the IJTAG network as a parallel data-out bus. You can configure the bus size to match the
native width of the CPU data bus.
Note
Before you can use CPU-based access for in-system testing, you must program your CPU.
Refer to “Guidelines for Programming the CPU for In-System Test” for details.

The tool automatically configures the correct scan interface (TAP or IJTAG) from the specified
host interface or the DesignInstance parameters in the DFT specification.

The following figure shows the architecture after you have inserted an IST controller with CPU-
based access. The figure shows a TAP controller as the scan interface. Refer to “Interface Pins”
for details.

Tessent® MissionMode User’s Manual, v2018.3 19

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test Controller Architecture
Direct Memory Access Architecture

Figure 2-1. IST Controller with CPU-Based Access

Direct Memory Access Architecture

In this architecture, the IST controller synchronously accesses data from the memory, interprets
the data and interfaces with the IJTAG network through a TAP or IJTAG scan interface.
Tessent Shell generates the controller based on the DFT specification. In addition, during
IJTAG pattern creation, the tool writes out the final memory data contents, which includes both
the controller instructions and the pattern data, along with a Verilog testbench.

You can implement multiple InSystemTest controllers to test specific groups of instruments that
are intercepted at the TAP or IJTAG scan interface. When implementing multiple controllers
using the same memory source, ensure that either only one controller accesses the memory at a
time (that is, different controllers are used for test at different times) or you are using multi-port
memory so multiple controllers can access the memory simultaneously.

The following figure shows a design after you have inserted an IST controller with a TAP
interface. Refer to “Interface Pins” for details.

20 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test Controller Architecture
Direct Memory Access Architecture

Figure 2-2. IST Controller With TAP Interface

You can also connect the InSystemTest controller directly to an IJTAG scan interface. In this
case, the controller interfaces with the 8-pin IJTAG interface with clock, reset, select, shift/
capture/update, scan in and scan out signals.

Memory
The memory block is external to the In-System Test controller. You can use any memory that is
currently in your design. When you are sharing memory between functional and test tasks,
multiplex the controller’s memory address output with the functional memory address to ensure
the controller can access the data during test. When the memory is dedicated for test, simply
connect the controller’s memory address output to the memory address inputs. A typical
implementation for this memory is a ROM, but you can use any storage mechanism as long as
you can configure it to behave like a clocked synchronous memory.

Tessent® MissionMode User’s Manual, v2018.3 21

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test Controller Architecture
Interface Pins

The memory contents are a combination of In-System Test controller instructions and IJTAG
pattern data. Instructions may have an associated “count” parameter. The controller has the
following classes of instructions:
Table 2-1. Direct Memory Instructions for the In-System Test Controller
Instruction Description
DR-SCAN Perform a DR-scan operation. There are five variations: DR-scan with
write data and no compare, DR-scan with write data and binary compare,
DR-scan with write data and compare with Xs, DR-scan with all-0 write
data and binary compare, and DR-scan with all-0 write data and compare
with Xs.
IR-SCAN Perform an IR-scan operation. There are three different variations based
on expect data comparison and whether expect data is strictly binary or
contains unknowns (Xs). The count parameter indicates the number of
data words in the IR-scan.
WAIT Wait for a specific time period. The count parameter indicates the
number of clock cycles the controller should wait while the target test
completes.
RESET The IJTAG pattern has an iReset. This instruction resets the TAP
controller synchronously or the ITAG scan interface asynchronously.
HALT End the current test program. There is no associated parameter.

Interface Pins
Each IST controller interacts with two sets of interface pins. One set connects the IST controller
to the CPU or memory, depending on the access mechanism you have chosen. The second set
connects the IST controller to the IJTAG network through either an IJTAG or TAP scan
interface.
Refer to “In-System Test Controller Implementation” to view a high-level diagram.

Interface Pins for IST Controller with CPU-Based Access

The IST controller with CPU-based access contains the following ports. Refer to “Timing
Protocol Between IST Controllers and Hosts” for timing details.
Table 2-2. Ports for CPU-Based Access Controller
Port Type Description
clock Clock input for the controller. The CPU’s native clock is not required to be
synchronous with this clock. This clock drives the connected IJTAG network in
In-System Test mode.
reset Asynchronous reset input to reset the IST controller.

22 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test Controller Architecture
Interface Pins

Table 2-2. Ports for CPU-Based Access Controller (cont.)

Port Type Description
enable Input signal to enable In-System Test mode. This signal should be asserted and
stay asserted during the entire in-system test. De-asserting this signal at any
time disables the controller from being transparent to the IJTAG network. See
“In-System Test Execution” for details.
data_in Parallel input bus that contains IST controller instruction opcode and data to
write to the IJTAG network through the TAP or IJTAG scan interface. The two
most significant bits represent the opcode for the controller, and the remaining
bits are the write data that will be shifted into the network.
data_out Parallel output bus that contains the status of the IST controller read operation
and the data read from the IJTAG network. The two most significant bits
represent a status code as (1’b0, ReadDone), and the remaining bits are the read
data shifted out from the network.
write_en Input signal to indicate valid data is present in the data-in bus. To be asserted by
the CPU after writing to data in.
test_active Output signal to indicate the IST controller is active.

Interface Pins for IST Controller with Direct Memory Access

The IST controller with direct memory access contains the following ports. Refer to “Timing
Protocol Between IST Controllers and Hosts” for timing details.
Table 2-3. Ports for IST Controller With Direct Memory Access
Port Description
clock Clock input. For In-System Test mode, configure the external memory to
also be clocked by this clock. The IST controller accesses the memory
synchronously on the rising edge of this clock. During in-system test, this
clock drives the connected IJTAG network.
reset Asynchronous input to reset the IST controller logic. Typically, this
signal is connected to power-on-reset signal.
enable Input signal to enable In-System Test mode. This signal should be
asserted and stay asserted during the entire in-system test. To cut short
the current in-system test and return to mission mode of operation, you
can de-assert this signal at any time. See “In-System Test Execution” for
details.

Tessent® MissionMode User’s Manual, v2018.3 23

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test Controller Architecture
Interface Pins

Table 2-3. Ports for IST Controller With Direct Memory Access (cont.)
Port Description
prog_index Multibit input that chooses the test program to run. This input is sampled
when the controller is enabled and does not have to stay stable
throughout the test. The size of this input is log-2 of the total number of
tests. This value is used as the index to a Test Program Address Table
that lists the addresses stored in memory.
When an invalid program index is specified, the tool asserts fail_flag and
test_done to indicate an error. An invalid program index is defined as any
index after the last specified TestProgram index up to the maximum
number of test programs.
For example: During IP generation, suppose you define a maximum of 8
test programs with the DirectMemoryAccessOptions/
max_test_program_count property. If you specify 7 TestProgram()
wrappers for pattern generation, indices 0 thru 6 are valid and 7 is
invalid.
test_active Output signal that indicates that the In-System Test controller is running.
You can use this signal to provide exclusive access to the memory from
the controller during test execution.
test_done Output signal that indicates the current test has completed. This signal is
set when the finite state machine (FSM) reaches the Halt state and
cleared when it goes to Idle state.
fail_flag Output signal that indicates mismatches between the read data and the
expect data by setting this signal high. This signal is cleared when the
FSM goes to the Idle state. When multiple tests are run, the functional
logic should collect the combined result of the individual tests.
mem_address Output bus that provides the address for the next memory read. Same size
as the memory address bus. When you are sharing memory with
functional logic, ensure that the controller has exclusive access to the
memory address bus during test.
mem_data Input bus that provides the data corresponding to the current address.
Same size as the memory data bus.

Note
For direct memory access controllers, the TAP scan interface to_tck port or the IJTAG scan
interface to_ijtag_tck port should effectively control the memory clock.

Interface Pins When Using TAP Scan Interface

When using a TAP controller as your scan interface, the IST controller uses the following ports
as the interface. In addition to the following pins, the top-level TAP signals (tck, trst, tms, tdi,
tdo) are brought into the controller for multiplexing with the controller-generated signals.

24 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test Controller Architecture
Timing Protocol Between IST Controllers and Hosts

Table 2-4. Ports for TAP Scan Interface

Port Name Description
to_tck Output signal from controller. When the IST controller is active, the clock input
of the controller drives this pin; otherwise, the tck input drives this pin.
to_trst Output signal from the IST controller, which is held inactive (1’b1) when the
controller is running; otherwise, it is driven by the top-level TRST port.
to_tms Output signal from the IST controller that is multiplexed with the top-level
TMS port at the input of the TAP controller.
to_tdi Output signal from the IST controller that is multiplexed with the top-level TDI
port at the source of TAP controller tdi input.
from_tdo Input signal to IST controller that comes from the internal tdo signal (before the
tristate buffer) of the TAP controller.

Interface Pins When Using IJTAG Scan Interface

When using the IJTAG network as your scan interface, the IST controller uses the following
ports as the interface. In addition to the following pins, the higher level IJTAG scan interface
signals (ijtag_tck, ijtag_reset, ijtag_sel, ijtag_ce, ijtag_se, ijtag_ue, ijtag_si, ijtag_so) are
brought into the controller for multiplexing with the controller generated signals.
Table 2-5. Ports for IJTAG Scan Interface
Port Name Description
to_ijtag_tck Clock for the IJTAG scan interface. This signal should effectively control the
ROM clock for CPU-based access controllers.
to_ijtag_reset Reset signal for the IJTAG scan interface.
to_ijtag_sel Select signal for the IJTAG scan interface.
to_ijtag_se Control signals for the IJTAG scan interface.
to_ijtag_ce
to_ijtag_ue
to_ijtag_si Input and output from the IJTAG scan interface.
from_ijtag_so

Timing Protocol Between IST Controllers and

Hosts
In the CPU-based access architecture, the CPU and the device run asynchronously. In the direct
memory access architecture, the memory and device run synchronously.

Tessent® MissionMode User’s Manual, v2018.3 25

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test Controller Architecture
Timing Protocol Between IST Controllers and Hosts

The following diagram shows the timing for IST controllers that interface with CPUs. With
clock running, the IST controller resets and runs in idle mode while waiting for the enable
signal to be asserted, which turns on the IST controller logic. The write enable operation begins
a few cycles later so that the IST controller clock and device’s test/monitoring controller clock
can synchronize.

The write enable signal indicates the beginning of data transfer from the device’s test/
monitoring controller to the IST controller through the CPU interface. When the internal test
done signal goes high, the IST controller communicates the test results through DataOut back to
the device controller. A value of “01” in the most significant bits indicates valid results data that
can be acted upon.

For details about the signals for the CPU-based architecture, refer to “CPU-Based Access
Architecture.”

Figure 2-3. CPU-Based Access Timing Diagram

The following diagram shows the timing for IST controllers that access memory directly. With
clock running, the IST controller resets and then you assert the enable signal. The controller
accesses the memory address for the test program you want to start with. The test active signal
goes high as soon as you assert the enable signal. When the test done signal goes high to
indicate the end of the test, you can read the fail flag signal for the results. When the fail flag is
high, the tool detected a failure. The signal remains high until you de-assert the enable signal.

The program index signal indicates the pattern set you are using for the test. This signal is
required when you have more than one test program pattern set. Specify the program index
within the DftSpecification/InSystemTest/Controllers/Interface/DirectMemoryAccess wrapper.
The index points to the first memory location for the pattern set. The IST controller reads from
memory until it reaches the last memory location for the pattern set.

26 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test Controller Architecture
In-System Test Execution

For details about the signals for the direct memory access architecture, refer to “Direct Memory
Access Architecture.”

Figure 2-4. Direct Memory Access Timing Diagram

In-System Test Execution

To execute an in-system test, assert (hold at 1) the IST controller’s input enable signal for the
duration of the test. This applies to both CPU-based and direct memory access architectures.
If you interrupt the test by de-asserting the enable signal, the test ends immediately and the state
of the IJTAG network is unknown. Therefore, ensure that you reset the IJTAG network or TAP
controller before starting the next test, unless the next test is an in-system test. Tessent
MissionMode automatically resets the network prior to performing in-system tests.

You can use the IST controller to run multiple tests with the same or different patterns during
system operation. For CPU-based access, the IST controller only performs parallel-serial
translation of the IJTAG network data, which means it does not know test boundaries. The CPU
can run multiple tests as long as the IST controller enable signal stays asserted. For CPU-based
access, the CPU is responsible for running multiple tests.

To run multiple tests when you are using direct memory access, de-assert the enable signal
when the current test is complete (test_done flag goes high), and then assert it again in later IST
controller clock cycles. The subsequent test starts only after the controller senses a 0-to-1
transition on the enable input. This prevents the test from running in a repeating loop when the
enable signal is high. When only POST is required, you can connect the reset signal to system
power-on-reset and the enable signal to constant-1.

Refer to “Timing Protocol Between IST Controllers and Hosts” for timing details.

Tessent® MissionMode User’s Manual, v2018.3 27

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test Controller Architecture
In-System Test Execution

IST Controller Transparency to the IJTAG Network

The IST controller architecture includes muxes located in front of the IJTAG network. One mux
input connects to the higher-level IJTAG network (e.g. from the TAP controller or pads). The
other mux input connects to the IST controller. When in-system test is running, the mux select
enables the IST controller path, making the IST controller the driver for the IJTAG network.
When the in-system test ends or is interrupted, the mux select reverts to not choosing the IST
controller path, meaning the controller becomes transparent to the IJTAG network and the
higher level IJTAG pins control the downstream IJTAG network. This means that when you
want to run manufacturing tests, you have to disable the IST controller so that it is transparent in
the IJTAG network.

28 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Chapter 3
In-System Test IP Insertion and Pattern
Generation

Tessent MissionMode uses the Tessent Shell data configuration syntax for IP insertion and
pattern generation. For IP insertion, use the DFT specification (DftSpecification) with the
InSystemTest wrapper. For pattern generation, use the patterns specification
(PatternsSpecification) with the InSystemTest wrapper.
Generating and Inserting the IST Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Timing Analysis for Designs with IST Controllers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Generating Test Patterns for In-System Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Validating the In-System Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Guidelines for Programming the CPU for In-System Test . . . . . . . . . . . . . . . . . . . . . . . 38

Generating and Inserting the IST Controller

You can insert the IST controller once the IJTAG interface at the location where you plan to
place the IST controller is finalized. Using multiple IST controllers allows you to reduce the
setup time through the IJTAG network, because each controller can be placed closer to the
instrument under test.
Note
After IST controller insertion and synthesis, ensure that you configure the controller to
remain inactive at all times except when performing in-system tests. Otherwise, the IJTAG
network downstream of the IST controller cannot be accessed, which could lead to incorrect
test_setup initialization or simulation mismatches.

Consider the following when planning for IST controller insertion:

• The IJTAG network interface that intercepts with an IST controller cannot be changed
after you insert the IST controller. You can continue to add instruments to the IJTAG
network but the IST controller will not be able to access them.
• Generally, insert the IST controller during the first DFT insertion pass along with the
MemoryBIST instruments, although, as required, you can insert the IST controller
during the second DFT along with the LogicBIST instruments.
For an overview of the Tessent Shell two-pass DFT insertion flow, refer to “Overview
of the RTL and Scan DFT Insertion Flow” in the Tessent Shell User’s Manual.

Tessent® MissionMode User’s Manual, v2018.3 29

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Generating and Inserting the IST Controller

• If you are inserting multiple IST controllers closer to their BIST instruments, insert the
IST controllers for the BIST instruments during their respective DFT insertion passes.
• When inserting multiple IST controllers at a host scan interface, the tool connects the
controllers in the same order as they are defined within the DftSpecification/
InSystemTest wrapper. For an example of an InSystemTest wrapper with multiple
controllers, refer to “InSystemTest” in the Tessent Shell Reference Manual.
Procedure
The following example shows a first DFT insertion pass, in which you are inserting the
MemoryBIST and IST instruments. The IJTAG network is automatically generated also. After
this pass, you would proceed with the second DFT insertion pass (EDT, LogicBIST, OCC) as
usual.

set_context dft -rtl -design_id rtl1

read_verilog design_rtl.v
read_cell_library tessent.celllib
set_design_source -format tcd_memory -y ../data -extension memlib
set_current_design design
set_design_level physical_block

add_black_boxes -m pll
add_dft_signals tck_occ_en memory_bypass_en

add_clocks clka -period 10ns

add_clocks clkb -period 13.2ns
add_clocks clkc -period 8ns
add_clocks 0 ramclk -period 10ns
set_dft_specification_requirements -memory_test on

check_design_rules

# Typically you use the create_dft_specification command and then edit

# the resulting DftSpecification to your requirements. In this case,
# the command would be: create_dft_specification

read_config_data -from_string {

DftSpecification(design,rtl) {
IjtagNetwork {
HostScanInterface(ijtag) {
Tap(t1) {
HostIjtag(i1) {
Sib(sri) {
...
}
Sib(sti) {
...
Sib(mbist) {
}
}

30 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Generating and Inserting the IST Controller

}
}
}
}
MemoryBist {
ijtag_host_node : Sib(mbist);
Controller(c1) {
clock_domain_label : ramclk;
Step {
MemoryInterface(m1) {
instance_name : regs/dram;
}
}
}
}

InSystemTest {
Controller(c0) {
protocol : cpu_interface;
host_interface : HostScanInterface(ijtag);
data_width : 8;
Connections {
reset : istb/reset;
CpuInterface {
clock : istb/clock;
enable : istb/enable;
write_en : istb/write_en;
data_in : istb/data_out;
data_out : istb/data_in;
}
}
}
}
}
process_dft_specification
extract_icl

Results
The following example shows the resulting ICL description for an IST controller that drives a
TAP scan interface. The MUX inside the controller that chooses between the client interface
and the controller is not modeled. During pattern generation, the IST patterns are retargeted to
the “host” interface of the IST controller.

Tessent® MissionMode User’s Manual, v2018.3 31

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Timing Analysis for Designs with IST Controllers

Module design_rtl_tessent_in_system_test_c0 {
TCKPort ijtag_tck;
TRSTPort trst;
TMSPort tms;
ScanInPort tdi;
ScanOutPort tdo {
Source from_tdo;
Attribute forced_low_output_port_list = "tdo_en";
}

ToTCKPort to_ijtag_tck;
ToTRSTPort to_trst {
Source trst;
}
ToTMSPort to_tms {
Source tms;
}
ScanInPort from_tdo;
ScanOutPort to_tdi {
Source tdi;
}

ScanInterface client {
Port ijtag_tck;
Port trst;
Port tms;
Port tdi;
Port tdo;
}
ScanInterface host {
Port to_ijtag_tck;
Port to_trst;
Port to_tms;
Port from_tdo;
Port to_tdi; }

Attribute tessent_instrument_type = "mentor::in_system_test";

Attribute tessent_instrument_container = "design_rtl_in_system_test.instrument";
Attribute tessent_signature = "3422381c831270128bd9b4e6a1c80506";
}

Timing Analysis for Designs with IST

Controllers
IST controllers do not contain false or multicycle paths. User logic interfacing with the CPU-
based controller is asynchronous to the controller.
For timing analysis, the following interactions exist between the IST controller and the design
into which it is inserted:

• IJTAG network. When running tests, the IJTAG network and the IST controller use the
same IST controller’s input clock. This clock is muxed with the existing IJTAG

32 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Generating Test Patterns for In-System Test

network’s tck through the to_ijtag_tck output pin on the controller so that the IJTAG
network is synchronous to the controller, so no exceptions are required.
The IJTAG network receives both the top-level tck (for manufacturing test access) and
the IST controller clock (for in-system test). When both of the clocks are defined, static
timing analysis times the paths starting from one and ending at the other, whereas in
reality the clocks are not active at the same time. You can avoid these clock interactions
during timing analysis in two ways:
o Perform modal analysis with the IST controller enable signal asserted for in-system
test and de-asserted for manufacturing test. The default name for this port is
cpu_interface_en or dma_en, depending on your architecture.
o Declare mutually exclusive clocks between the top-level tck and the controller
clock. For example, for the Synopsis Design Compiler synthesis tool, you could
specify:
set_clock_groups –logically_exclusive –group {tck} –group {ist_clock}

• CPU-based access. The logic for generating the data in (data leaving the CPU) and data
out (data entering the CPU) typically operates on the clock of the CPU internal bus. This
clock is asynchronous to the IST controller clock and is likely to be much faster. The
CPU interacts with the controller using an asynchronous handshake mechanism through
the use of the write enable input and status output of the controller. Hence, these paths
can be declared false. Note that the controller includes a synchronizer cell for reading
the write enable input.
For CPU-based access, you can define the CPU clock and the controller clock as
mutually exclusive, which means that no paths between them will be timed for static
timing analysis. For example, for the Synopsis Design Compiler synthesis tool, you
could specify:
set_clock_groups –logically_exclusive –group {cpu_clock} –group {ist_clock}.

• Direct memory access. You are responsible for using the to_tck output to control the
memory clock when in-system tests are running. In this case, the memory access
becomes synchronous to the IST controller operation, so no exceptions are required.

Generating Test Patterns for In-System Test

Generate the In-System Test patterns in pattern -ijtag context.
For more information, refer to “create_patterns_specification” and
“process_patterns_specification” in the Tessent Shell Reference Manual.

Tessent® MissionMode User’s Manual, v2018.3 33

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Generating Test Patterns for In-System Test

Note
For IST controllers connected to both LogicBIST and MemoryBIST, you can use a
validation-only patterns specification that contains only MemoryBIST instruments and
verify this in RTL. For LogicBIST instruments, you must validate at the gate-level. Refer to
“Tessent MissionMode Flow” for more information.

Prerequisites
• If you are executing LogicBIST patterns with the IST controller, prior to generating the
patterns, ensure that you have previously run fault simulation so that you have a patterns
database. Tessent Shell uses the patterns database as an input for pattern generation.
• (Optional) During fault simulation, you may want to verify compatibility with the
hardware default configuration by running the report_lbist_configuration
-hardware_default_compatibility command. Do this if, for in-system testing with
LogicBIST controllers, you want to reduce the number of cycles required to perform the
setup, which you can do if the pattern set is compatible with the hardware default
configuration values. During IST pattern generation, if the hardware default values need
to be loaded to all registers behind the same SIB, then these registers will be
synchronously reset to their hardware default values, thereby eliminating the need to
apply iWrites to them. Any BIST register value that is not compatible with
hardware_default mode must be explicitly initialized during in-system test.
Procedure
The following example shows pattern generation for a design that contains MemoryBIST and
LogicBIST. The example shows a sample PatternsSpecification that includes an IST controller
wrapper.

set_context pattern -ijtag -design_id gate

read_design design
read_cell_library tessent.celllib
set_current_design
add_clocks 0 clk -period 100ns
add_core_instance -module design_rtl_tessent_in_system_test_c0

34 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Generating Test Patterns for In-System Test

# Typically you use the create_patterns_specification command to generate

# the PatternsSpecification
read_config_data -from_string

PatternsSpecification(design,gate,signoff) {
AdvancedOptions {
ConstantPortSettings {
scan_en : 0;
}
}
Patterns(ICLNetwork) {
ICLNetworkVerify(design) {
}
}
Patterns(LogicBist_cpu) {
ClockPeriods {
clk : 100.00ns;
}
ProcedureStep(ltest_en) {
iCall(dft_signal_iproc) {
iProcArguments {
args:
processor_core_gate1_tessent_tdr_sri_ctrl_inst.tck_occ_en 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.control_test_point_en 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.observe_test_point_en 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.x_bounding_en 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.ltest_en 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.int_ltest_en 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.memory_bypass_en 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.int_mode 1
processor_core_gate1_tessent_tdr_sri_ctrl_inst.async_set_reset_static_disable 1;
}
}

TestStep(serial_load) {
LogicBist {
CoreInstance(.) {
run_mode : run_time_prog;
begin_pattern : 0;
end_pattern : 999;
}
}
}
}

Patterns(MemoryBist_P1) {
tester_period : 400.0;
ClockPeriods {
ramclk : 100.0ns;
}
TestStep(run_time_prog) {
MemoryBist {
...
}
}

Tessent® MissionMode User’s Manual, v2018.3 35

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Validating the In-System Test Patterns

InSystemTest {
Controller(design_rtl_tessent_in_system_test_c0_inst) {
TestProgram(0) {
pattern : LogicBist_cpu;
}
TestProgram(1) {
pattern : MemoryBist_P1;
}
}
}
}

process_patterns_specification

Results
In the TCD flow, the tool adds the IST controller as a core instance when you specify the
add_core_instance command. The TCD associated with the instrument provides controller
information required for pattern generation. The command also provides the instance path name
for the controller.
After pattern generation, the tool reports the memory required for In-System Test so that you
can ensure that you have enough resources.
• For the DMA controller, the tool stores the test program in ROM. The report shows the
amount of ROM required for storing the test program and also the actual time to run the
test programs.
• For the CPU-based controller, you can implement your own program logic and data. If
you follow the default implementation provided in the verification testbench, the report
shows the memory and runtime requirements for such an implementation. For example:
// -----------------------
// InSystemTest Statistics
// -----------------------
// Controller design_rtl_tessent_in_system_test_c0_inst (*)
// Total memory for 2 programs: 1005 8-bit words
// TestProgram(0): pattern=LogicBist_cpu, memory=432 words, runtime=0.18ms (1818 tck
cycles)
// TestProgram(1): pattern=MemoryBist_P1, memory=573 words, runtime=0.21ms (2051 tck
cycles)
// (*) Reported statistics assume CPU program and execution is similar to verification
testbench.

Validating the In-System Test Patterns

You can validate the in-system test patterns by running testbench simulations after you perform
IST pattern generation.

36 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Validating the In-System Test Patterns

Note
For IST controllers connected to both LogicBIST and MemoryBIST, you can use a
validation-only patterns specification that contains only MemoryBIST instruments and
verify this in RTL. For LogicBIST instruments, you must validate at the gate-level. Refer to
“Tessent MissionMode Flow” for more information.

Prerequisites
• This procedure assumes that you have generated the test patterns for the BIST
instruments that the IST controller will be controlling during in-system test.
Procedure
1. Set the simulation library sources. For example:
set_simulation_library_sources -v ../verilog/adk.v -v ../data/dram.v

2. Run the testbench simulation. For example:

run_testbench_simulation -select LogicBist_cpu -simulator_options -wait

3. Check the testbench simulations. For example:

check_testbench_simulations -report_status

Results
The resulting Verilog testbench file is named
“FilePrefix_TestProgramIndex_PatternSetName.v”, and the memory file (for use with the
direct memory access IST controller) is named “testbench_file_name.mem”. If you have
multiple controllers, the name is
FilePrefix_C<ControllerIndex>_TestProgramIndex_PatternSetName.v.mem.
For manufacturing patterns, if you are using CPU-based access, you must program the CPU
before you can run in-system testing as described in “Guidelines for Programming the CPU for
In-System Test.” The CPU does not need to be programmed if you are performing validation
through simulation.
If you are using direct memory access, there are no further setup requirements.
Examples
The following example shows a snippet of a testbench for CPU-based access with an eight-bit
data bus.

Tessent® MissionMode User’s Manual, v2018.3 37

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

initial
# Constant ports
begin: pin_constraints
end

# Reading from memory and writing into the IJTAG network

# You can replace this task with your data read and data write implementation
task process_one_cpu_interface_word;
endtask

# Emulating the CPU to exercise the In-System Test controller

task ist_emulate_cpu;
begin
$readmemb(_mem_file, mem);

while (!halt) begin

cpu_instruction = mem[pc][1:0];
pc = pc+1;
if (cpu_instruction === 2'b00) begin
count = mem[pc];
pc = pc+1;
while (count> 0) begin
write_data = mem[pc];
pc = pc+1;
expect_valid = mem[pc];
pc = pc+1;
expect_data = mem[pc];
pc = pc+1;
count = count-1;

process_one_cpu_interface_word(write_data[7:6], write_data[5:0],
expect_valid[5:0], expect_data[5:0]);
end
end else if (cpu_instruction === 2'b01) begin
count = mem[pc];
pc = pc+1;
while (count > 0) begin
count = count-1;
@(posedge DUT_inst.cpu_gate_tessent_in_system_test_istc_inst.clk);
end
end else if (cpu_instruction === 2'b10) begin
halt = 1;
$display($time,, "halt");
end
endtask

Guidelines for Programming the CPU for In-

System Test
Before you can use an IST controller configured for CPU-based access, you must program your
CPU.

38 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

CPU Tasks
Program the CPU so that it performs the following tasks:

• Read data from the memory and provide the data to the IST controller for test setup.
There may be multiple scan operations as part of test setup. Split the reading and writing
of data to the controller over multiple interactions with the controller, depending on the
number of scan operations and CPU bus width.
To complete one scan-IR and one scan-DR operation, the CPU interacts with the IST
controller asynchronously using the following protocol. The scan data is padded and
split into multiple words that match the controller data width.
o CPU places a word consisting of CPU interface 2-bit operation code (opcode)
instruction and N-2 bits of write data.
o CPU asserts the write enable signal.
o CPU waits for the “Data Valid” status bit to be asserted on the data out port. The
CPU can then consume the N-2 bits read data for comparison against the expect
data.
o Repeat the above steps for other words that represent the complete scan operation.
• Wait for the duration of the test.
• Read the data from the IST controller and compare it to the expect data. Split the reading
of data from the controller into multiple interactions, depending on the number of scan
operations.
• Generate test done and fail flag outputs to indicate test completion and whether any
mismatches occurred.
The data the CPU requires to run the IST controller is located within the PatternsSpecification
instrument dictionary. When you specify the process_patterns_specification command, Tessent
Shell generates an instrument dictionary named
“mentor::in_system_test::PatternsSpecification”. In addition, the tool creates a Verilog
testbench for verification of the In-System Test operation. The testbench uses Verilog tasks to
mimic CPU operation. All control signals are asserted at the internal pins on the controller
boundary. (The testbench directly forces and observes the internal design pins and cannot be
used as a tester program.)

The following figure shows how the Verilog testbench represents an IR-scan vector. The figure
shows that the testbench data includes opcode instructions and padding. Assume that the data
width is 12 and that the source data for the IJTAG scan vector at the host scan interface is:

scan_type=IR, length=2, write_data=01, expect_data=01

Tessent® MissionMode User’s Manual, v2018.3 39

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

Figure 3-1. Verilog Testbench Representation of IR-Scan Vector

Methods for Programming the CPU

To program the CPU, you can:

• Convert based on the Verilog testbench. When converting from the testbench, the data
that needs to be stored in memory for access by the CPU is the same data that the
testbench uses. You only need to write the program control logic that uses this data.
• Use the raw pattern data from the PatternsSpecification instrument dictionary. You can
introspect the instrument dictionary to extract the raw data. Using the raw data allows
you to write your own CPU program to optimize the structure of the data and control
code to match your CPU’s capability.
When writing your own CPU program, you determine the format of the data stored in
the memory that is accessed by the CPU and write program control logic that expands
this data before using it at the controller data pins.

Verilog Testbench Conversion

The following details about the Verilog testbench are useful for converting the testbench. They
are also useful when writing your own CPU program.

• The memory contents used by the testbench are located in a file with the same name as
the testbench file with the addition of a “.mem” suffix. The memory contents hold both
the control instructions for the testbench and the data necessary for interaction with the
IST controller. The testbench loads this memory file during simulation.
• The testbench uses three types of control instructions: data, wait and halt. The wait
instruction indicates the duration of the test when the controller is idle. The halt
instruction terminates the testbench.
• For data, the testbench uses the following five types of data scan instructions based on
the compare type for the expect data and the all-0 state (0000) for the write data. The

40 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

expect valid word is used to differentiate X and binary values, while the expect data
word contains the binary expected values.
o No compare: only write data stored in testbench memory. For example, write=1010,
expect=XXXX.
o Binary compare: write data + expect data. The expect valid word is implicitly
assumed to be true. For example, write=1010, expect=0100.
o Binary compare with all-0 write: expect data only. The write data is all-0 and
therefore represented by an instruction type rather than values. The expect valid
word is implicitly assumed to be true. For example, write=0000, expect=0100.
o Compare with X values: write data + expect data + expect valid. This the most
generic instruction in which there are some Xs in the expect data, but not all Xs. For
example, write=0100, expect=01X1.
o Compare with X values with all-0 write: expect data + expect valid. The write data is
all-0 and therefore represented by an instruction type rather than values. There are
some Xs in the expect data, but not all Xs. For example, write=0000, expect=01X1.
• The write word uses its two most significant bits to identify the opcode for the IST
controller. The controller only uses the opcode from the write word. The opcode bits
within the expect valid and expect data words function as unused padding used for
alignment with the memory width.
• When possible, the tool merges all consequently occurring scans of compare-with-X-
values instructions into a single data instruction and all consequently occurring scans of
no-compare instructions into a single data instruction. When the number of words
cannot be represented as a single word in the memory content size, the word is split into
multiple data instructions. Scans with all-0 write data are not merged.
• The wait duration is represented by a 32-bit integer. The number of memory words
depends on the data width. For example, the wait for an 8-bit memory word is
represented using four memory words.

Tessent® MissionMode User’s Manual, v2018.3 41

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

Raw Pattern Data for Writing Your Own CPU Program

You can decide on the format in which the memory contents are stored in memory. The CPU
then processes this memory content, writes to data in, and reads from the data out pins of the
controller. For TAP interfaces, the format shown in the following figure:

Figure 3-2. Composition of Data In and Data Out Words

For the TAP scan interface, the data in and data out words include the opcode/status bits and
scan-in/scan-out data. The following table lists the four opcode instructions and their
corresponding functions.
Table 3-1. Opcode Instructions for TAP Scan Interface
Opcode Description
ToPauseIR Initiates or continues a multi-word IR scan. The TAP controller
starts from either RunTestIdle or PauseIR, and ends in PauseIR
after shifting one word of scan data through the IJTAG network.
ToPauseDR Initiates or continues a multi-word DR scan. The TAP controller
starts from either RunTestIdle or PauseDR, and ends in PauseDR
after shifting one word of scan data through the IJTAG network.
ToRunTestIdle Finishes a multi-word DR or IR scan. The TAP controller starts
from either PauseDR or PauseIR, and ends in RunTestIdle state
after shifting one word of scan data through the IJTAG network.
You can also use this instruction to perform a single word DR scan,
in which case the TAP controller starts from RunTestIdle state,
shifts one word of scan data through the IJTAG network, and ends
back in RunTestIdle state.
ToTestLogicReset Resets the TAP controller synchronously and returns it to run-test-
idle state.

For the IJTAG scan interface, the data in and data out words include the opcode/status bits and
scan in/out data. The following table lists the three opcode instructions and their corresponding
functions. For the IJTAG scan interface, the ToPauseIR opcode is not valid because the patterns
delivered through this interface only have DR scans.

42 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

Table 3-2. Opcode Instructions for IJTAG Scan Interface

Opcode Description
ToPauseDR Initiates or continues a multi-word DR scan. When initiating a
scan, the IJTAG network goes through capture and shift. When
continuing a scan, the IJTAG network goes only through shift.
ToRunTestIdle Finishes a multi-word DR scan. Here the IJTAG network goes
through shift and update. You can also use this instruction to
perform a single word DR scan, in which case the IJTAG network
goes through capture, shift and update states.
ToTestLogicReset Performs an asynchronous reset of the IJTAG network using the
IJTAG reset signal.

For both interface types, a data width of N bits corresponds to N-2 scan-in/scan-out values plus
two opcode/status bits. The IST controller uses parallel data words, which means the IJTAG
pattern data must be split into multiple words of size N-2. This can require padding when the
pattern data is not an exact multiple of “N-2”.

For example, suppose you have a data width of 8 and 30 data bits. Then, N-2 equals 6 and 30/6
equals 5 words with no padding necessary. However, if you have 25 data bits of data, then 25/6
equals 5 words with 5 bits of padding.

When translating scan-IR data, the minimum word width required is two words. Returning to
Figure 3-1, the 2-bit raw data is padded to 20 bits. With the addition of 4 bits of opcode, you
have 24 bits, or two words of 12 bits each. When translating scan-DR data, the minimum word
width is only one word. In a similar example, two bits would be converted to 10-bits padded
plus 2 bits opcode for one word equal to 12 bits.

For write data, append the padding after the least significant bits, and for expect data append the
padding before the most significant bits. For example, suppose you have a “y...z” bit pattern and
are adding three bits of padding each for write data and expect data. This can be represented as:
RRRy...zWWW.

The four opcode instructions that you use when driving a TAP scan interface for CPU
interaction with the IST controller depend on the current state of the controller as described in
the table below. The table cells indicate whether an opcode instruction is allowed and the next
TAP state (shown in parenthesis) after the instruction is executed.
Table 3-3. Instructions for Programming the CPU When Using TAP Interface
Controller TAP State ToTest ToRun ToPauseDR ToPauseIR
State LogicReset TestIdle
IDLE (after Any Yes Yes Yes Yes
controller is (IDLE) Full DR scan Start DR scan Start IR scan
reset) (IDLE) (PauseDR) (PauseIR)

Tessent® MissionMode User’s Manual, v2018.3 43

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

Table 3-3. Instructions for Programming the CPU When Using TAP Interface
Controller TAP State ToTest ToRun ToPauseDR ToPauseIR
State LogicReset TestIdle
Pause PauseDR No1 Yes Yes No2
Finish DR scan Cont. DR scan
(IDLE) (PauseDR)
Pause PauseIR No3 Yes No4 Yes
Finish IR scan Cont. IR scan
(IDLE) (PauseIR)
1. ToTestLogicReset instruction used when controller state is Pause is equivalent to ToRunTestIdle.
2. ToPauseIR instruction used when TAP state is PauseDR is equivalent to ToPauseDR.
3. ToTestLogicReset instruction used when controller state is Pause is equivalent to ToRunTestIdle.
4. ToPauseDR instruction used when TAP state is PauseIR is equivalent to ToPauseIR.

Similarly, when driving the IJTAG scan interface, the instructions for programming the CPU
are as follows:
Table 3-4. Instructions for Programming the CPU When Using
IJTAG Scan Interface
Controller ToTest ToRun ToPauseDR
State LogicReset TestIdle
IDLE (after controller Yes Yes Yes
is reset) Full DR scan Start DR scan
Pause No1 Yes Yes
Finish DR scan Cont. DR scan
1. ToTestLogicReset instruction used when controller state is Pause is equivalent to ToRunTestIdle.
ToPauseIR instruction used when controller state is Pause is equivalent to ToRunTestIdle.

Data and Control Code Optimizations

When writing your own CPU program, you can optimize the program to match your CPU
capability. Some possible optimizations are:

• To reduce memory usage, you can store the raw scan data before padding. The CPU
program can perform padding, splitting to match the controller data width, and adding
opcodes to each of the data word.
• The padding required to make the write and read data a multiple of the IST controller
data size introduces runtime and memory overhead. Using smaller widths reduces the
padding runtime overhead, but it increases the padding memory overhead. The 2-bit
opcode on a 8-bit memory word results in 25% overhead on each word. To balance these
conflicting requirements, you can use a longer data width in the memory but use a
smaller data width at the controller interface.

44 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

Example of Introspecting the Raw Pattern Data

The following example shows a patterns specification and its resulting instrument dictionary.
The dictionary contains information about the tester period, tck period, clocks, pin constraints
and binary write/expect DR-scan and IR-scan data as applicable to the test program. Note how
the Patterns wrapper name, ProcedureStep wrapper name, clocks, and pin constraints correlate
to the keys in the dictionary.

SETUP> report_config_data
PatternsSpecification(M, gt, ist) {
Patterns(P1) {
ClockPeriods {
REFCLK: 25;
}
AdvancedOptions {
ConstantPortSettings {
post_en: 1;
}
}
ProcedureStep(S1) {
iCall(test_tdr) {
}
}
}
InSystemTest {
Controller(M_gt_tessent_in_system_test_1_inst) {
TestProgram(0) {
pattern: P1;
}
}
}
}

The test program has three scans. The first scan is an IR-scan that loads instruction opcode “00”
into the TAP instruction register. The next two DR-scans correspond to writing and reading bit
string “001100” into a 6-bit TDR that is selected by the prior TAP instruction. The pattern set
has a pin constraint on port post_en to “1” and an asynchronous clock called REFCLK with a
period of 25 ns.

Tessent® MissionMode User’s Manual, v2018.3 45

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
In-System Test IP Insertion and Pattern Generation
Guidelines for Programming the CPU for In-System Test

SETUP> puts [format_dictionary [get_instrument_dictionary

mentor::in_system_test::PatternsSpecification]]
P1 {
tester_period 100
tck_period 100
active_scan_interface TC0
data {
S1 {
reset0 {}
scan0 {
scan_type IR
length 2
write_data 00
expect_data 01
}
scan1 {
scan_type DR
length 6
write_data 001100
expect_data XXXXXX
}
scan2 {
scan_type DR
length 6
write_data 001100
expect_data 001100
}
}
}
clocks {
REFCLK 25.0
}
constraints {
post_en 1
}
}

46 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Appendix A
Getting Help

There are several ways to get help when setting up and using Tessent software tools. Depending
on your need, help is available from documentation, online command help, and Mentor
Graphics Support.
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Mentor Support Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

The Tessent Documentation System

At the center of the documentation system is the InfoHub that supports both PDF and HTML
content. From the InfoHub, you can access all locally installed product documentation, system
administration documentation, videos, and tutorials. For users who want to use PDF, you have a
PDF bookcase file that provides access to all the installed PDF files.
For information on defining default HTML browsers, setting up browser options, and setting the
default PDF viewer, refer to the “Documentation Options” in the Mentor Documentation
System manual.

You can access the documentation in the following ways:

• Shell Command — On Linux platforms, enter mgcdocs at the shell prompt or invoke a
Tessent tool with the -manual invocation switch.

• File System — Access the Tessent InfoHub or PDF bookcase directly from your file
system, without invoking a Tessent tool. For example:
HTML:
firefox $MGC_DFT/docs/infohubs/index.html

PDF
acroread $MGC_DFT/docs/pdfdocs/_bk_tessent.pdf

• Application Online Help — You can get contextual online help within most Tessent
tools by using the “help -manual” tool command. For example:
> help dofile -manual

This command opens the appropriate reference manual at the “dofile” command
description.

Tessent® MissionMode User’s Manual, v2018.3 47

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Getting Help
Mentor Support Services

Mentor Support Services

Mentor provides a range of industry-leading support services that keep design teams productive
and up-to-date with Mentor products.
A Mentor support contract includes the following:

• Software Updates — Get the latest releases and product enhancements to keep your
environment current.

• Mentor Graphics Support Center — Access our online knowledge base, personalized
to your Mentor products.

• Support Forums — Learn, share, and connect with other Mentor users.

• Technical Support — Collaborate with Mentor support engineers to solve complex

design challenges.

• Regular Communications — Receive the latest knowledge base articles and

announcements for your Mentor products.

• Mentor Ideas — Share ideas and vote for your favorites to shape future products.
More information is available here:

https://support.mentor.com

If your site is under a current support contract, but you do not have a Support Center login,
register today:

https://support.mentor.com/register

48 Tessent® MissionMode User’s Manual, v2018.3

August 2018

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 Third-Party Information
For information about third-party software included with this release of Tessent products, refer to the Third-Party
Software for Tessent Products.

Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
 End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula

IMPORTANT INFORMATION

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

END-USER LICENSE AGREEMENT (“Agreement”)

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

1. ORDERS, FEES AND PAYMENT.

1.1. To the extent Customer (or if agreed by Mentor Graphics, Customer’s appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an “Order”), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any
additional or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order
management system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and
physically signed by an authorized representative of Customer and Mentor Graphics.

1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month
or the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes
or other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a
valid certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all
applicable taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all
payments free and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by
Customer hereunder will be Customer’s sole responsibility. If Customer appoints a third party to place purchase orders and/or
make payments on Customer’s behalf, Customer shall be liable for payment under Orders placed by such third party in the event
of default.

1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics’ delivery of Software by electronic means is subject to Customer’s provision
of both a primary and an alternate e-mail address.

2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation, setup files and design data (“Software”) are copyrighted, trade secret and
confidential information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not
expressly granted by this Agreement. Except for Software that is embeddable (“Embedded Software”), which is licensed pursuant to
separate embedded software terms or an embedded software supplement, Mentor Graphics grants to Customer, subject to payment of
applicable license fees, a nontransferable, nonexclusive license to use Software solely: (a) in machine-readable, object-code form
(except as provided in Subsection 4.2); (b) for Customer’s internal business purposes; (c) for the term of the license; and (d) on the
computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer
may have Software temporarily used by an employee for telecommuting purposes from locations other than a Customer office, such as
the employee’s residence, an airport or hotel, provided that such employee’s primary place of employment is the site where the
Software is authorized for use. Mentor Graphics’ standard policies and programs, which vary depending on Software, license fees paid
or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be limited, for example, to
execution of a single session by a single user on the authorized hardware or for a restricted period of time (such limitations may be
technically implemented through the use of authorization codes or similar devices); and (c) support services provided, including
eligibility to receive telephone support, updates, modifications, and revisions. For the avoidance of doubt, if Customer provides any
feedback or requests any change or enhancement to Products, whether in the course of receiving support or consulting services,
evaluating Products, performing beta testing or otherwise, any inventions, product improvements, modifications or developments made
by Mentor Graphics (at Mentor Graphics’ sole discretion) will be the exclusive property of Mentor Graphics.
3. BETA CODE.

3.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively “Beta Code”), which may not be used without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to
test and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.

3.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customer’s use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customer’s evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.

3.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customer’s feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 3.3 shall survive termination of this Agreement.

4. RESTRICTIONS ON USE.

4.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices
and legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall
remain the property of Mentor Graphics or its licensors. Except for Embedded Software that has been embedded in executable
code form in Customer’s product(s), Customer shall maintain a record of the number and primary location of all copies of
Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customer’s employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Customer acknowledges that Software provided hereunder may contain source code which is proprietary and
its confidentiality is of the highest importance and value to Mentor Graphics. Customer acknowledges that Mentor Graphics
may be seriously harmed if such source code is disclosed in violation of this Agreement. Except as otherwise permitted for
purposes of interoperability as specified by applicable and mandatory local law, Customer shall not reverse-assemble,
disassemble, reverse-compile, or reverse-engineer any Product, or in any way derive any source code from Software that is not
provided to Customer in source code form. Log files, data files, rule files and script files generated by or for the Software
(collectively “Files”), including without limitation files containing Standard Verification Rule Format (“SVRF”) and Tcl
Verification Format (“TVF”) which are Mentor Graphics’ trade secret and proprietary syntaxes for expressing process rules,
constitute or include confidential information of Mentor Graphics. Customer may share Files with third parties, excluding
Mentor Graphics competitors, provided that the confidentiality of such Files is protected by written agreement at least as well as
Customer protects other information of a similar nature or importance, but in any case with at least reasonable care. Customer
may use Files containing SVRF or TVF only with Mentor Graphics products. Under no circumstances shall Customer use
Products or Files or allow their use for the purpose of developing, enhancing or marketing any product that is in any way
competitive with Products, or disclose to any third party the results of, or information pertaining to, any benchmark.

4.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use, or as permitted for Embedded Software under separate
embedded software terms or an embedded software supplement. Customer shall not disclose or permit disclosure of source
code, in whole or in part, including any of its methods or concepts, to anyone except Customer’s employees or on-site
contractors, excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in
any manner except to support this authorized use.

4.3. Customer agrees that it will not subject any Product to any open source software (“OSS”) license that conflicts with this
Agreement or that does not otherwise apply to such Product.

4.4. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (“Attempted Transfer”), without Mentor Graphics’ prior written consent and
payment of Mentor Graphics’ then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics’ prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics’ option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customer’s permitted successors in
interest and assigns.

4.5. The provisions of this Section 4 shall survive the termination of this Agreement.

5. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics’ then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.

6. OPEN SOURCE SOFTWARE. Products may contain OSS or code distributed under a proprietary third party license agreement, to
which additional rights or obligations (“Third Party Terms”) may apply. Please see the applicable Product documentation (including
license files, header files, read-me files or source code) for details. In the event of conflict between the terms of this Agreement
 (including any addenda) and the Third Party Terms, the Third Party Terms will control solely with respect to the OSS or third party
code. The provisions of this Section 6 shall survive the termination of this Agreement.

7. LIMITED WARRANTY.

7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed,
will substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not
warrant that Products will meet Customer’s requirements or that operation of Products will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must
notify Mentor Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty
applies only to the initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a)
Software updates or (b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty
shall not be valid if Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in
compliance with this Agreement. MENTOR GRAPHICS’ ENTIRE LIABILITY AND CUSTOMER’S EXCLUSIVE
REMEDY SHALL BE, AT MENTOR GRAPHICS’ OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON
RETURN OF THE PRODUCTS TO MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE
PRODUCTS THAT DO NOT MEET THIS LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES
WITH RESPECT TO: (A) SERVICES; (B) PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF
WHICH ARE PROVIDED “AS IS.”

7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.

8. LIMITATION OF LIABILITY. TO THE EXTENT PERMITTED UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES (INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS’ OR ITS LICENSORS’ LIABILITY UNDER THIS
AGREEMENT EXCEED THE AMOUNT RECEIVED FROM CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS
LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8
SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.

9. THIRD PARTY CLAIMS.

9.1. Customer acknowledges that Mentor Graphics has no control over the testing of Customer’s products, or the specific
applications and use of Products. Mentor Graphics and its licensors shall not be liable for any claim or demand made against
Customer by any third party, except to the extent such claim is covered under Section 10.

9.2. In the event that a third party makes a claim against Mentor Graphics arising out of the use of Customer’s products, Mentor
Graphics will give Customer prompt notice of such claim. At Customer’s option and expense, Customer may take sole control
of the defense and any settlement of such claim. Customer WILL reimburse and hold harmless Mentor Graphics for any
LIABILITY, damages, settlement amounts, costs and expenses, including reasonable attorney’s fees, incurred by or awarded
against Mentor Graphics or its licensors in connection with such claims.

9.3. The provisions of this Section 9 shall survive any expiration or termination of this Agreement.

10. INFRINGEMENT.

10.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired
by Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics
will pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and
agrees that as conditions to Mentor Graphics’ obligations under this section Customer must: (a) notify Mentor Graphics
promptly in writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the
action; and (c) grant Mentor Graphics sole authority and control of the defense or settlement of the action.

10.2. If a claim is made under Subsection 10.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.

10.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of
other than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that
Customer makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; (h) OSS, except to the extent that
the infringement is directly caused by Mentor Graphics’ modifications to such OSS; or (i) infringement by Customer that is
deemed willful. In the case of (i), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.

10.4. THIS SECTION 10 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMER’S SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
 SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT
OR TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.

11. TERMINATION AND EFFECT OF TERMINATION.

11.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon
written notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement
or any license granted hereunder will not affect Customer’s obligation to pay for Products shipped or licenses granted prior to
the termination, which amounts shall be payable immediately upon the date of termination.

11.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination of this Agreement and/or any license granted under this Agreement, Customer shall ensure that
all use of the affected Products ceases, and shall return hardware and either return to Mentor Graphics or destroy Software in
Customer’s possession, including all copies and documentation, and certify in writing to Mentor Graphics within ten business
days of the termination date that Customer no longer possesses any of the affected Products or copies of Software in any form.

12. EXPORT. The Products provided hereunder are subject to regulation by local laws and European Union (“E.U.”) and United States
(“U.S.”) government agencies, which prohibit export, re-export or diversion of certain products, information about the products, and
direct or indirect products thereof, to certain countries and certain persons. Customer agrees that it will not export or re-export Products
in any manner without first obtaining all necessary approval from appropriate local, E.U. and U.S. government agencies. If Customer
wishes to disclose any information to Mentor Graphics that is subject to any E.U., U.S. or other applicable export restrictions, including
without limitation the U.S. International Traffic in Arms Regulations (ITAR) or special controls under the Export Administration
Regulations (EAR), Customer will notify Mentor Graphics personnel, in advance of each instance of disclosure, that such information
is subject to such export restrictions.

13. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.

14. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.

15. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customer’s normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customer’s
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customer’s
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics’ request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 15 shall survive the termination of this Agreement.

16. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America or Japan, and the laws of Japan if Customer is located in Japan. All disputes arising out of or in relation to this
Agreement shall be submitted to the exclusive jurisdiction of the courts of Portland, Oregon when the laws of Oregon apply, or Dublin,
Ireland when the laws of Ireland apply, or the Tokyo District Court when the laws of Japan apply. Notwithstanding the foregoing, all
disputes in Asia (excluding Japan) arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a
single arbitrator to be appointed by the chairman of the Singapore International Arbitration Centre (“SIAC”) to be conducted in the
English language, in accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be
incorporated by reference in this section. Nothing in this section shall restrict Mentor Graphics’ right to bring an action (including for
example a motion for injunctive relief) against Customer in the jurisdiction where Customer’s place of business is located. The United
Nations Convention on Contracts for the International Sale of Goods does not apply to this Agreement.

17. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.

18. MISCELLANEOUS. This Agreement contains the parties’ entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Any translation of this Agreement is provided to comply with local legal requirements only. In the
event of a dispute between the English and any non-English versions, the English version of this Agreement shall govern to the extent
not prohibited by local law in the applicable jurisdiction. This Agreement may only be modified in writing, signed by an authorized
representative of each party. Waiver of terms or excuse of breach must be in writing and shall not constitute subsequent consent, waiver
or excuse.

Rev. 170330, Part No. 270941