Accessug

Synopsys TestMAX™ Access User
Guide
Version T-2022.03-SP3, July 2022
Copyright and Proprietary Information Notice
© 2022 Synopsys, Inc. This Synopsys software and all associated documentation are proprietary to Synopsys, Inc.
and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys, Inc. All
other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is
strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
https://www.synopsys.com/company/legal/trademarks-brands.html.
All other product or company names may be trademarks of their respective owners.
Free and Open-Source Licensing Notices
If applicable, Free and Open-Source Software (FOSS) licensing notices are available in the product installation.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse
and is not responsible for such websites and their practices, including privacy practices, availability, and content.

www.synopsys.com
Synopsys TestMAX™ Access User Guide 2

T-2022.03-SP3
Feedback
Contents
Related Products, Publications, and Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Understanding TestMAX Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

TestMAX Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
TestMAX Access Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
TestMAX Access Network Architecture Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Star Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Ring Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Hierarchical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
SHS Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
TestMAX Access Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2. Working With TestMAX Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Configuring TestMAX Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Using the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Setting Up the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Defining the Search Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Setting Up Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Reading the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3. TestMAX Access Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

TestMAX Access Flow at Different Levels of the Design Hierarchy . . . . . . . . . . . . . 25
Core-Level Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Enabling DFT Components at the Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Defining Test Modes at the Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Defining IEEE 1500 Interface Controls at the Core Level . . . . . . . . . . . . . . . . . 30
Configuring DFT Components at the Core Level . . . . . . . . . . . . . . . . . . . . . . . . 31
3
Feedback
Contents
Checking DFT at the Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Generating TestMAX Access Components at the Core Level . . . . . . . . . . . . . . 33
Connecting DFT Components to the RTL Design at the Core Level . . . . . . . . . 35
Validating DFT Connections to the RTL Design at the Core Level . . . . . . . . . . .36
Writing Output Files From TestMAX Manager at the Core Level . . . . . . . . . . . . 37
Validating Generated PDL at the Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Enabling DFT Components at Higher Levels of the Design Hierarchy . . . . . . . . . . . 38
Executing Cores Parallelly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Configuring the TestMAX Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Reading Lower-Level Components of the Design Hierarchy . . . . . . . . . . . . . . . . . . 40
Configuring the TAP IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Checking DFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Generating TestMAX Access Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Connecting TestMAX Access Components to the RTL Design . . . . . . . . . . . . . . . . 44
Validating the TestMAX Access Connections to the RTL Design . . . . . . . . . . . . . . . 44
Verifying TestMAX Access Generated Components . . . . . . . . . . . . . . . . . . . . . . . . .45
Writing Output Files From the TestMAX Manager Tool . . . . . . . . . . . . . . . . . . . . . . .46
Pattern Porting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4. Automotive Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Autonomous In-System Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
AIT Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
AIT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
POST Using AIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
In-System Test Using AIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
AIT Pin Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Clocks and Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Clock Stopping Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Test Start and End Sequences Using the AIT Pin Interface . . . . . . . . . . . . . . . . . . . 69
Test Start and End Sequences Using the AIT IEEE 1500 Interface . . . . . . . . . . . . . 71
AIT Output Status Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Broadcasting the Test Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Generating AIT PDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4
Feedback
Contents
Enabling IEEE 1500 Interface Only Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Memory Write Using AIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Generating AIT RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Using the write_test_packets Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
write_test_packets Command Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Updating the AIT PDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
Updating AIT Wait Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Refreshing the AIT PDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Regenerating the AIT PDLs and Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Using the write_test_model Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5. Advanced Peripheral Bus Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

APB and Other Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Generating APB Using TestMAX Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
APB Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
APB Interface Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
APB Data Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
APB to IEEE 1500 Data Converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
APB Parity Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Server With APB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6. Automotive Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Synopsys Automotive DFT Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
SoC-Level Design Implementation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7. TestMAX Access IEEE 1687 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

IEEE 1687 at the Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Generating TDR: Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Generating ICL and PDL Patterns: Core Level . . . . . . . . . . . . . . . . . . . . . . . . 124
Generating Test Patterns: Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Configuring DFT: Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
IEEE 1687 at the Subsystem Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Generating TDR: Subsystem Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Generating ICL and PDL Patterns: Subsystem Level . . . . . . . . . . . . . . . . . . . 126
5
Feedback
Contents
Generating Test Patterns: Subsystem Level . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Integration to the Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Configuring DFT: Subsystem Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
IEEE 1687 at the SoC Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Generating TDR: SoC Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Generating ICL and PDL Patterns: SoC Level . . . . . . . . . . . . . . . . . . . . . . . . .129
Generating Test Patterns: SoC Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Integrating the IEEE 1687 IP to the Access Network With TAP . . . . . . . . . . . . 129
Configuring DFT: SoC Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Configuring the Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Integrating IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Access Network Ring Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Access Network Configuration: Example Usage . . . . . . . . . . . . . . . . . . . . . . . 132
IEEE 1687 Support With TestMAX SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
DFT Mode Control in SMS Using IEEE 1687 . . . . . . . . . . . . . . . . . . . . . . . . . 133
DFT Mode Control in SMS Using IEEE 1687: Example . . . . . . . . . . . . . . . . . .133
Configuring Access Network for SMS Using Separate Servers . . . . . . . . . . . . 134
Configuring Access Network for SMS Using Separate Servers: Example . . . . 134
Configuring Access Network for SMS Using a Single Server . . . . . . . . . . . . . 135
Configuring Access Network for SMS Using a Single Server: Example . . . . . . 136
6
Feedback
About This User Guide

The TestMAX Access User Guide describes the architecture, methodology, and
commands used for integrating TestMAX Access components into an RTL design.
This document is for design engineers experienced in testability concepts and for test and
DFT engineers who want to understand how to integrate TestMAX Access components
into an RTL design.
This preface includes the following sections:
• Related Products, Publications, and Trademarks
• Conventions
• Customer Support
Related Products, Publications, and Trademarks

For additional information about the TestMAX tool, see the documentation on the
Synopsys SolvNetPlus support site at the following address:
https://solvnetplus.synopsys.com
You might also want to see the documentation for the following related Synopsys products:
• TestMAX Manager
• TestMAX SMS
• TestMAX XLBIST
• TestMAX Advisor
®
• DesignWare STAR Hierarchical System
® ™
• DesignWare STAR Memory System
®
• VCS
™
• DFTMAX
• DFTMAX Ultra
• DFTMAX SEQ
®
• PrimeTime

T-2022.03-SP3
Feedback
Conventions
®
• Design Compiler
™
• Fusion Compiler
®
• Formality
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier Indicates syntax, such as write_file.
Courier italic Indicates a user-defined value in syntax, such as

write_file design_list
Courier bold Indicates user input—text you type verbatim—in examples, such
as
prompt> write_file top
Purple • Within an example, indicates information of special interest.

• Within a command-syntax section, indicates a default, such as
include_enclosing = true | false
[] Denotes optional arguments in syntax, such as

write_file [-format fmt]
... Indicates that arguments can be repeated as many times as

needed, such as
pin1 pin2 ... pinN.
| Indicates a choice among alternatives, such as

low | medium | high
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Bold Indicates a graphical user interface (GUI) element that has an

action associated with it.
Edit > Copy Indicates a path to a menu command, such as opening the Edit
menu and choosing Copy.

T-2022.03-SP3
Feedback
Customer Support
Convention Description
Ctrl+C Indicates a keyboard combination, such as holding down the Ctrl

key and pressing C.
Customer Support
Customer support is available through SolvNetPlus.
Accessing SolvNetPlus
The SolvNetPlus site includes a knowledge base of technical articles and answers to
frequently asked questions about Synopsys tools. The SolvNetPlus site also gives you
access to a wide range of Synopsys online services including software downloads,
documentation, and technical support.
To access the SolvNetPlus site, go to the following address:
https://solvnetplus.synopsys.com
If prompted, enter your user name and password. If you do not have a Synopsys user
name and password, follow the instructions to sign up for an account.
If you need help using the SolvNetPlus site, click REGISTRATION HELP in the top-right
menu bar.
Contacting Customer Support

To contact Customer Support, go to https://solvnetplus.synopsys.com.

T-2022.03-SP3
Feedback
1
Understanding TestMAX Access
The TestMAX Access tool is built on the DesignWare STAR Hierarchical System (SHS)
technology. The SHS is an automated hierarchical test solution for testing an SoC or
designs using multiple IP blocks. The SHS creates a hierarchical IEEE 1500 network to
access and control all IP blocks at the SoC level.
This topic describes the architecture of the TestMAX Access tool and integration of
the Access components into an RTL design. The terms SHS and Access are used
interchangeably in this document.
To learn more about the basics of the TestMAX Access tool, see
• TestMAX Access
• TestMAX Access Network Architecture
• TestMAX Access Network Architecture Types
• SHS Server Architecture
• TestMAX Access Design Flow
• Licensing
TestMAX Access
The TestMAX Access tool leverages the SHS technology and the IEEE 1149.1, IEEE
1149.6, IEEE 1500, and IEEE 1687 standards to provide a test access infrastructure that
automates test integration and validation for an SoC.
The following are the key features of the TestMAX Access tool:
• Integrates and verifies the IEEE 1687 network and IEEE 1687-compliant IP
◦ Extracts and verifies instrument connectivity language (ICL) files
◦ Ports hierarchical procedural description language (PDL) patterns
• Integrates and verifies the IEEE 1500 access network

T-2022.03-SP3
Feedback
Chapter 1: Understanding TestMAX Access
TestMAX Access
◦ Recognizes existing IEEE-compliant IP

◦ Ports patterns from low to high design hierarchy
◦ Validates ported patterns
◦ Generates tester-ready patterns in WGL, STIL, and SVF formats
◦ Diagnoses post-silicon failures
• Integrates and verifies test patterns
Additionally, the tool provides the following features:
• Provides a mechanism for inserting the IEEE 1149.1-, IEEE1149.6-, IEEE 1500-, or
IEEE 1687-compliant IP into an RTL design at the initial RTL stage
• Generates a centralized server (depending on the user configuration) that connects the
IP blocks using the IEEE 1500 or IEEE 1687 network to the RTL design
• Generates the test access port (TAP) controller and boundary-scan registers (BSR)
• Supports in-system testing by generating the Autonomous In-System Test (AIT)
controller for automotive design
• Checks the connectivity of the modified RTL design
• Checks the compliance of the test patterns before the patterns are ported to the SoC
level
• Generates the server and TAP controller DFT constraints, which are used in the
downstream design process
For IEEE Std 1149.1 and IEEE Std 1149.6, the tool provides the following features:
• Inserts boundary-scan components
• Verifies boundary-scan designs (BSD)
• Generates BSDL and test patterns
• Checks compliance (only IEEE Std 1149.1)
For more information, see https://www.synopsys.com/implementation-and-signoff/test-
automation/testmax-access.html.

T-2022.03-SP3
Feedback
TestMAX Access Network Architecture

The TestMAX Access tool provides serial access to non-memory IP blocks through the
IEEE 1500 or IEEE 1687 interface (and further to JTAG) for testing. The IP blocks can be
analog cores, digital cores, or mixed-signal cores such as PLLs, ADCs, DACs, and GPIOs.
The Access network consists of multiple SMS or SHS cores compliant to the IEEE 1500
standard. The cores are grouped together using a shared module called the server,
which is controlled by the JTAG TAP. The bridge logic between the TAP and IEEE 1500-
compliant interfaces is called the JTAG to IEEE 1500 converter (JPC).
The server provides access points to the TAP controller, system processor TAP, Advanced
Peripheral Bus (APB), self-monitoring analysis and reporting technology (SMART), and
AIT. The server consists of two main components: the shared fuse processor (SFP) and
JPC. The SFP controls the repair signature flow through the IEEE 1500 network between
the eFUSE and SMS cores. The eFUSE block is a one-time programmable non-volatile
memory used to store repair data. For more information about the JPC_SFP block, see
SHS Server Architecture.
SMART provides the interface to run functions such as built-in self-test (BIST), built-in hard
repair (BIHR), and user-defined register (UDR) load. The JPC_SFP block uses SMART
for both SMS and SHS cores. The system processor TAP and AIT controller provide an
alternate path to access the SMS cores for in-system test and diagnostics.
The servers located at the lower levels are called subservers. SMS or SHS cores are
connected to the server or subserver in a ring. The cores with similar behavior are
connected in a ring. For example, the SRAM or ROM memories are in the SMS ring and
the analog or mixed-signal wrappers are in the SHS ring.
The following figures show the TestMAX Access network without and with a subserver.

T-2022.03-SP3
Feedback
Figure 1 TestMAX Access Network Without a Subserver

SoC
TAP
Server
1500 ring 1
1687 ring 4
1687 ring 5
1500 ring 6
Ring 2
Ring 3
1687 wrapped
Third-party 1500
XLBIST Third-party
IP1 wrapped IP
IP3
Core1 Core1 Core1
1500 wrapped
1500 Third-party
XLBIST IP2 Third-party
wrapped IP
IP4
Core2 Core2 Core2
1500
XLBIST
wrapped IP
Core3 Core3
Subsystem1 Subsystem2 Subsystem3

T-2022.03-SP3
Feedback
Figure 2 TestMAX Access Network With a Subserver

SoC
TAP
Server
1500 ring 1
1687 ring 4
1500 ring 5
Ring 2
Ring 3
1687 wrapped
Third-party Subserver
XLBIST Third-party
IP1
IP3
Core1 Core1
1500 wrapped
1500 Third-party
XLBIST IP2 Third-party
wrapped IP
IP4
Core2 Core1 Core2
1500
XLBIST
wrapped IP
Core3 Core2
The TestMAX Access tool

• Inserts the IEEE 1500 wrapper around the IP under test in the SoC design
• Propagates all IEEE 1500 signals to the appropriate hierarchy
• Propagates TestMAX Access test ports to the SoC level or the subsystem boundary
interface
• Provides support for nested subsystems
• Integrates and connects the inserted IEEE 1500 wrapper and server components into
both the RTL and gate-level functional hierarchy of the SoC
• Changes the default location (top level) within the SoC design
• Controls and stores the state of each IEEE 1500 wrapper and server in a common
workspace

T-2022.03-SP3
Feedback
TestMAX Access Network Architecture Types
• Provides compliance with the SystemVerilog IEEE 1800-2009 standard

• Inserts IEEE Std 1149.1 and IEEE Std 1149.6 TAP controller components for AC-
coupled, differential, or advanced digital networks

The TestMAX Access (SHS) server can select a single SHS core at a time to apply the
test patterns. The server can also select a fixed number of SHS cores in a daisy-chained
concatenation to apply the test patterns in parallel.
The three types of server architectures are:
• Star Architecture
• Ring Architecture
• Hierarchical Architecture
Star Architecture
A server with the star architecture has the following features:
• Server accesses each SHS core individually.
• More connections from all SHS cores to the server.
• Number of connections is six times the number of SHS cores.
• SHS cores can be daisy chained within the server.
• An individual SHS core can be bypassed from the server daisy chain.

T-2022.03-SP3
Feedback
Figure 3 Star Architecture
JTAG TAP
SHS SHS
SHS STAR SHS

server
Fuse box
SHS SHS
Ring Architecture
A server with the ring architecture has the following features:
• Server accesses each ring individually.
• Server cannot access an SHS core individually.
• An individual SHS core in a ring cannot be bypassed from the server. Only a complete
ring can be bypassed.
Figure 4 Ring Architecture

JTAG TAP
SHS SHS
SHS
SHS
SHS
STAR
SHS
server
Fuse box SHS
SHS SHS

T-2022.03-SP3
Feedback
SHS Server Architecture
Hierarchical Architecture
A server with the hierarchical architecture has the following features:
• Server accesses only its SHS cores or rings.
• An individual SHS core in a ring cannot be bypassed from the server. Only a complete
ring can be bypassed.
Figure 5 Hierarchical Architecture

JTAG TAP
SHS SHS
JTAG-ready
SHS SHS
subserver
Fuse box
Subserver1 Subserver2
SHS SHS
SHS SHS SHS SHS SHS

SHS
For more information about the architecture of the server, see the SHS Server User Guide.

The following figure shows the Access (SHS) server with different interfaces.

T-2022.03-SP3
Feedback
Figure 6 Access Server and Interfaces

TAP System
controller processor TAP APB master SMART
Server
spif_mode
SFP_JPC AIT
eFUSE SFP JPC

Ring 1
Ring 2
Ring n
The JTAG to IEEE 1500 converter (JPC) logic converts the IEEE Std 1149.1 signals
into IEEE 1500 interface signals. The shared fuse processor (SFP) controls the repair
signature flow for all Access (SHS) cores in the Access network through the IEEE 1500
interface. The SFP provides an interface between the Access cores and the eFUSE block.
The JPC_SFP block controls the Access SMART BIST functionality. The system processor
TAP interface provides an alternate path to access SMS and all memories. This enables
in-system test and diagnostics of the embedded memories through the firmware using an
embedded or external processor.
The tool generates the APB interface driver at the server level. The APB driver contains
two registers for data decoding, which are addressed as word0 and word1.
The AIT block allows you to perform in-system and power-on self-test (POST) on the
XLBIST cores. For more information about the XLBIST cores, see the TestMAX XLBIST
User Guide. For more information about AIT, see Automotive Testing.
The server is connected in a two-level hierarchy. The server is always at the first level. The
servers at the second level are called subservers. The subservers can contain
• Their own core rings, JPC_SFP, and eFUSE
• Their own core rings, JPC_SFP, and a shared eFUSE
• Core rings only (shadow server)

T-2022.03-SP3
Feedback
TestMAX Access Design Flow
The following figure shows the server hierarchy.
Figure 7 Server Hierarchy

eFUSE
Server
IEEE 1500 rings
Subserver eFUSE eFUSE

Core (Ring only subchip)
Core
Core
Subserver Subserver
Core
Core Core Core Core

Core
Core
Subserver
(Ring only subchip)
Core Core Core Core Core
Core

This topic describes the design flow used to integrate the TestMAX Access components
such as a server, shadow servers (subservers with only core rings), and subservers
(subservers with components such as core rings, JPC_SFP, and eFUSE) into an RTL
design and validate the RTL design in a hierarchical or flat design.

T-2022.03-SP3
Feedback
The following steps are involved in the TestMAX Access design flow:
1. Set up DFT: Read and elaborate the design files and enable DFT components.
2. Configure DFT: Define clocks, IP blocks, test modes, compression, and other DFT
components.
3. Check DFT: Perform RTL lint (syntax) and scan checks using the TestMAX Advisor
tool.
4. Generate DFT: Generate DFT components based on the configuration.
5. Connect DFT: Integrate the Access-generated components into the RTL design.
6. Validate DFT: Perform structural checks and connections between Access-generated
components using the TestMAX Advisor tool.
7. Write output files: Save the protocol, test models, ICL, and PDL files for the
downstream process.
Test patterns are represented using the PDL and ICL languages. The PDL defines the
procedures and actions of the XLBIST core. The ICL describes the elements and I/O
ports of the XLBIST core.
Figure 8 TestMAX Access in the DFT Flow
NDMs for memory DFT config MASIS files for

RTL files
and standard cells memories
TestMAX Manager
TestMAX XLBIST TestMAX Access TestMAX SMS TestMAX Advisor
DFT SDC
ICL PDL
RTL + DFT RTL Test models Test protocols constraints constraints Testbench
Design Compiler or Fusion Compiler
TestMAX DFT
Netlist

T-2022.03-SP3
Feedback
Licensing
Licensing
The following licenses (provided with the tool) and tools are required for the TestMAX
Access tool:
• Test-Platform-RTL license: Only one copy of the Test-Platform-RTL license is checked
out upon invocation. The license is not released until you exit the tool. Set the
SNPSLMD_LICENSE_FILE environment variable to the license server hosting the Test-
Platform-RTL license.
• Test-Platform-Access license: Used for enabling the hierarchical flow.
• TestMAX Advisor (Version Q-2020.03-SP1): Used for scan and connectivity checks.
This license is checked out when the tool runs the plan_dft, check_dft, and
validate_dft commands.
• VCS: Used for Verilog simulation.

T-2022.03-SP3
Feedback
2
Working With TestMAX Access
The TestMAX Access tool can only be used through a command-line interface called
dft_shell.
For information about working with the TestMAX Access, see

• Configuring TestMAX Access
• Using the User Interface
• Setting Up the Design
Configuring TestMAX Access

Before invoking TestMAX Access, set the following environment variables:
• SNPSLMD_LICENSE_FILE: Specify the license server hosting the Test-Platform-RTL
license.
• VCS_HOME: Specify the path of the latest VCS installation.
Using the User Interface

The command-line interface allows you to enter commands at the command line prompt.
The interface is used for scripts, batch mode, and push-button operations.
To start the TestMAX Access tool, enter the tool invocation command, dft_shell, at the
Linux shell prompt.
At startup, the dft_shell command performs the following tasks:
• Displays the program header and the dft_shell prompt.
• Executes any script file or command specified by the -file option.
Running the TestMAX Access tool generates the following files in the current directory:
• dft_command.log: List of commands executed.
• dft_output.txt: Log file that captures the commands and output.

T-2022.03-SP3
Feedback
Chapter 2: Working With TestMAX Access
Setting Up the Design
To exit the tool, use the exit or quit command.

The TestMAX Access tool uses a design library to store the design and the associated
library information. This topic describes how to create a design library, prepare and save
the design, and configure the network.
To set up the design, see
• Defining the Search Path
• Setting Up Libraries
• Reading the Design
Defining the Search Path

The TestMAX Access tool uses a search path to look for files that are specified with a
relative path or no path. To specify the search path, use the set_app_var command and
set the search_path application variable to list the directories in the order of precedence.
When the tool looks for a file, the tool starts the search from the first directory specified in
the search_path variable and selects the first matching file.
Use the search_path variable with the following commands:
• set_app_var – The following example specifies the REFLIBS and NLIBS directories
using a relative path for the tool to search for files.
Example: dft_shell> set_app_var search_path {../REFLIBS ../NLIBS}
• lappend – Use the lappend command to add directories to the default search path,
which is the directory from which you invoked the tool.
Example: dft_shell> lappend search_path ./mylibdir
Setting Up Libraries
The create_lib command creates a new design library. Use this command with the
-ref_libs option to read the cell libraries (NDM) for memories, standard cells, I/O pads,
and so on. The following example shows the command usage.
dft_shell> create_lib -ref_libs \
{../NDM/cell_library_name ../NDM/saed32hvt_c.ndm} stdcell.nlib

T-2022.03-SP3
Feedback
Chapter 2: Working With TestMAX Access
Reading the Design

The tool can read RTL designs in SystemVerilog or Verilog format.
Use the analyze and elaborate commands followed by the set_top_module command.
The analyze and elaborate commands create files such as .mr, .pvl, and .hdl in the
HDL_LIBRARIES/WORK directory. The elaborate command builds the specified module
without linking to other modules of the design. This allows you to run multiple elaborate
commands before performing a single linking of the entire design.
The top-level module must be a module that was previously elaborated using
the elaborate command. The top-level module is given as an argument to the
set_top_module command. The set_top_module command sets the specified module as
the top-level design, links the entire design, and creates a single block that is used for the
remaining design flow.
The following example shows the command usage.
// Reading the Design RTL Files
set design des_unit_core
analyze -f sverilog [glob RTL/*]
elaborate $design
set_top_module $design

T-2022.03-SP3
Feedback
3
TestMAX Access Flow
This topic describes the steps involved in the TestMAX Access hierarchical flow.
Note:
The TestMAX Access tool supports only hierarchical design flows.
To generate and integrate Access components, see
• TestMAX Access Flow at Different Levels of the Design Hierarchy
• Core-Level Flow
• Enabling DFT Components at Higher Levels of the Design Hierarchy
• Executing Cores Parallelly
• Configuring the TestMAX Access Network
• Reading Lower-Level Components of the Design Hierarchy
• Configuring the TAP IP
• Checking DFT
• Generating TestMAX Access Components
• Connecting TestMAX Access Components to the RTL Design
• Validating the TestMAX Access Connections to the RTL Design
• Verifying TestMAX Access Generated Components
• Writing Output Files From the TestMAX Manager Tool
• Pattern Porting
TestMAX Access Flow at Different Levels of the Design Hierarchy

The following figures show the flow of the TestMAX Access tool at the core, subsystem,
and SoC levels.

T-2022.03-SP3
Feedback
Chapter 3: TestMAX Access Flow
Figure 9 Core-Level Flow

Set up DFT
open_lib, analyze, elaborate, set_top_module
Read standard cell library files, analyze, elaborate, and link design
Configure DFT
set_dft_configuration -ieee_1500 enable,
define_test_mode -usage ...,set_dft_signal ...
Enable DFT components, define test modes ...
Check DFT
check_dft
Perform RTL lint and scan checks
Generate DFT
generate_dft
Generate DFT IP Verilog files and connectivity files *.ict.zip and *.wks file
used at subsytem or SoC level
Connect DFT
connect_dft
Modify RTL design to instantiate the generated DFT IP and make
required connections
Validate DFT
validate_dft
Connectivity checks on the modified RTL design
Write output files

report_dft, write_test_protocol, write_test_model,
write_dft_constraints
Save protocol, test model, ICL, PDL ... files

T-2022.03-SP3
Feedback
Figure 10 Subsystem-Level Flow

Set up DFT
Read standard cell library files, analyze, elaborate, and link design
Configure DFT
read_test_model – Read ICL/PDL that has information about
interface connectivity, ports, and patterns
set_dft_access_element – Specify the access type, subserver
or shadow server
Check DFT
check_dft
Generate DFT
generate_dft
Connect DFT
connect_dft
Modify RTL design to instantiate the generated DFT IP and make
Validate DFT
validate_dft
Connectivity checks on the modified RTL design
Write output files


T-2022.03-SP3
Feedback
Figure 11 SoC-Level Flow

Set up DFT
Read standard cell library files, analyze, elaborate, and link the design
Configure DFT
read_test_model – Read ICL/PDL that contains information about
interface connectivity, ports, and patterns
set_dft_access_element – Specify the subserver and
shadow server
Check DFT
check_dft
Generate DFT
generate_dft
Connect DFT
connect_dft
Modify RTL design to instantiate the generated DFT IP and make the
Validate DFT
validate_dft
Perform connectivity checks on the modified RTL design
Write output files


T-2022.03-SP3
Feedback
Core-Level Flow
Core-Level Flow
The following topics describe the tasks that you must perform on each core before
configuring DFT at a higher level in the design hierarchy:
• Enabling DFT Components at the Core Level
• Defining Test Modes at the Core Level
• Defining IEEE 1500 Interface Controls at the Core Level
• Configuring DFT Components at the Core Level
• Checking DFT at the Core Level
• Generating TestMAX Access Components at the Core Level
• Connecting DFT Components to the RTL Design at the Core Level
• Validating DFT Connections to the RTL Design at the Core Level
• Writing Output Files From TestMAX Manager at the Core Level
• Validating Generated PDL at the Core Level
Enabling DFT Components at the Core Level

To enable the TestMAX DFT components into the RTL design, use the
set_dft_configuration command.
An example of the DFT components enabled at the core level:

set_dft_configuration
-wrapper enable
-ieee_1500 enable
-clock_controller enable
-logicbist enable
-scan_compression enable
-scan enable
Defining Test Modes at the Core Level

To define a test mode, use the define_test_mode command. For example,
define_test_mode test_mode_name.
Each test mode must have a unique name that can be used to refer to the test mode in
the subsequent DFT commands or reports. You can either use the default test mode and
define additional test modes or create a new set of test modes.

T-2022.03-SP3
Feedback
Core-Level Flow

set_dft_signal -type TestMode -port [list TM1 TM2]
define_test_mode xlbist -usage logicbist
define_test_mode wrp_if -usage wrp_if -encoding [list TM1 0 TM2 1 TM3 1 ]
define_test_mode wrp_of -usage wrp_of -encoding [list TM1 1 TM2 1 TM3 1 ]
define_test_mode scan -usage scan -encoding [list TM1 0 TM2 1 TM3 0 ]
define_test_mode sccomp -usage streaming_compression -encoding \
[list TM1 0 TM2 0 TM3 1 ]
You can use the following options with the define_test_mode command:
• -usage wrp_if: Inward facing or INTEST mode of wrapper configuration. This mode is
used for testing all logic internal to the IP under test. In this mode, the tool enables and
configures wrappers to drive and capture data within the core, in conjunction with the
internal chains.
• -usage wrp_of: Outward facing or EXTEST mode of wrapper configuration. This
mode is used for testing all logic external to the IP under test. The tool enables and
configures wrappers to drive and capture data outside the core. The internal chains are
disabled.
• -usage scan: Standard scan mode operation, which is the default if the -usage option
is not specified. The top-level scan-in ports drive the scan chains, and the scan chains
in-turn drive the top-level scan-out ports. This mode is used for testing all logic internal
to the IP under test.
• -usage streaming_compression: Compressed scan mode of operation. In this mode,
the scan data decompressors drive the internal scan chains, and the scan chains in
turn drive the scan data compressors. This mode is used for testing all logic internal to
the IP under test with reduced test data volume and test application time.
• -usage logicbist: Inserts the TestMAX XLBIST IP in the design.
Defining IEEE 1500 Interface Controls at the Core Level

To define the IEEE 1500 ports in the design, use the set_dft_signal command. You
can create the ports using the create_port command. Before creating the ports, run the
setup_rtl_flow command.

##P1500 Signals
set_dft_signal -type WSI -port WSI -view spec
set_dft_signal -type WSO -port WSO -view spec
set_dft_signal -type WRCK -port WRCK -view spec
set_dft_signal -type WRSTN -port WRSTN -view spec
set_dft_signal -type CaptureWR -port CAPTUREWR -view spec
set_dft_signal -type ShiftWR -port SHIFTWR -view spec

T-2022.03-SP3
Feedback
Core-Level Flow
set_dft_signal -type UpdateWR -port UPDATEWR -view spec

set_dft_signal -type SelectWIR -port SELECTWIR -view spec
For more information about the set_dft_signal command options, see the man pages.
Configuring DFT Components at the Core Level

To configure the DFT components such as the scan chain, OCC, TestMAX XLBIST, set
the sequential compression mode, and manufacture the test patterns, use the following
commands:
Define DFT signals
set_dft_signal -type ScanDataIn -port port_name
set_dft_signal -type ScanDataOut -port port_name
set_dft_signal -type ScanDataEnable -port port_name
Specify on-chip clocking (OCC)

set_dft_clock_controller -cell_name occ_ctrl \
-pllclocks [list wrp_clk u_pll_1/pll_clk_2 u_pll_1/pll_clk_2] \
-ateclock ate_clk -cycles_per_clock $occ_chain_len \
-chain_count $occ_chain_count
Configure logic BIST

set_logicbist_configuration -chain_count $k -xtolerance high \
-test_mode {xlbist} -misr_width $misr -pattern_counter_width $pcw \
-shift_counter_width $scw
Configure scan compression

set_scan_compression_configuration -inputs $sc -outputs $sc \
-chain_count $k -streaming true -clock ate_clk -test_mode {sccomp}
Configure scan and wrapper

set_ieee_1500_configuration -wir_width 4
set_scan_configuration -chain_count $sc -test_mode {wrp_if}
set_scan_configuration -chain_count $sc -test_mode {scan}
set_wrapper_configuration -reuse_threshold -1 -test_mode {wrp_of}
set_wrapper_configuration -chain_count 2 -test_mode {wrp_of}
Define wrp_of scan ports for top-level integration

for { set i 0 } { $i < $wrapper_chain_count} {incr i} {
set_dft_signal -type ScanDataIn -port wrp_si$i -test_mode wrp_of
set_dft_signal -type ScanDataOut -port wrp_so$i -test_mode wrp_of }
Define wrp_shift for non-XLBIST mode

set_dft_signal -port wrp_shift -type wrp_shift -test_mode wrp_of

T-2022.03-SP3
Feedback
Core-Level Flow
Create test protocol

create_test_protocol
Checking DFT at the Core Level

To analyze the RTL design, use the check_dft command. This command identifies
potential coverage issues and DFT violations that must be corrected. The TestMAX
Advisor tool runs in the background.
The check_dft command creates the following files and directories:
• spg_check_dft_sources.f: List of all RTL source files
• spg_check_dft_constraints.sgdc: TestMAX Advisor constraints such as clocks and test
modes
• spg_check_dft_config.prj: File required by the TestMAX Advisor tool to read the source
and .sgdc files, other setup violation reports, and to set the defined goals
• spg_check_dft_config: Directory that contains the following files:
◦ spg_check_dft_config/design_name/dft_shell_goal/spyglass_reports/dft/
dftCoverage.rpt: Report of stuck-at coverage
◦ spg_check_dft_config/design_name/dft_shell_goal/spyglass_reports/dft/
no_scan.rpt: List of non-scan cells
◦ spg_check_dft_config/design_name/dft_shell_goal/spyglass_reports/simple.rpt
The check_dft command generates the following output.
Information: Generating design lib file ./spg_check_dft_gate_design.tlib
Information: Generating functional RTL source list
file ./spg_check_dft_sources.f
Information: Generating constraint file for scan readiness
checks ./spg_check_dft_constraints.sgdc
Invoking SpyGlass...
…/spyglass_R-2020.09/SPYGLASS_HOME/bin/spyglass -project
spg_check_dft_config.prj -goal dft_shell_goal -batch
Information: SpyGlass run started
Information: Synthesis completed
Information: Flattening completed
Information: SpyGlass running goal(s) `dft_shell_goal' with top
`des_unit_core' completed successfully
SpyGlass Message Summary: 0 error, 3 warnings, 80 Infos
------------------------------------------------------------------------
---
Results Summary:
------------------------------------------------------------------------
---

T-2022.03-SP3
Feedback
Core-Level Flow
Total Flip flop count: 1888

Scannable Flip flop count: 1888
Total combinational reconvergent paths to clock pins of flip-flop
: 0
Total combinational reconvergent paths to asynchronous pins of
flip-flops: 0
Total sequential reconvergent paths to asynchronous pins of flip-flops
: 0
Stuck-at fault coverage = 86.6%
Stuck-at test coverage = 86.7%
Percentage of scannable flip-flops = 100.0%
-------------------------------------------------------------------------
---
Reports Directory:
work_dir/spg_check_dft_config/consolidated_reports/des_unit_core_dft_shel
l_goal/
SpyGlass LogFile:
work_dir/spg_check_dft_config/consolidated_reports/des_unit_core_dft_shel
l_goal/spyglass.log
Standard Reports:
spyglass_violations.rpt moresimple.rpt
Information: Use 'check_dft -load_gui on' for loading SpyGlass GUI
1
Generating TestMAX Access Components at the Core Level

The generate_dft command generates TestMAX Access components based on the
following constraints:
• DFTMAX, DFTMAX Ultra, DFTMAX SEQ, and XLBIST
• OCC
• IEEE 1500-dedicated wrapper
• Pipeline scan data
The generate_dft command also displays messages showing the
• Configuration of the test IP generated
• Scan signals used
• Location of the generated DFT components along with the file names

T-2022.03-SP3
Feedback
Core-Level Flow
The generate_dft command generates the following output.

Summary of enabled DFT components
Warning: 'check_dft' command should be run to get an early estimate of
the coverage and scan readiness of the design. (DFT-2902)
Client Status
Scan Enable
Wrapper Enable
Logicbist Enable
Mbist Enable
Dft Access Enable
Scan_compression Enable
Pipeline_scan_data Enable
Clock_controller Enable
ieee_1500 Enable
Bsd Disable
Hsio Disable
Summary of DFT implementation

Begin Core Wrapper Analysis ...
End Core Wrapper Analysis ...
information: Generated DFT Wrapper IP Verilog
in ./des_unit_core_WC_D1.16994.v
- Partition: 'default_partition’
Information: Architecting Shared Head Pipeline with '2' stages
Information: Architecting Shared Tail Pipeline with '2' stages
Information: Architecting DFT Scan IP with '7' scan chains in mode
'wrp_if'
Information: Architecting DFT Scan IP with '7' scan chains in mode 'scan'
Information: Architecting DFT Extest Wrapper IP with '2' wrapper chains
in mode 'wrp_of'
Information: Architecting Streaming DFT Compressor IP with '8' inputs /
'8' outputs / '80' internal chains in mode 'sccomp'
Information: Architecting '5' Input Wrapper Chains / '7' Output Wrapper
Chains / '68' Scan Chains
Information: Architecting DFT XLBist Compressor IP with '80' internal
chains in mode 'xlbist'
Information: Architecting '5' Input Wrapper Chains / '7' Output Wrapper
Chains / '68' Scan Chains
Summary of DFT connections

ScanDataIn:
Mode: sccomp
"si0" -> U_DFT_TOP_IP_0/si[0]
[...]
Mode: wrp_if
[...]

T-2022.03-SP3
Feedback
Core-Level Flow
Mode: scan
[...]
Mode: wrp_of
"wrp_si0" -> U_DFT_TOP_IP_0/si[7]
"wrp_si1" -> U_DFT_TOP_IP_0/si[8]
[...]
ScanDataOut:
Mode: sccomp
"so0" -> U_DFT_TOP_IP_0/so[0]
[...]
Mode: wrp_if
[...]
Mode: scan
[...]
Mode: wrp_of
"wrp_so0" -> U_DFT_TOP_IP_0/so[7]
"wrp_so1" -> U_DFT_TOP_IP_0/so[8]
[...]
DFT IP files and location

Information: Generating DFT IP Verilog
in /./DFTTopIP_des_unit_core0.1699.v
in /./DFTSpcChainIP_des_unit_core0.1699.v
[...]
Connecting DFT Components to the RTL Design at the Core Level

The connect_dft command integrates the DFT components into the RTL design,
connects the components, and then generates the modified RTL in the output/Verilog
directory. This directory contains the source file content and the modified content. All
modified files retain the original RTL design name.

T-2022.03-SP3
Feedback
Core-Level Flow
Validating DFT Connections to the RTL Design at the Core Level

The validate_dft command validates the generated constraints for connections and
rules. To perform lint checks on the Access-generated components, use the -check
connectivity option. To output additional details, use the -verbose option.
• -check connectivity: Performs connectivity checks between the DFT components

and the RTL design. Performs rule checks on the Access-generated components.
• -verbose: Generates verbose output during the connectivity check.
The validate_dft -check connectivity command generates the following output.

dft_shell> validate_dft -check connectivity
/global/apps/spyglass_R-2020.09/SPYGLASS_HOME/bin/spyglass -project
spg_validate_dft_config.prj -goal dft_shell_goal -batch
[...]
------------------------------------------------------------------
Results Summary:
------------------------------------------------------------------
: 0
flip-flops : 0
: 0
------------------------------------------------------------------
Reports Directory:
work_dir/spg_validate_dft_config/consolidated_reports/des_unit_core_dft_
shell_goal/
SpyGlass LogFile:
work_dir/spg_validate_dft_config/consolidated_reports/des_unit_core_dft_
shell_goal/spyglass.log
Standard Reports:
Information: Use 'validate_dft -load_gui on' for loading SpyGlass GUI
1

T-2022.03-SP3
Feedback
Core-Level Flow
Writing Output Files From TestMAX Manager at the Core Level

The TestMAX Manager tool writes out the following files:
• IEEE1450.1 STIL protocol files
• IEEE1450.6 CTL test models
• IEEE1687 ICL and PDL files
• Constraint files for inserting scan chains in the RTL design using the Design Compiler
or Fusion Compiler tool
• SDC constraints for the PrimeTime tool and synthesis constraints for the Design
Compiler tool
• Constraint files for formal verification using the Formality tool
To save the protocol files, use the following commands:
write_test_protocol
-output ./spf/$design.wrp_if.spf -test_mode {wrp_if}
-output ./spf/$design.wrp_of.spf -test_mode {wrp_of}
-output ./spf/$design.xlbist.spf -test_mode {xlbist}
-output ./spf/$design.compr.spf -test_mode ScanCompression_mode}
To save the test model, use the following command:

write_test_model -output ./output/$design\_CTL.ctl
To save the ICL and PDL files, use the following command:
write_testbench
-icl_pdl enable
-out ./patterns/$design\_1687
-test_mode xlbist
To write constraints to connect the DFT components to scan chains in the Design
Compiler or Fusion Compiler tool, use the write_dft_constraints command. This
command also writes the constraints for formal equivalence checks using the Formality
tool.
write_dft_constraints -output constr
The following files are created:

• constr.fc.tcl: For use in the Fusion Compiler tool.
• constr.tcl: For use in the Design Compiler tool.

T-2022.03-SP3
Feedback
Enabling DFT Components at Higher Levels of the Design Hierarchy
• constr.helper.tcl: Referenced by the Design Compiler or Fusion Compiler script to

define wrapped cells.
• constr.fm.tcl: For use in the Formality tool ( to set the circuit to functional mode).
Validating Generated PDL at the Core Level

For validating the generated PDL at core level, use the validate_dft command with the
verify_access_component option.
For example, the following command validates the TestMAX XLBIST IPs at the core level:
validate_dft -check verify_access_component
Enabling DFT Components at Higher Levels of the Design

Hierarchy
To enable the DFT components at higher levels of the design hierarchy, use the
set_dft_configuration command with the following options:
-dft_access enable
-bsd enable
-ieee_1500 enable
Note:
You can enable DFT components such as scan, compression, wrapper, OCC,
and pipeline with the components mentioned above. To create ports in the RTL
design, use the setup_rtl_flow and create_ports commands.
Executing Cores Parallelly

To execute cores parallelly, create user-defined groups and specify cores for generating
merged PDL patterns using the set_dft_access_configuration command.
The syntax of the command is as follows:
set_dft_access_configuration
-group test_group_name
-cores {core_list}
-misr_comparison individual | unified

T-2022.03-SP3
Feedback
Configuring the TestMAX Access Network
You can use the following options with the set_dft_access_configuration command:
• -group: Specify the user-defined group name for the set of cores to be executed
parallelly
• -cores: Specify the list of cores that needs to be grouped. You can also specify a
single core for this option.
• -misr_comparison: Specify the type of comparison for MISR. The default MISR
comparison type is unified.
For example,
set_dft_access_configuration -group test_group_1 -cores \
{core1_1 core1_2} -misr_comparison individual
set_dft_access_configuration -group test_group_2 -cores \
{core2 core3} -misr_comparison individual]
To generate a merged PDL for the user-specified core groups, use the port_patterns
command.
For example,
port_patterns -access_interface ieee1149.1 -format pdl -merge
{Test_group_1 Test_group_2}
For more information about the port_patterns command, see the man pages.
Configuring the TestMAX Access Network

To configure the TestMAX Access network in the hierarchical flow
1. Use the set_dft_access_configuration command to define the TestMAX Access
parameters for the design.
2. Use the set_dft_access_element -type top_server command to enable the
server as the top-level controller.
3. Use the set_dft_access_element command to specify the TestMAX Access
server, subserver, and other components. Use any parameter to customize the wire
connections between the defined Access component and any other port or module.
set_dft_access_element
–type server | sub_server | shadow_server | AIT
-instance instance_name -module module_name
-parameter [ list parameter_name parameter_value | -file file_name1 ]
-interface [ list signal_type signal_connection | -file file_name2 ]

T-2022.03-SP3
Feedback
Reading Lower-Level Components of the Design Hierarchy
You can use the following options with the set_dft_access_element command:
◦ -instance instance_name: Specify the instance name.
◦ -module module_name: Specify the module name.
◦ -parameter [list parm1 value param2 value…|file file_name]: Specify the

parameter definitions.
◦ -interface [list signal_type signal_connection…|file file_name]:
Specify the wire connection between the Access components and the user-defined
ports or any other interface or ports.
4. Connect the IP blocks under test in a ring architecture.
set_dft_ring ring_name
-ordered_elements ordered_list
-head_element head_list
-tail_element tail_list
-include_elements include_list
-complete true|false
You can use the following options with the set_dft_ring command:
◦ -ordered_elements ordered_list: Specify the order in which the components
are connected.
◦ -head_element head_component: Specify the first component of the ring.
◦ -tail_element tail_component: Specify the last component of the ring.
◦ -include_elements unordered_list: Include components without an order.
◦ -complete true|false: When false, the tool controls the order of the rings.
Reading Lower-Level Components of the Design Hierarchy

To read the TestMAX Access-generated test models for the lower-level components of the
design hierarchy, use the read_test_model command . You can use the following options
with the read_test_model command:
• -format icl|wks|pdl|ict: Specify the type of test model.
◦ icl: Specify the ICL for the IP to access.
◦ wks: Specify the workspace file path. For lower-level BIST cores, specifies the file at
a higher level of the design hierarchy.
◦ pdl: Specify the PDL of the IP to access.

T-2022.03-SP3
Feedback
Configuring the TAP IP
◦ ict: Specify the compout directory. For lower-level cores, specifies the file at a
higher level of the design hierarchy.
◦ hdl: Specify the stub file path of the lower blocks.
• -design: Specify the top module of the design.

read_test_model ../core/des_unit_core_srv_1.ict.zip -format ict \
-design des_unit_core
read_test_model ../core/des_unit_core.wks -format wks -design \
des_unit_core
read_test_model ../core/output/stub/des_unit_core.v -format hdl \
read_test_model ../core/output/des_unit_core.icl -format icl \
read_test_model ../core/output/des_unit_core.pdl -format pdl \
Configuring the TAP IP

To configure the TAP at the SoC level, use the set_dft_configuration command
with the -bsd enable option. To define the TAP, use the set_bsd_configuration and
set_bsd_instruction commands. You can use the -ir_width option to set the width of
the instruction register.
set_dft_configuration -bsd enable
set_bsd_configuration -ir_width 4
set_dft_signal
-type tdi -port TDI -view spec
-type tdo -port TDO -view spec -active_state 1
-type tck -port TCK -view spec
-type tms -port TMS -view spec
-type trst -port TRSTN
set_bsd_instruction SMS_SEL -code op_code \
-register SERVER1 -length 1

T-2022.03-SP3
Feedback
Checking DFT
Table 1 Test Signals
Signal Type Keyword Description
tck Test clock
tdi Test data in
tdo Test data out
tdo_en Test data out enable
tms Test mode select
trst Asynchronous test reset (optional)
To identify the IEEE Std 1149.1 TAPs, use the set_dft_signal command. This command
places an attribute on the specified port; the attribute's value is the same as the signal type
keyword.
set_dft_signal -view spec|existing_dft -type signal_type \
-port port_list -hookup_pin pad_output_name
Checking DFT
Use the check_dft command to identify potential coverage issues and DFT violations.
The check_dft command generates the following output.
Information: Generating design lib file ./spg_check_dft_gate_design.tlib
Information: Generating functional RTL source list
file ./spg_check_dft_sources.f
Information: Generating constraint file for scan readiness
checks ./spg_check_dft_constraints.sgdc
…/spyglass_R-2020.09/SPYGLASS_HOME/bin/spyglass -project
spg_check_dft_config.prj -goal dft_shell_goal -batch

Information: SpyGlass running goal(s) `dft_shell_goal' with top
`des_unit_core' completed successfully
SpyGlass Message Summary: 0 error, 3 warnings, 80 Infos
-----------------------------------------------------------------
Results Summary:
-----------------------------------------------------------------

T-2022.03-SP3
Feedback
Generating TestMAX Access Components

: 0
flip-flops : 0
: 0
Stuck-at fault coverage = 86.6%
Stuck-at test coverage = 86.7%
Percentage of scannable flip-flops = 100.0%
-----------------------------------------------------------------
Reports Directory:
work_dir/spg_check_dft_config/consolidated_reports/des_unit_core_dft_she
ll_goal/
SpyGlass LogFile:
work_dir/spg_check_dft_config/consolidated_reports/des_unit_core_dft_she
ll_goal/spyglass.log
Standard Reports:
Information: Use 'check_dft -load_gui on' for loading SpyGlass GUI
Generating TestMAX Access Components

Use the generate_dft command to generate the TestMAX Access components based
on the DFT constraints provided. The generate_dft command generates the following
output.
Creating Fabric IP for Hierarchical Flow
Added target ctl instance soc .
Added target ctl instance u_des_unit_soc_core .
Added target ctl instance soc .
ctlName des_unit_core InstName u_des_unit_soc_core
- Partition: 'default_partition'
Information: Architecting DFT Scan IP with '8' scan chains in mode
'soc_top_scan'
Information: Architecting Streaming DFT Compressor IP with '9' inputs /
'9' outputs / '80' internal chains in mode 'soc_top_sccomp'
Architecting Fabric IP
Information: Architecting Shared Head Pipeline with '1' stages

Information: Architecting Head Balancing Pipeline
3 head stages added to top level logic
1 head stages added to u_des_unit_soc_core

T-2022.03-SP3
Feedback
Connecting TestMAX Access Components to the RTL Design
0 head stages added to u_subsystem

Information: Architecting Shared Tail Pipeline with '1' stages
Information: Architecting Tail Balancing Pipeline
3 tail stages added to top level logic
1 tail stages added to u_des_unit_soc_core
0 tail stages added to u_subsystem
[…]
Connecting TestMAX Access Components to the RTL Design

The connect_dft command integrates the DFT components into the RTL design,
connects the components, and then generates the modified RTL in the output/Verilog
directory. This directory contains the modified RTL files and the list of source RTL files.
The modified files retain the original RTL name. The connect_dft command generates
the following output.
Invoking RTL modifier...
RTL modifier run started
Information: RTL modifier design read complete.
Information: DFT IP instantiation complete.
Information: Connection for ScanDataIn DFT IP complete.
Information: Connection for ScanDataOut DFT IP complete.
Information: Connection for TestMode DFT IP complete.
Information: Connection from Scan Enable to DFT IP complete.
Information: RTL generation complete.
Information: RTL modifier run completed successfully.
Information: Modified RTL with DFT IP generated at
work_dir/output/Verilog directory.
RTL modifier Log Directory: work_dir/rtl_modifier_log/
RTL modifier LogFile : work_dir/rtl_modifier_log/gensys.log
1
Validating the TestMAX Access Connections to the RTL Design

The validate_dft command validates the generated constraints for connections and
rules. You can also specify an option to perform lint checks on the Access-generated
components.
• -check connectivity: Performs connectivity checks between the DFT components
and the RTL design. Also, performs rule checks on the Access-generated components.
• -verbose: Generates verbose output during the connectivity check.
For more information about the validate_dft command, see the man pages.
The validate_dft -check connectivity command generates the following output.

T-2022.03-SP3
Feedback
Verifying TestMAX Access Generated Components
/global/apps/spyglass_R-2020.09/SPYGLASS_HOME/bin/spyglass -project
spg_validate_dft_config.prj -goal dft_shell_goal -batch
'SCAN_DATA_INPUT' group connection validation started...
'63' check(s) passed
'0' check(s) failed
[…]
Information: SpyGlass running goal(s) `dft_shell_goal' with top `soc'
completed successfully
SpyGlass Message Summary: 177 errors, 39 warnings, 1195
Infos
---------------------------------------------------------------------
Results Summary:
---------------------------------------------------------------------
: 0
flip-flops : 0
: 0
---------------------------------------------------------------------
Reports Directory:
work_dir/spg_validate_dft_config/consolidated_reports/soc_dft_shell_go
al/
SpyGlass LogFile:
work_dir/spg_validate_dft_config/consolidated_reports/soc_dft_shell_go
al/spyglass.log
Standard Reports:
Information: Use 'validate_dft -load_gui on' for loading SpyGlass GUI
1
Verifying TestMAX Access Generated Components

For validating the Access-generated components at the top level, use the validate_dft
command.
The syntax of the command is as follows:
validate_dft
[verify_access_component | verify_access_system]
[-group test_group_name]
[-testbench generate_only | simulate_only | all]

T-2022.03-SP3
Feedback
Writing Output Files From the TestMAX Manager Tool
[-masis_dir path_to_dir]
[-apb on | off]
You can the following options with the validate_dft command:

• -verify_access_component: Perform lower-level PDL validation. This option is used
only at the lower levels.
• -verify_access_system: Perform XLBIST validation at the top level
• -group: Specify the list of cores groups for which merged testbenches are generated.
• -testbench: You can specify the following arguments for this option:
◦ generate_only: Generate patterns and testbenches
◦ simulate_only: Simulate testbenches for the generated patterns
◦ all: This is the default option for generation of testbench and simulates them as
well.
• -masis_dir: Specify the location of the MASIS files directory. The default directory is
generated_files.
• -apb: Specify the type of interface (JTAG or APB) for validation for the STAR Silicon
Debugger tool. The default value is off.
For example,
• Validating XLBIST IPs at the top level
validate_dft -check verify_access_system
• Generating and simulating testbench for the merged PDLs with JTAG interface
validate_dft -check verify_access_system -group \
{test_group_1 test_group_2}
• Generating and simulating testbench for the merged PDLs with APB interface
validate_dft -check verify_access_system -group \
{test_group_1 test_group_2} -apb on
Writing Output Files From the TestMAX Manager Tool

The TestMAX Manager tool writes out the following files:
• IEEE1450.1 STIL protocol files
• IEEE1450.6 CTL test models
• IEEE1687 ICL and PDL files

T-2022.03-SP3
Feedback
Pattern Porting
• Constraint files for connecting XLBIST cores to scan chains in the Design Compiler or
Fusion Compiler tool
• SDC constraints for the PrimeTime tool and synthesis constraints for the Design
Compiler tool
• Constraint files for formal verification using the Formality tool
Note:
You can write out the protocol files and test models by using the
write_test_protocol and write_test_model commands.
Write DFT constraints

To write constraints to connect the DFT components to the scan chains in Design
Compiler or Fusion Compiler, use the write_dft_constraint command . This command
also writes constraints for formal equivalence checks using Formality. The following
example shows the command usage.
-output ${design}_dft_constraints_shift
-test_mode defined -mode shift -occ active
-output ${design}_dft_constraints_capture
-test_mode defined -mode capture -occ active
-output {design}_dft_constraints_any
-test_mode defined -mode any -occ active
The following files are created:

• constr.fc.tcl: For use in Fusion Compiler
• constr.tcl: For use in Design Compiler
• constr.helper.tcl: Referenced by the Design Compiler or Fusion Compiler script to
define wrapped cells
• constr.fm.tcl: For use in Formality (sets the circuit to functional mode)
Pattern Porting
Test patterns generated at a lower level can be ported to a higher level. To port the core-
level patterns to SoC-level, use the following command:
port_patterns -access_interface ieee1149.1 -pdl on
The ported patterns are saved in tester formats such as STIL and WGL. The Verilog
testbench is also saved for simulation of the patterns.

T-2022.03-SP3
Feedback
Pattern Porting
The syntax of the port_patterns command is as follows:

port_patterns
[-access_interface ieee1149.1 | apb | fabric]
[-format stil | wgl | pdl | firmware_c_code | sequence_text]
[-masis_dir filepath]
[-template_file filepath]
[-merge listOfCoresGroups]
You can the following options with the port_patterns command:

• -access_interface: Specify the type of access interface for the design. You can use
the following arguments with this option:
◦ ieee1149.1: Specify this argument when the JTAG interface is enabled
◦ apb: Specify this argument when the APB interface is enabled
◦ fabric: Specify this argument when the fabric is enabled
• -format: Specify the format in which patterns are ported. You can use the following
arguments with this option:
◦ stil: Port the patterns in STIL format
◦ wgl: Port the patterns in WGL format
◦ pdl: Port the patterns in PDL format
◦ firmware_c_code: Specify this argument for APB C code generation
◦ sequence_text: Specify this argument for APB sequence text generation
• -masis_dir: Specify a custom path for the MASIS files
• -template_file: Specify the path of the template trace file for APB sequence text
generation. The default path is the location of the template FTS file generated by the
STAR Yield Accelerator tool.
• -merge: Specify the list of user-defined groups to generate the merged PDL
For example,
• Porting serial PDL patterns
port_patterns -access_interface ieee1149.1 -format pdl
• Porting serial STIL patterns using the user-provided MASIS files

port_patterns -access_interface ieee1149.1 -format stil -masis_dir
masis_files
• Porting merged PDLs for user-specified cores groups

T-2022.03-SP3
Feedback
Pattern Porting
port_patterns -access_interface ieee1149.1 -format pdl -merge

{Test_group_1 Test_group_2}
• Porting ATPG patterns

port_patterns -verbose on -access_interface fabric -format stil
For more information about the port_patterns command, see the man pages.

T-2022.03-SP3
Feedback
4
Automotive Testing
Automotive and industrial applications are safety critical and must comply to safety
regulations such as ISO 26262 (automotive) and IEC 61508 (industrial). High-quality
silicon must have zero defective parts per million (DPPM) so no faulty chips are shipped
to customers. Periodic testing is done in the field to safeguard against defects originating
because of aging. For these stringent requirements, DFT (structural testing) becomes part
of the on-chip safety mechanism.
Standards specify only fault classes and detection requirements. In an implementation,
purely software-based functional testing can be used if it meets the criteria and the
fault metrics (such as coverage and time) are measurable. Structural tests using DFT
techniques are fault-metric based. A combination of functional and structural fault
detection methods is required to meet the quality goals.
The following are a few automotive-DFT design safety concepts:
• Single point fault metric (SPFM)
• Latent fault metric (LFM)
• Fault tolerant time interval (FTTI)
• Failure in time (FIT)
The ISO 265262 standard defines automotive safety integrity levels (ASIL), which defines
the level of risk reduction needed to achieve a tolerable risk for safety. There are four
levels: ASIL A, ASIL B, ASIL C, and ASIL D. The criteria for ASIL levels gets stricter from
ASIL A through ASIL D, that is, ASIL D defines the highest integrity level. For the higher
levels, the tests must detect more faults in less time and propagate the results faster.

T-2022.03-SP3
Feedback
Chapter 4: Automotive Testing

The following figure shows the relationship between time and failure occurrence for the
ASIL levels.
Failure detection
ASIL-D
Failure occurence
ASIL-C
ASIL-B
ASIL-A
The following are the requirements for automotive DFT:

• High manufacturing test coverage and low DPPM
• Cover many structures (memory, logic, analog or mixed-signal, and so on) using DFT
solutions through in-system test (IST)
• Ensure high coverage of safety structures such as error correction code (ECC), cyclic
redundancy check (CRC), safety-engine logic, lock-step comparator modules, self-
coverage mechanism for dynamic function exchange (DFx) structures, and so on
• Gap analysis of missing coverage by combining fault metrics from functional and
structural tests
• Routing test data and propagating test results faster, which are as important as
detection of the fault itself
• Safety coverage of blocks that are conduits in enabling in-system test
• Self-testing and safety-ready subsystems
• Target fault coverage according to the required ASIL level
• Pass or fail status from in-system test must be a multibit encoded bus and not a single
bit
To learn more about automotive testing, see
• Autonomous In-System Test
• AIT Operating Modes
• AIT Architecture
• POST Using AIT
• In-System Test Using AIT

T-2022.03-SP3
Feedback
Autonomous In-System Test
• AIT Pin Description

• Clocks and Resets
• Test Start and End Sequences Using the AIT Pin Interface
• Test Start and End Sequences Using the AIT IEEE 1500 Interface
• AIT Output Status Modes
• Broadcasting the Test Content
• Generating AIT PDL
• Enabling IEEE 1500 Interface Only Mode
• Memory Write Using AIT
• Generating AIT RTL
• Using the write_test_packets Command
• Updating the AIT PDL
• Regenerating the AIT PDLs and Testbenches
• Using the write_test_model Command

Automotive devices must be tested while in use in the application or when no ATE is
available to provide test data. The Synopsys Autonomous In-System Test (AIT) controller
provides minimal data to the XLBIST logic that applies test patterns to the XLBIST cores
autonomously using the IEEE 1500 network. The AIT controller uses ring-based topology
and SHS components such as the server, subserver, and eFUSE as the test data access
mechanism.
The AIT controller works with these SHS network types: server only and server and
subserver. The following figure shows the AIT controller with a server-only SHS network.

T-2022.03-SP3
Feedback
Figure 12 AIT Controller With a Server-Only SHS Network

APB interface JTAG (1149.1)
APB-to-1500 JTAG-TAP
Converter FSM
Control MUX
Server
MUX
MUX MUX
WSI_RING1
WSO_RING1
WSO_RING2
WSO_RING2
WSI_RING2
WSI_RING2
AITXLBIST_WSI/WSC
AIT_TEST_MODE
WSO_RING2
Control
interface
MCU/PMU/ Status XLBIST XLBIST
Safety Manager interface AIT
(Customer IP) Start
address
XLBIST XLBIST
POST_or_IST_enable
MUX
Programmable test data XLBIST XLBIST

RAM ROM

T-2022.03-SP3
Feedback
The following figure shows the AIT controller with a server and subserver SHS network.
Figure 13 AIT Controller With a Server and Subserver SHS Network
SMART IP
Server
Subserver AIT XLBIST SMS

IEEE 1500
IP
IEEE 1500
XLBIST SMS
IEEE 1500 IP
AIT XLBIST SMS
IP
XLBIST
XLBIST SMS
The TestMAX Access tool

• Inserts the AIT controller for in-system testing
• Ports patterns from the core level to the SoC level
• Inserts a test data register (TDR) and recognizes the user-defined register (UDR) in the
XLBIST core
The following figure shows the AIT controller with the APB interface. When the AIT
controller is at the server level, the core-level PDL is ported to the SoC-level PDL. When

T-2022.03-SP3
Feedback
AIT Operating Modes
the AIT controller is at the subserver level, the core-level PDL is ported to the subsystem-
level PDL.
Figure 14 AIT Controller and APB Interface

TAP
TDR SoC-level
APB SMART IP PDL
JTAG
Server
Subsystem
-level PDL
Subserver AIT XLBIST SMS

IEEE 1500
IP
IEEE 1500
XLBIST SMS
IEEE 1500 IP
AIT XLBIST SMS
IP
Core-level XLBIST Core-level

PDL XLBIST SMS PDL
AIT Operating Modes

The three different operating modes of the AIT controller are:
• Manufacturing test
• Power On/Off Self-Test (POST)
• In-system test (IST)
Manufacturing Test
The AIT controller can be switched to functional mode using the IEEE 1500 network while
the ATE applies test patterns on the XLBIST core. In functional mode, the AIT controller
1. Fetches test data from the AIT memory
2. Collects responses from the XLBIST cores using the IEEE 1500 network
3. Compares the responses with the expected value and gives the test status (pass or
fail) to the output ports. This ensures that there are no defects in the AIT logic and path
during the test.

T-2022.03-SP3
Feedback
AIT Operating Modes
POST
If APB is available, it can trigger the AIT controller using the APB driver. If APB is not
available, then the AIT controller can be triggered by the power management unit (PMU)
through the pin interface. In POST mode, the AIT controller
2. Collects responses from the XLBIST cores using the AIT ports or APB network (if
available)
fail) to the output ports
In-System Test
In in-system test mode, the APB triggers the AIT controller using the APB driver. In in-
system mode, the AIT controller
2. Collects responses from the XLBIST cores using the AIT ports or APB network (if
available)
fail) to the output ports
The following are a few implementation choices for the in-system test:
• CPU-driven test – Uses more bandwidth of the CPU and network on chip (NoC)
1. The CPU or the Safety Manager drives the test data through the APB interface of
the server.
2. The CPU provides test data, waits for the test to finish, and reads the multiple-input
status register (MISR).
3. The CPU compares the MISR with the expected values and determines whether the
test has passed or failed.
• CPU-triggered test – Uses less bandwidth of CPU and on-chip functional resources
1. The CPU or the Safety Manager drives the test data through the APB interface of
the server and loads the test data in the memories.
2. The CPU then triggers DFT resources such as the AIT controller, which fetches and
executes tests, similar to POST mode.

T-2022.03-SP3
Feedback
AIT Architecture
3. The CPU and NoC are idle when the test runs. The CPU can carry out functional
tasks or tests on other blocks.
4. The CPU waits for a certain number of cycles and checks the AIT status. Or, the
CPU polls and gets an interrupt from the AIT when the test status is available.
AIT Architecture
The AIT controller manages XLBIST-based POST or IST for automotive SoC designs
through the IEEE 1500 interface. The AIT controller also reduces the load on the CPU
during the in-system test.
The following steps are involved in the functioning of the AIT controller:
1. The CPU or PMU triggers the AIT controller.
2. The AIT controller fetches test data from the memory and applies it to the XLBIST
cores through the IEEE 1500 network.
3. The AIT controller collects responses from the XLBIST cores and compares it with the
expected data stored in the memory.
4. After the comparison, the AIT controller indicates whether the test has passed or failed.
The following figure shows the AIT controller architecture.
Figure 15 AIT Controller Architecture
SRAM, ROM, Memory

IEEE 1500
and so on
Output interface
Input interface
EXEC unit
IEEE 1500 Status Error handler
System Control
Control unit
The following figure shows the AIT controller signals.

T-2022.03-SP3
Feedback
AIT Architecture
Figure 16 AIT Controller Signals

Clocks
i_ait_clk i_div_wrck i_ref_clk
i_timeout_cnt_strap
o_status
i_mode
o_wso_compare_status
PMU/custom i_test_start
o_wso_compare_status_ready
input interface i_test_enable
PMU/custom
o_max_compare_wso_done
i_abort output interface
o_core_status_valid
i_reset_counter
o_xlbist_ateclk_stop
o_ait_test_mode
i_data_valid
i_mem_data_in
i_mem_start_addr
o_mem_rd_enable AIT controller
Memory interface o_mem_addr
o_mem_wr_en i_i15002ait_wso
o_mem_wr_data o_ait2i1500_wsi
o_ait2i1500_wrck
WSI
o_ait21500_wrstn
WRCK Output IEEE 1500
WRSTN o_ait2i1500_selectWIR interface
WRCK o_ait2i1500_shiftWR
Input IEEE 1500
SelectWIR o_ait2i1500_captureWR
interface
ShiftWR o_ait2i1500_updateWR
CaptureWR
UpdateWR
WSO
i_ait_bypass_mode i_ait_rstn
Reset
The AIT controller supports the following hardware features:

• Central and distributed AIT architectures
• Jump to a memory address when the AIT content is distributed
• Pause/resume for reloading the test memory
• Toggle the WRSTN signal from the XLBIST cores to clear the IEEE 1500 interface
data. Stop WRCK when toggling WRSTN.
• Stop-on-first-fail, which reduces the status generation time and provides faster
response to the system
• Compress data for long running zeros in the input WSI data
• Memory write/read for debug and memory interface checks
• Detect wrong AIT packets in the memory

T-2022.03-SP3
Feedback
POST Using AIT
The AIT controller supports the following automation features:

• Convert structural test vectors into AIT packets
• Early estimate of the number of bytes of test data
• Test sequences for XLBIST cores
• Concurrent testing of multiple XLBIST cores
• eFUSE-triggered test for SMART XLBIST operation (for POST)
• Memory content checks for correctness of test data
• Multi-input signature register (MISR)
• SHS pipelining
POST Using AIT

POST is managed by the AIT controller. The AIT controller runs through the instructions
stored in the RAM or ROM. The XLBIST testing is controlled through the subserver
module that allows operation from either the AIT controller or IEEE 1500 interface. The
subserver is connected to the server through the IEEE 1500 interface. The APB bus is
used for complex in-system tests through the embedded processor. In the following figure,
the grey blocks represent the customer IP.
Figure 17 POST Using the AIT Controller

IEEE 1500
Subserver
WSI_RING2
AITXLBIST_WSI/WSO
WSO_RING2
WSI_RING2
WSO_RING2
WSO_RING2
AIT_TEST_MODE
Control interface
Power XLBIST
Status interface
AIT
manager Start address
POST_or_IST_enable
Programmable test data RAM/ROM XLBIST

T-2022.03-SP3
Feedback
In-System Test Using AIT
In-System Test Using AIT

The TestMAX Access tool provides infrastructure for both in-system and production tests.
You can enable multiple XLBIST engines during the same sessionand apply tests through
the TAP or APB.
AIT Pin Description

The following tables list the pin and status of signals required to integrate the AIT
controller into the RTL design.
Note:
One XLBIST core interval includes multiple patterns.
Table 2 Pin Description
Pin Direction Clock Source/Load Functionality
i_data_valid Input i_ait_clk MCU/PMU/Safety Indicates whether the memory data

Manager is available. If this pin is high and the
AIT controller is in functional mode, the
controller starts fetching data from the
memory. No dependency on any other
inputs.
i_abort Input i_ait_clk MCU/PMU/Safety If this pin is set to 1, the AIT operation is
Manager terminated immediately.
To start the AIT operation, apply i_abort
= 0 and assert test_en and test_start in a
four ait_clk interval.
i_ait_clk Input N/A Functional clock Primary clock that controls all AIT
(PLL) registers. No dependency on any other
IP.
i_ait_rstn Input Asynchron MCU/PMU/Safety Active low asynchronous reset. When

ous Manager ait_rstn is set to 0, the AIT controller is in
reset mode.
For the reset operation, first de-assert
reset and then apply i_ait_clock. Applying
i_ait_clock and i_ait_rstn at the same
time can create unknown values in the
silicon.

T-2022.03-SP3
Feedback
AIT Pin Description
Table 2 Pin Description (Continued)
i_ref_clk Input i_ait_clk Functional clock Controls the watchdog counter flip-flops;
no limit on the clock frequency. If the
(divided) (Oscillator/PLL)
frequency of i_ref_clk is high, the timeout
count occurs quickly. The i_ref_clk clock
frequency and the timeout count values
must be adjusted optimally. i_ref_clk
must be ratio synchronous to i_ait_clk.
i_timeout_cnt Input i_ref_clk MCU/PMU/Safety Provides the number of times the

_strap[N:0] Manager i_ref_clk signal toggles before the
timeout occurs. The timeout value is
i_timeout_cnt_strap
2 .You can override the
IEEE 1500 control.
The value must not change in the middle
of an operation because the new value
immediately takes effect. So, it is safe
to set i_timeout_cnt before the AIT
operation starts.
i_mode[1:0] Input i_ait_clk MCU/PMU/Safety Indicates the mode of operation, 00 – AIT

Manager mode, 10 – debug mode, or 11 – memory
read/write. You can override the IEEE
1500 control.
i_test_enable Input i_ait_clk MCU/PMU/Safety Starts the test sequence. Must go from
Manager 0 to1 and stay high until the test is
completed.
i_test_start Input i_ait_clk MCU/PMU/Safety Must go from 0 to 1, four cycles after

Manager asserting i_test_enable for starting the
test. TDR is overridden.
i_mem_start Input i_ait_clk MCU/PMU/Safety Gives the address from which the
_addr [N:0] Manager AIT controller starts fetching data. If
the memory contains multiple EOT,
i_mem_start_addr must be the address
of the location where the last execution
stopped.
i_mem_start_addr must be set at the
start of AIT operation or along with either
test_en or test_start. TDR is overridden.
i_mem_data Input i_ait_clk MCU/PMU/Safety Input from the memory to the AIT
_in [N:0] Manager controller. Memory data widths supported
are 8, 16, 32, and 64. Must connect with
read_data of the memory.

T-2022.03-SP3
Feedback
AIT Pin Description
selectWIR / Input WRCK Server/subserver IEEE 1500 interface of the AIT controller,
shiftWR / driven by the IEEE 1500 network.
captureWR /
updateWR
WSI Input WRCK Server/subserver WSI IEEE 1500 data input, driven by the
IEEE 1500 network.
WRSTN Input Asynchron Server/subserver IEEE 1500 network reset input, driven
ous by the IEEE 1500 network. Requires
functional override in POST or IST mode.
N/A
WRCK Input N/A Server/subserver IEEE 1500 network clock input, driven
by the IEEE 1500 network. Requires
functional clock source in POST or IST
mode.
i_div_wrck Input i_ait_clk Functional clock Drives the IEEE 1500 interface logic of
(divided) (PLL) the AIT controller.
i_div_wrck is ratio synchronous with
ait_clk and can be /1 , /2, /3 or /4 or /5 of
i_ait_clk. i_div_wrck must match with the
IEEE 1500 WRCK frequency.
i_i15002ait_ Input i_div_wrck Server/subserver WSO coming from the XLBIST ring
wso through the server or subserver.
o_mem_rd_e Output i_ait_clk Test ROM/RAM Read enable for test memory (RAM or
nable ROM)
o_mem_wr Output i_ait_clk Test ROM/RAM Write enable for test memory
_en
o_mem_addr Output i_ait_clk Test ROM/RAM Read/write address of the test memory.
If the AIT controller is reading from
memory, o_mem_addr acts as the read
address.
If the AIT controller is writing into the
memory, o_mem_addr acts as the write
address.
o_ait_test_m Output i_ait_clk MCU/PMU/Safety Indicates that the AIT-based XLBIST test
ode Manager is enabled

T-2022.03-SP3
Feedback
AIT Pin Description
o_mem_wr_ Output WRCK Test RAM Provides write data to the AIT memory
data when the memory write feature is
enabled
o_status_re Output i_ait_clk MCU/PMU/Safety Indicates when to collect the AIT status.
ady Manager If o_status_ready is 1, the AIT status can
be collected.
o_ait2i1500_ Output i_div_wrck Server/subserver IEEE 1500 output from the AIT controller
selectWIR that goes into the XLBIST ring
shiftWR that goes into the XLBIST ring
captureWR that goes into the XLBIST ring
updateWR that goes into the XLBIST ring
o_ait2i1500_ Output Asynchron Server/subserver IEEE 1500 output from the AIT controller
wrstn ous that goes into the XLBIST ring
N/A
wrck that goes into the XLBIST ring
wsi that goes into the XLBIST ring
WSO Output WRCK Server/subserver IEEE 1500 output of the AIT controller
that connects to the server
i_ait_bypass Input Asynchron MCU/PMU/Safety i_ait_bypass_mode must be 0 when the

_mode ous Manager AIT controller is in functional mode.
N/A i_ait_bypass_mode must be 1, for scan
insertion.
i_ait_bypass_mode must be treated as a
constant, for SPF generation.
Example: set_dft_signal -type
constant -active_state 1 -port
i_ait_bypass_mode

T-2022.03-SP3
Feedback
AIT Pin Description
o_status[3:0] Output i_ait_clk MCU/PMU/Safety Shows the current status of the AIT
Manager controller.
IDLE – 4’b0000
BUSY – 4’b0010
MEM_MISR_FAIL_AND_TEST_PASS –
4’b0101
MEM_MISR_PASS_AND_TEST_FAIL –
4’b0110
BAD_AIT_INSTRUCTION_DETECTED –
4’b0111
AIT_MEM_INTERFACE_WRONG –
4’b1000
PAUSE – 4’b1001
TEST PASS – 4’b1111
TIMEOUT – 4’b1011
TEST FAIL – 4’b1100
BAD_TEST_SEQ – 4’b1101
ABORT – 4’b1010
Test complete without any WSO
comparisons – 4’b1110
i_reset_coun Input ref_clock MCU/PMU/Safety Resets the timeout counter. Must be

ter Manager high for at least one i_ref_clk. TDR is
overridden. i_reset_counter can be 1
until test_enable is applied to the AIT
controller. After that, i_reset_counter
must be 0.
o_xlbist_atec Output Asynchron MCU/PMU/Safety Clock gating enable for ATE clock (clock
lk_stop ous Manager/Server input of XLBIST).
N/A
o_xlbist_atec Output Asynchron MCU/PMU/Safety Clock gating enable for ate clk (clock
lk_stop ous Manager input of XLBIST)
N/A
o_ring_sel Output i_ait_clk Server Indicates the active XLBIST rings
o_ring_status Output i_ait_clk MCU/PMU/Safety Status of each XLBIST ring. 0 = fail, 1 =

Manager pass.

T-2022.03-SP3
Feedback
AIT Pin Description
o_ring_status Output i_ait_clk MCU/PMU/Safety Indicates whether the values of each bit
_valid Manager in the o_ring_status_valid bus is valid in
per XLBIST status mode.
o_ring_<x>_ Output i_ait_clk MCU/PMU/Safety Status of each XLBIST core in ring_x, in

status Manager per XLBIST status mode.
In per pattern status mode, the status of
pattern comparisons done using the AIT
packets is logged. If there is an overflow
in the o_ring_<x>_status ports, then the
remaining status of pattern comparisons
is logged in o_wso_comapre_status.
o_ring_<x>_ Output i_ait_clk MCU/PMU/Safety Indicates whether the values of each bit
status_valid Manager in the o_ring_<x>_status bus is valid in
per XLBIST status mode.
o_wso_comp Output i_ait_clk MCU/PMU/Safety Indicates the status of an XLBIST core

are_status[N Manager in per XLBIST core status mode or
:0] interval/pattern in per interval/pattern
status mode. The status depends on the
AIT behavior set by the AIT packets.
In per XLBIST core status mode, each bit
in wso_compare_status [n:0] indicates
the status of one XLBIST core. For
example, if bit[n] = 1, then the status of
th
the n core in the IEEE 1500 ring is pass.
If bit[n] = 0, then the status is fail.
In per interval/pattern status mode, each
bit in wso_compare_status indicates
the status of one interval/pattern. For
th
example, if bit[n] = 1, the status of the n
interval/pattern is pass. If bit[n] = 0, then
the status is fail.
o_wso_comp Output i_ait_clk MCU/PMU/Safety Indicates when to collect the

are_status_r Manager o_wso_compare_status
eady
o_max_comp Output i_ait_clk MCU/PMU/Safety Gives the maximum number of

are_wso_d Manager comparisons completed
one

T-2022.03-SP3
Feedback
AIT Pin Description
Table 3 Status Description
Status Encoding Description
IDLE 4’b0000 Indicates that the AIT operation has not yet started.
The AIT controller is in IDLE state until the test start
sequence is completed.
BUSY 4’b0010 Indicates that the AIT controller is busy after it

completes the test start sequence.
MEM_MISR_FAIL_AND_ 4’b0101 Indicates that the MISR check failed and the test
TEST_PASS passed when the memory MISR check is enabled
MEM_MISR_PASS_AND 4’b0110 Indicates that the MISR check passed and the test
_TEST_FAIL failed when the memory MISR check is enabled
BAD_AIT_INSTRUCTION 4’b0111 Indicates that the AIT controller received incorrect or

_DETECTED unsupported AIT instruction packet. This occurs when
the AIT memory is corrupted.
AIT_MEM_INTERFACE_ 4’b1000 Interface connection between the AIT controller and

WRONG the AIT memory is not correct. That is, data enable, clk
enable, and read enable are not connected between
the AIT controller and the AIT memory.
STATUS_PAUSE 4’b1001 AIT operations pause when the AIT controller gets this
instruction. The AIT controller comes out of the pause
state after it detects toggle on i_data_valid.
STATUS_TEST_PASS 4’b1111 Indicates that the AIT controller successfully completed

all WSO comparisons for the given memory content.
That is, the expected response (stored inside memory
as AIT packets) and actual response are the same.
If the MEM MISR check is enabled, indicates that both
the MEM MISR check and the test result passed.
STATUS_TIMEOUT 4’b1011 Timeout occurs when the timeout counter reaches the
timeout_cnt_value
maximum limit, that is, (2 ) i_ref_clk.
The timeout counter works even when the AIT
controller has not started. Timeout can be reset by
applying i_reset_counter or programming the RESET
counter bit in SHS2AIT_CTRL TDR.
Apply i_ait_rstn to start a new sequence, after the
timeout occurs.
STATUS_TEST_FAIL 4’b1100 Indicates that there is a mismatch in the comparison

between the expected and actual WSO data.
If you enable the MEM MISR check, both the MISR
check and the test result fail.

T-2022.03-SP3
Feedback
Clocks and Resets
Table 3 Status Description (Continued)
Status Encoding Description
STATUS_BAD_TEST_ 4’b1101 After the AIT operation starts, if termination occurs

SEQ without following the test end sequence, the
STATUS_BAD_TEST_SEQ status is indicated.
Apply i_ait_rstn to start a new sequence after
BAD_TEST_SEQ occurs.
STATUS_TEST_COMPL 4’b1110 Indicates that the status test is complete without WSO
ETE BUT no WSO comparison.
compares
STATUS_ABORTED 4’b1010 The AIT operation is terminated immediately when

i_abort = 1. For starting the AIT operation, i_abort must
be de-asserted.
Apply i_ait_rstn to start a new sequence after
terminating an AIT operation.
Clocks and Resets

The AIT controller has four clock domains as illustrated in the following figure.
Figure 18 AIT – Clock Domains

IEEE 1500 input
WIR
WDR SHS2AIT 1500 interface and debug data
read_interface IEEE 1500 output
AIT2CTRL
Output interface/MUX
SRAM, ROM,
EXEC engine
Packet decoder
interface
Memory
splicing
and so on
FIFO
Data
AIT21500
write_interface EXEC engine
Timeout ait_clk
CRC Master sequencer div_wrck
counter ref_clk
WRCK

T-2022.03-SP3
Feedback
Clocks and Resets
The following are the clocks used in the AIT controller:

• i_ait_clk: Primary free-running clock for the majority of AIT logic. The frequency of the
clock must be equal to or greater than the WRCK frequency of the XLBIST network.
• i_div_wrck: Clock derived from ait_clk. i_div_wrck drives the WRCK logic of XLBIST
when the AIT controller is in operational mode. i_div_wrck must be a divided version
(/1, /2,/ 3, /4, or /5) of i_ait_clk and also must be ratio synchronous to i_ait_clk, that is,
the edges of both i_ait_clk and i_div_wrck must be aligned. i_div_wrck must be a free-
running clock.
• WRCK: Input clock to the AIT controller. Controls the IEEE 1500 WIR and WDR logic of
the AIT controller.
• i_ref_clk: Controls the timeout counter of the AIT controller. i_ref_clk must be a free-
running clock of low frequency so that the timeout count is sufficient for the entire
XLBIST test duration. i_ref_clk must be ratio synchronous to ait_clk.
Figure 19 AIT: Clocks

WRCK
AIT_CLK AIT
i_div_wrck
Clock divider
REF_CLK
The following are the resets used in the AIT controller:

• i_ait_rstn: Primary reset for the majority of logic in the AIT controller. This is an active-
low and asynchronous reset. i_ait_rstn must be de-asserted while ait_clk is not
running. Otherwise, unknown values might get created in the AIT logic.
• WRSTN: The IEEE 1500 reset that drives the logic controlled by the WRCK clock.
This is an active-low and asynchronous reset. This is the same reset that goes into the
server, AIT controller, and XLBIST IEEE 1500 logic. In manufacturing testing, this reset
clock comes from the TRSTN signal of the chip.

T-2022.03-SP3
Feedback
Test Start and End Sequences Using the AIT Pin Interface
Clock Stopping Requirements

The following are the clock stopping requirements for the AIT controller:
• i_ait_clk must be free running and only stopped through the SHS2AIT_CTRL register
for debugging.
• i_div_clk must be free running and only stopped through the SHS2AIT_CTRL register
for debugging.
• The AIT controller drives XLBIST when the AIT controller is in operational mode. The
AIT controller must stop both ate_clk and ait21500_wrck when they are not required.
• Both ate_clk and o_ait21500_wrck must be stopped when the AIT controller
encounters an abort or pause condition (i_abort =1), times out, or receives an incorrect
test initialization sequence.
• o_ait21500_wrck is driven directly by the AIT controller. The AIT controller stops
o_ait21500_wrck when necessary.
• ate_clk is not driven by the AIT controller. ate_clk is stopped using clock gating cells
(CGC) enable signal, o_xlbist_ateclk_stop.
Figure 20 Clock Stopping
ate_clk ate_clk
ate_clk
o_xlbist_ate o_xlbist_ate o_xlbist_ate
AIT SYNC CGC XLBIST
clk_stop clk_stop clk_stop
This topic describes the reset, start, and end sequences for the AIT-driven IEEE 1500 test
using the AIT controller pins. A fixed sequence of AIT pins is required to start and end
an AIT-driven test. This is to safeguard the AIT FSM from starting or ending accidentally
because of spurious bit flips on its inputs, which can occur because of ageing or random
events in the silicon.
Note:
After applying the resets (i_ait_rstn and WRSTN), the AIT controller is in pin
interface mode. In this mode, the IEEE 1500 interface is not active. After

T-2022.03-SP3
Feedback
programming the SHS2AIT_WIR register, the IEEE 1500 interface becomes

active.
The reset sequence is as follows:
1. Stop WRCK and apply WRSTN reset.
2. Start WRCK.
3. Stop all AIT clocks.
4. Assert ait_rstn = 0.
5. De-assert ait_rstn = 1.
6. Wait for a few cycles (based on the worst timing corner) to allow the reset de-assertion
to propagate throughout the AIT logic.
7. Start all AIT clocks. Let ait_clk run sufficiently (at least 10 cycles), which initializes all
flip-flops to the reset value.
Note:
For stopping the clocks while applying reset, you can alternatively add a reset
synchronizer. The clock fed to the reset synchronizer must be the slowest
among the AIT clocks. Also, ensure that all timing checks (recovery and
removal) are performed.
The following figure shows the reset sequence.
The test start sequence is as follows:

1. Until i_test_enable is applied, i_reset_counter must be 1. This ensures that
unnecessary timeout does not occur.
2. Assert i_test_enable = 1 and i_reset_counter = 0.
3. Wait for four ait_clk cycles.
4. Assert i_test_start = 1.
6. Hold i_test_enable = 1 and i_test_start = 1.
7. At the end of this sequence, the AIT controller is ready to accept data from memory.
8. Assert i_data_valid = 1. The AIT controller starts fetching data from the memory.

T-2022.03-SP3
Feedback
Test Start and End Sequences Using the AIT IEEE 1500 Interface
The following figure shows the test start sequence.
The test end sequence is as follows:

1. De-assert i_test_start = 0. i_test_enable is still high 1’b1.
3. De-assert i_test_enable = 0.
5. Hold i_test_enable = 0 and i_test_start = 0. At the end of the sequence, the AIT FSM
goes back to idle state.
The following figure shows the test end sequence.
This topic describes the reset, start, and end sequences for the AIT-driven IEEE 1500
test using the IEEE 1500 registers in the AIT controller. A fixed sequence of IEEE 1500
register programming is required to start and end an AIT-driven test. This is to safeguard
the AIT FSM from starting or ending accidentally because of spurious bit flips on its inputs,
which can occur because of ageing or random events in the silicon.
The following table lists the IEEE 1500 registers inside the AIT controller.
Table 4 AIT IEEE 1500 Registers
Register Width IR Value Write/Read
SHS2AIT_WIR reg 4 bit 4bit Write/read
SHS2AIT_BYP reg 1 bit 4’b0000 Write/read
SHS2AIT_CTRL reg N bits 4'b0001 Write/read

T-2022.03-SP3
Feedback
Table 4 AIT IEEE 1500 Registers (Continued)
Register Width IR Value Write/Read
WSO_COMPARE_STATUS reg MAX_COMP_CNT – 4'b0010 Write/read

Number of XLBIST
cores + 2
AIT2SHS_STATUS reg 8 bits 4'b0011 Write/read
BUSY_INSTR reg 1 bit 4'b0100 Write/read
SHS2AIT_DEBUG_DATA reg Size of memory word 4'b0101 Write/read
MEM_WRITE reg Width of memory 4'b0110 Write/read
MEM_READ_DATA Width of memory 4'b0111 Write/read
WSO_READ_BACK 32 bits 4'b1000 Write/read
SMART enable 1 bit 4'b1001 Write/read
AIT_MEM_MISR read 64 bits 4'b1010 Write/read
RING_STATUS Number of XLBIST 4’b1011 Write/read

rings
RING_STATUS_VALID Number of XLBIST 4’b1100 Write/read

rings
RING_<X>_STATUS Number of XLBIST 4’b1101 Write/read

cores in ring X
RING_<X>_STATUS_VALID Number of XLBIST 4’b1110 Write/read

cores in ring X
Note:
The number of RING_<X>_STATUS and RING_<X>_STATUS_VALID depends
on the number of XLBIST rings, based on which the width of the WIR varies.
The following tables provide detailed information about the IEEE 1500 registers.
Control Register Bit Function Usage
SHS2AIT_WIR Bit 0 IR_value[0] Wrapper instruction register

(WIR) for selecting the IEEE
1500 TDRs
Bit 1 IR_value[1]

T-2022.03-SP3
Feedback
Bit 2 IR_value[2]
Bit 3 IR_value[3]
SHS2AIT_BYPASS Bit 0 IEEE 1500 bypass Bypasses the AIT IEEE 1500
reg network with one pipeline depth
SHS2AIT_CTRL 0 Mode[0] AIT mode bit 0
1 Mode[1] AIT mode bit 1
2 Reset override TDR based AIT reset, 0 = reset

assertion, 1 = de-assertion
3 Clock gate enable TDR based AIT clock gating, 1 =

clock flowing, 0 = clock gated
4 Test_start Creates transitions on

test_enable/test_start and starts
test
5 unused Unused
6 AIT_Test_Mode_ove AIT_test_mode override for

rride debug
7 TDR select Used to select input from pins or

TDR bits.
8 Timeout count[0] Timeout count override. The

width is defined in the RTL using
9 Timeout count[1] the TIMEOUT_STRAP_WIDTH
parameter.
10 Timeout count[2]
... ...
(7+TIMEOUT_STRA Timeout count[n-1]

P_WIDTH)
(7+TIMEOUT_STRA SMART_enable Selects SMART mode

P_WIDTH+1)

T-2022.03-SP3
Feedback
(7+TIMEOUT_STRA Reset_counter Clears the timeout counter value

P_WIDTH+1+1)
(7+TIMEOUT_STRA Memory start addr[0] Memory start address from

P_WIDTH+1+1+1) where the AIT controller picks
up packets. The width is
... ... defined in the RTL using the
MEM_ADDR_WIDTH parameter.
MSB Memory start addr
[WIDTH]
AIT2SHS_STATUS 0 Status[0] AIT status output bit 0
1 Status[1] AIT status output bit 1
4 Unused Unused
5 Unused Unused
6 STATUS_FAIL STATUS pass/fail bit for the

overall status
7 STATUS_READY STATUS ready bit for the overall

status
RING_STATUS 0 Status of ring 1 1 = pass, 0 = fail

(Valid only in per
core status mode) 1 Status of ring 2 1 = pass, 0 = fail
... ... ...
N–1 Status of ring N 1 = pass, 0 = fail

(N = Number of
XLBIST rings)

T-2022.03-SP3
Feedback
RING_STATUS_VA 0 Status validity of ring RING_STATUS_VALID [0] = 1

LID 1 indicates that the status of ring 1
(Valid only in per is valid
core status mode)
1 Status validity of ring RING_STATUS_VALID [0] = 1
2 indicates that the status of ring 2
is valid
... ... ...
N–1 Status validity of ring RING_STATUS_VALID [0] = 1

N indicates that the status of ring
(N = Number of
XLBIST rings) N is valid
RING_<X>_STATUS 0 Status of core 1 in 1 = pass, 0 = fail

X = ring name Ring_X
Each ring has a 1 Status of core 2 in
status register (in per 1 = pass, 0 = fail
Ring_X
core status mode)
... ... ...
N-1 Status of core N in 1 = pass, 0 = fail

Ring_X
(N = Number of
cores in Ring_X)
RING_<X>_STATUS 0 wso_compare_interv Status of the first WSO

X = ring name al_status #1 comparison interval
Each ring has a 1 = pass, 0 = fail
status register (in per
pattern status mode) 1 wso_compare_interv Status of the second WSO
al_status #2 comparison interval
1 = pass, 0 = fail
... ... ...

T-2022.03-SP3
Feedback
N-1 wso_compare_interv Status of the Nth WSO

al_status #N comparison interval
(N = Number of
cores in Ring_X) 1 = pass, 0 = fail
RING_<X>_STATUS 0 Status validity of core RING_<X>_STATUS_VALID [0]

_VALID 1 in Ring_X = 1 indicates that the status of
X = ring name core 1 in Ring_X is valid
Each ring has a
status register (in per 1 Status validity of core RING_<X>_STATUS_VALID [0]
core status mode) 2 in Ring_X = 1 indicates that the status of
core 2 in Ring_X is valid
... ... ...
N-1 Status validity of core RING_<X>_STATUS_VALID [0]

(N = Number of N in Ring_X = 1 indicates that the status of
cores in Ring_X) core N in Ring_X is valid
The RING_<X>_STATUS_VALID register in per pattern status mode is not applicable.
WSO_COMPARE_S 0 wso_compare_interv If previous M WSO

TATUS (in per al_status #M+1 comparisons are logged into
interval/pattern RING_<X>_STATUS registers,
status mode) indicates the status of the M+1th
Width of the interval/pattern
register is 1 = pass and 0 = fail
MAX_COMPARE_V
ALUE +1. This 1 wso_compare_interv If previous M WSO
parameter is used for al_status #M+2
AIT RTL generation. comparisons are logged into
RING_<X>_STATUS registers,
indicates the status of the
M+2nd interval/pattern
1 = pass and 0 = fail
... ... ...
(MSB-2) wso_compare_interv Status of Nth WSO comparison

al_status #N interval
1 = pass and 0 = fail

T-2022.03-SP3
Feedback
(MSB-1) max_wso_compare_ Indicates whether the number

done of interval/pattern comparisons
exceeded the maximum number
(MAX_COMPARE_VALUE)
1 – Indicates that the number
of comparisons exceeded
MAX_COMPARE_VALUE
(parameter for AIT RTL
generation) or is equal to
MAX_COMPARE_VALUE.
0 – Indicates that the number of
comparisons have not reached
or exceeded the maximum
value.
MSB wso_compare_status Indicates whether

(MAX_COMPARE_V _ready wso_compare_status can be
ALUE+1) collected or not
1 – Collect status
0 – Do not collect status
WSO_COMPARE_S 0 N/A N/A

TATUS (in per
XLBIST core status ... ... ...
mode)
Width of the 5 N/A N/A
register is
MAX_COMPARE_V (MSB-2) N/A N/A
ALUE +1. This
parameter is used for (MSB-1) N/A Unused, value is 0
AIT RTL generation.
MSB wso_compare_status Indicates that
(MAX_COMPARE_V _ready wso_compare_status can be
collected
ALUE+1)
XLBIST_CORE_STA Bit 0 Indicates that XLBIST_CORE_STATUS_VALI

TUS_VALID wso_compare_status D[0] = 1 indicates that Core 1
[0] has a valid status. has a valid status, otherwise
Applicable only in per ignore the status of Core 1
XLBIST core mode.

T-2022.03-SP3
Feedback
Bit 1 Indicates that XLBIST_CORE_STATUS_VALI

wso_compare_status D[1] = 1 indicates that Core 2
XLBIST core mode.
Bit N Indicates that XLBIST_CORE_STATUS_VALI

(NUM_XLBIST_COR wso_compare_status D[1] = 1 indicates that Core
[N+1] has a valid (N+1) has a valid status,
ES-1)
status. Applicable otherwise ignore the status of
only in per XLBIST Core N+1
core mode.
WSO_READ back Bit 0 Bit 0 of XLBIST WSO WSO can be read from the AIT
data reg controller.
... …
Bit 31 Bit 31 of XLBIST

WSO
AIT_BUSY Bit 0 Indicates that the AIT The ATE polls this register
controller is busy and sends the next data if the
register is not set. If the register
is set (AIT is busy), the ATE
does not send data.
AIT_MEM_MISR Bit 0 Bit 0 of AIT_MEM Validate the memory content of

READ MISR content the AIT controller
... …
Bit 63 Bit 63 of AIT_MEM

MISR
Bit 64 MISR comparison

status is pass or fail

T-2022.03-SP3
Feedback
MEM_READ data Bit 0 Bit 0 of memory read Through the MEM_READ

reg data register, AIT data can be read
back
... …
Bit N = width of AIT Bit N of memory read

memory data
MEM_WRITE data Bit 0 Bit 0 of memory write Through the MEM_WRITE

reg data register, data can be written into
the AIT memory
... …
Bit N = width of the Bit N of memory write

AIT memory data
The reset sequence is as follows:

1. Stop WRCK and apply WRSTN reset.
2. Start WRCK.
3. Stop all AIT clocks.
4. Set the SHS2AIT_WIR register to 0001. This selects the SHS2AIT_CTRL register.
5. Set bit #7 of the SHS2AIT_CTRL register to 1. This selects the TDR as the source of
all inputs.
6. Set bit#2 to 0. This resets the AIT controller. Wait for a few cycles to allow the reset de-
assertion to propagate throughout the AIT logic.
7. Start all AIT clocks. Let the ait_clk run sufficiently (at least 10 cycles), which initializes
all flip-flops to the reset value.
The test start sequence is as follows:
all inputs.
3. Set bit #4 to 1. This starts the AIT FSM.

T-2022.03-SP3
Feedback
4. Set bit #3 to 1. This starts ait_clk. At the end of this sequence, the AIT FSM reaches
the start state.
5. Assert i_data_valid = 1. The AIT controller starts fetching data from the memory after
the FSM reaches the run state.
The following figure shows the test start sequence.
The test end sequence is as follows:

all inputs.
3. Set bit #4 of the SHS2AIT_CTRL register to 0. This ends the AIT operation and puts
the FSM back to idle state.
The following figure shows the test end sequence.
Note:
When the AIT controller uses the IEEE 1500 interface, the AIT controller applies
the reset sequence and test start sequence according to the AIT PDL.
The test sequences for multiple AIT sessions are as follows:
• Session 1
1. Apply the reset sequence to the AIT controller.
2. Apply the test start sequence. The AIT operation starts.
3. Collect the AIT status from the o_status port when the o_status_ready port is 1.
4. Collect the pass or fail status of the XLBIST core from the o_wso_compare_status
port when the o_wso_compare_status_ready port is 1.
5. Apply the test end sequence. The statuses of all registers are cleared.
When the AIT controller reaches the end sequence, the o_status port indicates
whether the test has passed or failed. After the end sequence, the AIT controller
stops fetching data from the memory and the o_mem_rd_addr port is not
incremented. All output ports hold the values until the ait_rstn signal or AIT exit
sequence is applied.

T-2022.03-SP3
Feedback
AIT Output Status Modes
• Session 2
1. Apply the i_reset_counter signal to the AIT controller. This clears the timeout
counter. The i_reset_counter signal must be synchronous with the i_ref_clk signal.
2. Apply the test start sequence and the new memory address through the
i_mem_start_addr port. The AIT controller starts fetching data from the
i_mem_start_addr port.
3. Collect the AIT status from the o_status port when the o_status_ready port is 1.
4. Collect pass or fail status of the XLBIST core from the o_ring_status,
o_ring_<x>_status, and o_wso_compare_status ports when the
o_wso_compare_status_ready port is 1.
5. Apply the test end sequence. The statuses of all registers are cleared.

The AIT controller has two output status modes:
• Per interval/pattern status: Each bit in the o_ring_<x>_status and
o_wso_compare_status ports indicates the pass or fail status of one interval or pattern.
Note:
o_ring_status, o_ring_status_valid, and o_ring_<x>_valid_status ports
are not valid in per pattern status mode. If there is an overflow in the
o_ring_<x>_status port, then the remaining status of patterns are logged in
the o_wso_compare_status port. x represents the ring name.
• Per XLBIST core status: Each bit in the o_ring_status port indicates the pass or
fail status of the XLBIST rings. Each bit in the o_ring_status_valid port indicates
the status validity of the corresponding bit in the o_ring_status port. Each bit in the
o_ring_<x>_status port indicates the pass or fail status of XLBIST cores in ring_x,
which is an XLBIST ring. Each bit in the o_ring_<x>_status port indicates the status
validity of the corresponding bit in the o_ring_<x>_status port.
Note:
The o_wso_compare_status port is not valid in the per XLBIST status mode.
The per XLBIST core status can be enabled using the AIT packets. These
packets are generated using the -per_core_xlbist_status on option with the
write_test_packets command. The default is off.
For example, there are five cores (A_c1, A_c2, A_c3, A_c4, A_c5) in ring A and each
core contains five intervals of XLBIST patterns. There are three cores (B_c1, B_c2,

T-2022.03-SP3
Feedback
B_C3) in ring B and each core contains seven intervals of XLBIST patterns. The
MAX_COMPARE_VALUE parameter value = (5 cores x 5 patterns + 3 cores x 7 patterns) = 46.
For ring A, the testing sequence is A_c1, A_c3, A_c2, and A_c5. A_c4 is not tested.
• A_c1 has three passing and two failing patterns (11100).
• A_c3 has all failing patterns (00000).
• A_c2 has all passing patterns (11111).
• A_c5 has all passing patterns (11111).
For ring B, the testing sequence is B_c2 followed by B_c3. B_c1 is not tested.
• B_c2 has six passing patterns and one failing pattern (1111110).
• B_c3 has all passing patterns (1111111).
The width of the status ports is as follows:
• o_ring_status = number of rings = 2
• o_ring_status_valid = number of rings = 2
• o_ring_A_status = number of XLBIST cores in ring A = 5
• o_ring_A_status_valid = number of XLBIST cores in ring A = 5
• o_ring_B_status = number of XLBIST cores in ring B = 3
• o_ring_B_status_valid = number of XLBIST cores in ring B = 3
• o_wso_compare_status = MAX_COMPARE_VALUE – (total number of XLBIST cores)
= 46 – (5+3) = 38
The status of the ports for per pattern mode is as follows:
• o_ring_status: N/A (reset condition or 0)
• o_ring_status_valid: N/A (reset condition or 0)
• o_ring_A_status: 11100 (A_c1)
• o_ring_A_status_valid: N/A (reset condition or 0)
• o_ring_B_status: 000 (For A_c3, the status of three patterns is logged in
o_ring_B_status and the remaining are logged in o_wso_compare_status because
o_ring_B_status overflows.)
• o_ring_B_status_valid: N/A (reset condition or 0)

T-2022.03-SP3
Feedback
Broadcasting the Test Content
• o_wso_compare_status:
B_c3 B_c2 A_c5 A_c2 A_c3
o_wso_compare_status 1111111 1111110 11111 11111 00
• Per pattern status (o_wso_compare_status, o_ring_B_status, and o_ring_A_satus

combined):
B_c3 B_c2 A_c5 A_c2 A_c3 A_c1
o_wso_compare_status, 1111111 1111110 11111 11111 00000 11100

o_ring_B_status, and
o_ring_A_satus
The status of the ports for per XLBIST mode is as follows:

• o_ring_status: 11
• o_ring_status_valid: 11
• o_ring_A_status: 10110
• o_ring_A_status_valid: 10111. This signature indicates that A_c4 is not run, A_c1 fails,
and the remaining cores pass.
• o_ring_B_status: 100
• o_ring_B_status_valid: 110. This signature indicates that B_c1 is not run, B_c2 fails,
and the remaining cores pass.
• o_wso_compare_status: N/A (reset condition or 0)
Note:
In the per XLBIST core mode, if the ported XLBIST PDL is a merged version
(multiple PDL files merged into one), then the MISR values are extracted
individually using the -misr_comparison individual option with the
set_dft_access_configuration command.
Broadcasting the Test Content

To broadcast the same test data across multiple XLBIST rings, the rings must be identical,
that is, the number and type of XLBIST cores in each ring must be the same. During
broadcasting, the AIT controller selects multiple XLBIST rings, for which broadcasting is

T-2022.03-SP3
Feedback
Generating AIT PDL
enabled, and programs all the corresponding XLBIST cores with the targeted core using
the same test data.
While the MISR UNLOAD command is executed, XLBIST rings are selected one by one to
shift the WSO data to the AIT controller. For example, XLBIST rings A and B are identical
and both the rings have four cores: A {A_c1 A_c2 A_c3 A_c4}, B {B_c1 B_c2 B_c3 B_c4}.
If broadcasting is enabled for rings A and B and the {A_c2, A_c3} cores are targeted, then
the same test data is used to program the corresponding cores in ring B, that is, {B_c2,
B_c3} at the same time.
Because the same test data is used to program multiple XLBIST cores at the same
time, both test time and test data are reduced by broadcasting. You can select multiple
groups of XLBIST rings for broadcasting. The write_test_packets command uses
the -broadcasting option to generate AIT packets in such a way that broadcasting is
supported for the given set of XLBIST rings.
For example, if there are four XLBIST rings (A, B, C, D), where A and B are identical and
C and D are identical, the command usage is as follows:
write_test_packets -broadcasting {A B} {C D}
Generating AIT PDL

You can generate different configurations of the AIT PDL by using the -active_cores
option with the set_dft_access_element command in the TestMAX Manager tool.
If you use the -active_cores option, the TestMAX Manager tool generates an AIT PDL
that contains XLBIST_CORE_STATUS_VALID and WSO_COMPARE_STATUS register
values. If you do not use the -active_cores option, the TestMAX Manager tool generates
an AIT PDL with only the WSO_COMPARE_STATUS register values.
Enabling IEEE 1500 Interface Only Mode

The AIT controller can be triggered through the pin interface or the IEEE 1500 (APB)
interface. By default, both interface ports are available.
To generate the AIT controller in IEEE 1500 interface mode, use the
ieee_1500_interface_only enable|disable command.
When you use the enable argument, the following AIT ports are not available:
• i_timeout_cnt_strap
• i_mode
• i_test_start

T-2022.03-SP3
Feedback
Memory Write Using AIT
• i_test_enable
• i_mem_start_addr
• i_reset_counter
In the AIT controller, IEEE 1500 override is available for these ports. The values of these
ports can be changed directly using the SHS2AIT_CTRL register.
Memory Write Using AIT

The AIT controller can write contents into the AIT memory using the AIT memory write
feature as shown in the following figure.
The AIT memory can be loaded using either the APB or IEEE 1500 interface. The
APB or IEEE 1500 interface applies the memory write sequence generated by the
write_test_model command to the AIT memory through the AIT controller. For more
information about the write_test_model command, see Using the write_test_model
Command.
To enable the memory write feature in the AIT controller, use the
set_dft_access_element -memory_write enable|disable command. By default, the
memory write feature is disabled.
Figure 21 Memory Write - AIT

TAP (1149.1)
Memory write path JTAG SMART APB
Server eFUSE (OTP)
IEEE 1500 ring IEEE 1500 ring IEEE 1500 ring
IEEE 1500 interface IEEE 1500 interface IEEE 1500 interface
Subserver Subserver Subserver

WSO_RING1
WSO_RING2
WSI_RING1
WSO_RING1
WSO_RING2
WSO_RING1
WSI_RING1
WSI_RING2
WSO_RING2
WSI_RING1
WSI_RING2
WSI_RING2
SHS2AIT SHS2AIT SHS2AIT

XLBIST XLBIST XLBIST
AIT core AIT core AIT core
AIT XLBIST AIT XLBIST AIT XLBIST

memory core memory core memory core

T-2022.03-SP3
Feedback
Generating AIT RTL
Generating AIT RTL

You can configure the AIT controller and change the parameters using the TestMAX
Access tool. In addition to the IEEE 1500 interface, the AIT controller has several
additional control signals that must be connected to the custom logic or PMU.
The functional connections are defined using the -interface option with the
set_dft_access_element command, as shown in the following example.
set_dft_configuration -dft_access enable
set_dft_access_element -type ait
-interface [list i_ait_clk TCK
i_ref_clk TCK
i_ait_rstn TRSTN
i_timeout_cnt_strap i_timeout_cnt_strap
i_mode i_mode
i_test_start i_test_start
i_test_enable i_test_enable
i_data_valid i_data_valid
i_abort i_abort
i_mem_start_addr i_mem_start_addr
i_div_wrck TCK
i_mem_data_in i_mem_data_in
o_mem_rd_enable o_mem_rd_enable
o_mem_addr o_mem_addr
i_reset_counter i_reset_counter
o_xlbist_ateclk_stop o_xlbist_ateclk_stop
i_ait_bypass_mode i_ait_bypass_mode
o_status o_status
o_status_ready o_status_ready
o_ring_status o_ring_status
o_ring_status_valid o_ring_status_valid
o_ring_<x>_status [list o_ring_<x>_status] // x - ring name
o_ring_<x>_status_valid [list o_ring_<x>_status_valid]
o_wso_compare_status o_wso_compare_status
o_wso_compare_status_ready o_wso_compare_status_ready
o_max_compare_wso_done o_max_compare_wso_done]
-parameter [list MEM_ADDR_WIDTH 16 MEM_DATA_WIDTH 64 \

TIMEOUT_STRAP_WIDTH 5 PROP_DLY_CNT_VAL 16 \
WRSTN_TOGGLE_PULSE_COUNT 7 MAX_COMPARE_VALUE 40]
-memory_write enable|disable
-ieee_1500_interface_only enable|disable
-ring_status_ports enable|disable
The first column of ports represents the actual ports of the AIT controller. The second
column of ports represents the ports in the design. The TestMAX Manager tool creates
connections between the first and second columns of ports. For the remaining ports of the
AIT IEEE 1500 interface, the Access tool creates connections.
You must connect the memory clocks to the same source pins as that of the ait_clk.

T-2022.03-SP3
Feedback
Generating AIT RTL
The -memory_write option enables or disables the memory write logic through the IEEE
1500 interface in the AIT controller. When the -ieee_1500_interface_only option
is enabled, the AIT controller can be triggered only through the IEEE 1500 interface.
It disables the input ports, i_timeout_cnt_strap, i_mode, i_test_start, i_test_enable,
i_mem_start_addr, and i_reset_counter. When this option is disabled (default), the AIT
controller can be triggered through both the pin and IEEE 1500 interface.
The -ring_status_ports option enables or disables the output status ports,
o_ring_status, o_ring_status_valid, o_ring_<x>_status, o_ring_<x>_status_valid, and
o_wso_compare_status. By disabling this option, the number of ports can be reduced.
Replacing the CGC or SYNC2P Logic
The generated AIT RTL has CGC and second stage synchronization cells (SYNC2P)
in the design. You can replace these cells with your CGC and SYNC2P cells. You can
identify CGC cells by the name, module_name_ClockGate in the AIT RTL. SYNC2P cells
can be identified by the name, module_name_sync2psync2p in the AIT RTL.
Table 5 AIT Parameters
Parameter Name Default Value Min Value Max Value Usage
MEM_DATA_WIDTH 64 8,16,32, and 8,16,32, and Memory data width

64 64
MEM_ADDR_WIDTH 16 8 64 Memory address width
TIMEOUT_STRAP_WI 4 4 8 Timeout counter width

DTH
PROP_DLY_CNT_VAL 10 10 255 Number of ait_clk cycles

required to ensure that all
inputs are stable
MAX_COMPARE_VA 10 # xlbist cores 65535 The maximum number

LUE of interval/pattern
comparisons that occurs
and the status log in
wso_compare_status.
Beyond this number, the
AIT controller does not
log status.
WRSTN_TOGGLE_PUL 5 5 7 Width of the

SE_COUNT o_ait2i1500_wrstn pulse
generated by AIT
RESET_WAIT_COUNT 10 9 15 Delay between reset and

test enable in SMART
mode

T-2022.03-SP3
Feedback
Using the write_test_packets Command

The write_test_packets command converts the XLBIST PDLs ported to the server or
subserver into AIT packets. The following script shows the command usage.
write_test_packets
-input "ported_PDLs_of_xlbist_to_server_or_subserver"
-output "AIT_MEM.txt"
-ait_ring_control on|off
-multiple_xlbist_rings on|off
-ams_mapping_file AMS_mapping_file_location
-ring_order "ring_name {1500 xlbist ring order}" \
-broadcasting “{set of identical XLBIST rings}
-exec_level server|subserver
-verbose on|off
-core_to_pdl_list "core_level_xlbist_PDLs"
-memory_data_width 8|16|32|64
-core_module_to_instances "core_module_name \
{repetitive instances of core_module_name}"
-max_wso_compares "maximum_number_of_comparisons"
-add_wrstn_pre_eot on|off
-wrstn_clockoff_margin "integer"
-single_eot on|off
-update_ait_pdl on|off
-ait_wait_cycle_margin "0.1_to_1.0"
-ait_pdl_path "AIT_PDL_location"
-per_core_xlbist_status on|off
-refresh_ait_pdl on|off
-stop_at_first_fail on|off
-wrong_packet_detection on|off
-misr_check on|off
-misr_mask_data "AIT_memory_MISR_mask_data"
-srv_sms_pipes "number_of_server_sms_pipelines"
-tap_srv_pipes "number_of_tap_server_pipelines"
You can use the following options with the write_test_packets command:
• -input: Input PDLs are XLBIST PDLs ported to the server or subserver, which
are converted into AIT packets. The write_test_packets command can accept
more than one PDL at a time and convert the PDLs into AIT packets. By default, the
conversion occurs in the order in which PDLs are given. The order can be changed
using the -test_order option.
Command usage:
write_test_packets -input \
"ported_PDLs_of_xlbist_to_server_or_subserver"

T-2022.03-SP3
Feedback
Example:
write_test_packets
-input "core1xlbist_portedtoserver.pdl"
-input "core1xlbist_portedtoserver.pdl core2xlbist_portedtoserver.pdl"
-input "core1xlbist_portedtosubserver.pdl \
core2xlbist_portedtosubserver.pdl"
• -output: AIT test data file, which contains the AIT packets.
Command usage: write_test_packets -output "file_name"

• -ait_ring_control: When set to on, the AIT controller controls a single or multiple
XLBIST rings using the output port, o_ring_sel. By enabling different bits in o_ring_sel,
the corresponding XLBIST ring is selected. When set to off, the AIT controller has no
control on the XLBIST rings. It implies that the AIT controller can have control on only a
single XLBIST ring at a time.
Command usage : write_test_packets -ait_ring_control on|off
• -multiple_xlbist_rings: Enable this option when multiple XLBIST rings are present
and the AIT controller has control over these rings.
Command usage: write_test_packets -multiple_xlbist_rings on|off
• -ams_mapping_file: Contains the information of XLBIST rings that are mapped to
the corresponding bits in the o_ring_sel output port of the AIT controller. The AMS
mapping file is required if the -ait_ring_control option is enabled to ensure proper
ring selection.
Command usage: write_test_packets -ams_mapping_file
AMS_mapping_file_path
The following table shows how the XLBIST rings are connected to the Access tool and
AIT controller.
Table 6 AIT and XLBIST Rings
Ring Type Number with respect XLBIST Ring Number

to the Access Tool Based on AIT
o_ring_sel
AIT AIT 1 N/A
Ring_A XLBIST 2 1
Ring_B XLBIST 3 2
Ring_C XLBIST 4 3

T-2022.03-SP3
Feedback
Ring Type Number with respect XLBIST Ring Number

to the Access Tool Based on AIT
o_ring_sel
Ring_D XLBIST 5 4
Ring_E XLBIST 6 5
• -ring_order: Indicates how IEEE 1500 rings are constructed (WSO to WSI) in the
SoC.
For example, if the IEEE 1500 ring_A contains 5 instances of core1 (m1_1, m1_2,
m1_3, m1_4, m1_5) and the IEEE 1500 ring_B contains 3 instances of core2 (m2_1,
m2_2, m2_3), the command usage is as follows:
write_test_packets -ring_order "ring_A {m1_1 m1_2 m1_3 m1_4 m1_5}
ring_B {m2_1 m2_2 m2_3}"
If the IEEE 1500 ring_A contains 2 instances of core1, 2 instances of core2, 2

instances of core3 and the IEEE 1500 ring_B contains 3 instances of core1, 2
instances of core2, 1 instance of core3, the command usage is as follows:
write_test_packets -chain_order "ring_A {m1_1 m1_2 m2_1 m2_2 m3_1
m3_2} ring_B {m1_3 m1_4 m1_5 m2_3 m2_4 m3_3}"
Note:
Use the -chain_order option when the -multiple_xlbist_rings option
is disabled.
• -broadcasting: Broadcasts the same test data across multiple XLBIST rings.
• -exec_level: Indicates the level (server or subserver) to which the XLBIST core PDLs
are ported.
Command usage: write_test_packets -exec_level server|sub_server
• -verbose: Provides additional information about the conversion process. The valid
arguments are on and off. The default is off.
Command usage: write_test_packets -verbose on|off
• -core_to_pdl_list: Inputs the PDLs of the XLBIST cores in the entire IEEE 1500
ring. The PDL list is given as a pair, {xlbist_core_module_name core_xlbist PDL
path}. If the same core is instantiated multiple times, you can give a single core name,
{core_module_name, PDL path}.
Command usage:
write_test_packets -core_to_pdl_list "core_level_xlbist_PDLs"

T-2022.03-SP3
Feedback
Example:
If the IEEE 1500 ring contains five instances of core1, five instances of core2, and five
instances of core3, use the following command:
write_test_packets -core_to_pdl_list m1 core1_xlbist.pdl m2
core2_xlbist.pdl m3 core3_xlbist.pdl …
• -chain_order: Indicates how the XLBIST IEEE 1500 ring is constructed (WSO to
WSI) in the SoC.
Command usage:
write_test_packets -chain_order "1500_xlbist_ring_order"
Example:
If the IEEE 1500 ring contains five instances of core1, five instances of core2, and five
write_test_packets -chain_oder "m1_1 m1_2 m1_3 m1_4 m1_5 m2_1 m2_2
m2_3 m2_4 m2_5 m3_1 m3_2 m3_3 m3_4 m3_5"
• -core_module_to_instances: Indicates if repetitive instances of cores are present in

the SoC.
Command usage:
write_test_packets -core_module_to_instances \
"core_module_name {repetitive instances of core_module_name}"
Example:
If the IEEE 1500 ring contains five instances of core1, five instances of core2, five
write_test_packets -core_module_to_instances "m1 {m1_1 m1_2 m1_3 m1_4
m1_5} m2 { m2_1 m2_2 m2_3 m2_4 m2_5} m3 {m3_1 m3_2 m3_3 m3_4 m3_5}"
• -memory_data_width: The memory width of RAM or ROM, which stores the AIT
content. The valid arguments are 8,16, 32, and 64.
Command usage: write_test_packets -memory_data_width 8|16|32|64
• -max_wso_compares: Gives the maximum number of WSO comparisons that
can occur inside the AIT controller without overwriting the WSO status. At the
time of AIT RTL generation, the MAX_COMPARE_VALUE parameter determines the
number of comparisons that can occur inside the AIT controller. If the number
of WSO comparisons exceeds the max_wso_compares parameter value, the
write_test_packets command issues a warning, but the comparison occurs.

T-2022.03-SP3
Feedback
Command usage:
write_test_packets -max_wso_compares \
"maximum_number_of_comparisons"
• -add_wrstn_pre_eot: Indicates that WRSTN must be toggled at the end of the AIT
test. This sets all IEEE 1500 registers of the XLBIST core to known values after the AIT
operation. The valid arguments are on and off. The default is off.
Command usage: write_test_packets -add_wrstn_pre_eot on|off
• -single_eot: Places one EOT packet for the entire AIT test data. After the AIT
controller executes the EOT packet, the AIT controller does not accept any new AIT
packet, and the output status can be read. The valid arguments are on and off. The
default is off. If you do not want to place single EOT, then write_test_packets
places one EOT for one input PDL.
Command usage: write_test_packets -single_eot on|off
• -wrstn_clockoff_margin: While applying asynchronous reset, it is safe to turn off
the clock for the logic. This is to ensure that there is no metastability in the design.
By default, the AIT RTL is developed considering metastability, that is, WRCK turns
off while applying WRSTN. The RTL provides a gap of four AIT clock cycles between
stopping, applying, and starting WRCK.
The following figure shows an example waveform.
You can use this option to add more gap of clock cycles between the WRCK and
WRSTN toggle. If you want a gap of six more cycles added to the default clock cycles
provided by the RTL, use the write_test_packets - wrstn_clockoff_margin 6
command. Extra packets are generated for introducing an extra gap between WRCK
and WRSTN.
• -per_core_xlbist_status: To generate AIT packets for per XLBIST core mode, the
-per_core_xlbist_status option must be on. If the -per_core_xlbist_status
option is off, AIT packets generated using the write_test_packets command are for
the per interval/pattern status mode. The default is off.
Command usage: write_test_packets -per_core_xlbist_status on|off
• -stop_at_first_fail: To give the fail status after the AIT controller encounters the
first WSO comparison fail, the -stop_at_first_fail option must be on. After the first
comparison fail, the AIT controller stops executing packets. The default is off.
Command usage: write_test_packets -per_core_xlbist_status on|off

T-2022.03-SP3
Feedback
• -wrong_packet_detection: If this option is on, the AIT controller identifies the invalid
AIT instructions and issues the BAD_AIT_INSTRUCTION_DETECTED status, that is,
4’b0111. The default is off.
Command usage: write_test_packets -wrong_packet_detection on|off
• -misr_check: Enables MISR check to validate the AIT memory content.
Command usage:
write_test_packets -misr_check on|off
• -misr_mask_data: 64-bit data used to mask the actual 64-bit MISR value.
Command usage: write_test_packets -misr_mask_data

"AIT_memory_MISR_mask_data"
• -srv_sms_pipes: Number of pipelines between the server and SMS. The tool uses
this number to generate the AIT packets from the ported PDL files.
Command usage:
write_test_packets -srv_sms_pipes "number_of_server_sms_pipelines"
• -tap_srv_pipes: Number of pipelines between the server and TAP. The tool uses this
number to generate the AIT packets from the ported PDL files.
Command usage:
write_test_packets -tap_srv_pipes "number_of_tap_server_pipelines"
write_test_packets Command Example

Two different cores {m1, m2}, each instantiated five times {m1_1, m1_2, m1_3, m1_4,
m1_5} {m2_1, m2_2, m2_3, m2_4, m2_5} in an SoC have PDL files at the server level.
The IEEE 1500 rings are connected in this order: m1_1, m1_2, m1_3, m1_4, m1_5, m2_1,
m2_2, m2_3, m2_4, and m2_5.
There are four IEEE 1500 rings, connected in the following order: Ring_A {m1_1, m1_2},
Ring_B {m1_3, m1_4}, Ring_C {m1_5}, and Ring_D {m2_1, m2_2, m2_3, m2_4, m2_5}.
Because the AIT controller has control over multiple XLBIST rings, you must provide the
AMS mapping file for proper ring selection. Enable broadcasting for Ring_A and Ring_B.
The number of tap_srv_pipes is 4 and number of srv_sms_pipes is 1.
Introduce six extra clock cycles gap between WRCK and WRSTN. The AIT RTL supports
100 WSO comparisons. The AIT test data for m2_5, m2_1, m2_3, m2_4, m2_1, m1_1,
m1_2, m1_3, m1_4, and m1_5 must be generated. The AIT test data must have only
one end-of-test (EOT) packet. To validate the memory content, the -misr_check option
is enabled. The 1, 3, 9, and 64 bits of the 64-bit MISR signature are masked. The

T-2022.03-SP3
Feedback
Updating the AIT PDL
AIT PDL is modified with the estimated wait time and expected status value using the
write_test_packets command.
The command usage for the example is as follows:

write_test_packets
-input "core1xlbist_portedtoserver.pdl \
core2xlbist_portedtoserver.pdl"
-output "ROM.txt"
-ait_ring_control on
-multiple_xlbist_rings on
-ams_mapping_file “./AMS_mapping”
-ring_order "Ring_A {m1_1 m1_2} Ring_B {m1_3 m1_4} Ring_C {m1_5} \
Ring_D {m2_1 m2_2 m2_3 m2_4 m2_5}"
-broadcasting "{Ring_A Ring_B}"
-exec_level server
-tap_srv_pipes “4”
-srv_sms_pipes “1”
-verbose on
-core_to_pdl_list "m1 core1_xlbist.pdl m2 core2_xlbist.pdl"
-memory_data_width 64
-core_module_to_instances "m1 { m1_1 m1_2 m1_3 m1_4 m1_5} m2 \
{ m2_1 m2_2 m2_3 m2_4 m2_5 }"
-max_wso_compares 100
-add_wrstn_pre_eot on
-single_eot on
-wrstn_clockoff_margin 6
-update_ait_pdl on
-ait_pdl_path "./AIT.pdl"
-ait_wait_cycle_margin 1.0
-per_core_xlbist_status off
-refresh_ait_pdl on
-stop_at_first_fail “off”
-wrong_packet_detection “on”
-misr_check “on”
-misr_mask_data “10000000_00000000_00000000_00000000_00000000_00000000_0
0000001_00000101"

To update the AIT PDL, see
• Updating AIT Wait Time
• Refreshing the AIT PDL

T-2022.03-SP3
Feedback
Updating AIT Wait Time

The TestMAX Manager tool generates the default AIT PDL (original AIT PDL) when the
generate_dft command is executed.
The AIT controller supports two versions of PDL. The TestMAX Manager tool outputs the
following PDLs:
• Per XLBIST core status PDL: PDL generated when the -active_cores option is used
with the set_dft_access_element command. This PDL contains the expected value
for comparing the status of each XLBIST core.
• Per interval/pattern status PDL: PDL generated for comparing each interval/pattern
when the -active_cores option is not used. This PDL contains the expected value for
comparing the status of each interval/pattern.
The following IEEE 1500 registers are present in the per interval/pattern and per XLBIST
core status AIT PDLs.
Table 7 IEEE 1500 Registers
IEEE 1500 Register Functionality in Per Functionality in Per XLBIST Core

Interval/Pattern Status PDL Status PDL
SHS2AIT_CTRL Initializes the AIT controller Initializes the AIT controller
AIT2SHS_STATUS Outputs status of the AIT controller Outputs status of the AIT controller
WSO_COMPARE_STA Indicates pass/fail status for each Indicates pass/fail status for the
TUS interval/pattern entire XLBIST core
XLBIST_CORE_STATUS N/A Indicates whether the XLBIST cores

_VALID are targeted or not for a given AIT
simulation
After applying the initialization sequence through the SHS2AIT_CTRL register, the AIT
controller starts fetching data from the memory and applies the data to the XLBIST cores
through the Access network. Then, the test status responses (pass or fail) are captured in
the AIT2SHS_STATUS register.
The AIT controller does not know when to collect the status. Therefore, after initialization
through the SHS2AIT_CTRL register, the AIT controller waits for some predetermined time
(Twait) before capturing the status responses into the AIT2SHS_STATUS register. Twait
varies from design to design. Therefore, the original AIT PDL must be corrected with this
Twait value. The write_test_packets command can be used to correct the Twait value.

T-2022.03-SP3
Feedback
To correct the AIT PDL with the correct Twait value, you can use the following options with
the write_test_packets command:
• -update_ait_pdl: If this option is on, the AIT PDL is modified with the correct Twait.
Command usage: write_test_packets -update_ait_pdl on|off

• -ait_pdl_path: Provides the path of the input or original AIT level PDL. After
modification, the input PDL is moved to *.pdl_bck and the input AIT PDL is updated.
Command usage: write_test_packets -ait_pdl_path "AIT_level_PDL_path"
• -ait_wait_cycle_margin: Gives the ratio between the shift packets and total
packets. This number is used for the calculation of AIT PDL wait time (Twait). # shift
packets / # total packets = ait_wait_cycle_margin. The valid arguments are 0.1, 0.2,
0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0. The default argument is 0.8. This
number can be an approximate.
Command usage:
write_test_packets -ait_wait_cycle_margin \
"ait_wait_cycle_margin"
Refreshing the AIT PDL

Each bit in the WSO_COMPARE_STATUS register indicates the pass or fail status
and the XLBIST_CORE_STATUS_VALID register indicates the targeted XLBIST cores.
These registers must be changed according to number of comparisons and XLBIST
cores. If these registers are not changed according to the AIT simulation or the memory
content, then fake fail simulations can occur. These registers can be modified using the
-refresh_ait_pdl option with the write_test_packets command.
To refresh the AIT core PDL, use the write_test_packets -refresh_ait_pdl on|off
command. If refresh_ait_pdl is on, the AIT PDL is modified.
The -refresh_ait_pdl option refreshes the AIT PDL (number of comparisons and
targeted cores for per XLBIST core status mode) according to the write_test_packets
output file. For operating the AIT controller in per XLBIST core mode, use the per XLBIST
core PDL with the write_test_packets command. For operating the AIT controller in
per interval/pattern mode, use the per interval/pattern PDL with the write_test_packets
command.

T-2022.03-SP3
Feedback
Table 8 Functionality of WSO_COMPARE_STATUS in Per Interval/Pattern Status Mode
WSO_COMPARE_S Bit 0 wso_compare_interv Status of the first interval/pattern

TATUS al_status of #1 1 = pass
0 = fail
... ... ...
MSB-2 wso_compare_interv Status of the Nth interval/pattern

al_status of #N 1 = pass
0 = fail
(MSB-1) max_wso_compare_ Indicates whether the number

done of interval/pattern comparisons
exceeded the maximum number
(MAX_COMPARE_VALUE).
1 – Indicates that the number
of comparisons exceeded the
MAX_COMPARE_VALUE
(parameter for AIT RTL
generation) or is equal to
MAX_COMPARE_VALUE
0 – Indicates that the number of
comparisons have not reached
or exceeded the maximum value
MSB wso_compare_status Indicates whether

_ready wso_compare_status can be
collected or not
1 – Collect status
0 – Do not collect status
Table 9 Functionality of XLBIST_CORE_STATUS_VALID in Per XLBIST Core Status

Mode
XLBIST_CORE_STA Bit 0 Indicates that XLBIST_CORE_STATUS_VALI

TUS_VALID wso_compare_status D[0] = 1 indicates that Core 1
XLBIST core mode.

T-2022.03-SP3
Feedback
Table 9 Functionality of XLBIST_CORE_STATUS_VALID in Per XLBIST Core Status

Mode (Continued)
Bit 1 Indicates that XLBIST_CORE_STATUS_VALI

wso_compare_status D[1] = 1 indicates that Core 2
XLBIST core mode.
Bit N Indicates that XLBIST_CORE_STATUS_VALI

wso_compare_status D[1] = 1 indicates that Core
[N+1] has a valid (N+1) has a valid status,
status. Applicable otherwise ignore the status of
only in per XLBIST Core N+1
core mode.
Table 10 Functionality of WSO_COMPARE_STATUS in Per XLBIST Core Status Mode
WSO_COMPARE_S Bit 0 wso_compare_interv Status of core 1, 1 = pass, 0 =

TATUS al_status of #1 fail
Bit 1 wso_compare_interv Status of core 2, 1 = pass, 0 =

al_status of #2 fail
MSB-2 wso_compare_interv Status of core N, 1 = pass, 0 =

al_status of #N-1 fail
MSB-1 No function Unused
MSB wso_compare_status Indicates that

_ready wso_compare_status can be
collected

T-2022.03-SP3
Feedback
Regenerating the AIT PDLs and Testbenches
Regenerating the AIT PDLs and Testbenches

To regenerate the AIT PDLs and testbenches, follow these steps:
1. Generate an SHS IEEE 1500 XLBIST ring using the generate_dft and connect_dft
commands in the TestMAX Manager tool.
2. Generate an original AIT PDL using the -active_cores option for per XLBIST status
PDL.
3. Port patterns using the port_patterns command. This converts the core-level XLBIST
or AIT PDL into server- or subserver-level PDL.
4. Use the write_test_packets command to convert the ported XLBIST PDL into AIT
packets and then refresh the original AIT PDL.
5. Read the refreshed AIT PDL into the TestMAX Manager tool using the
read_test_model command.
6. Regenerate and port the AIT PDLs and testbenches.
Using the write_test_model Command

The write_test_model command converts the AIT memory packets generated into PDL
according to the user-defined arguments using the write_test_packets command. The
following example shows the command usage.
write_test_model
-memory read | write | read_write
-start_address "memory_start_addresses_in_integer"
-input_memory "location_of_AIT_content_generated_by_write_test_packet"
-format pdl
-output "name_of_output_PDL"
-test_mode ait
The write_test_model command can generate three types of PDL:

• write mode PDL: The write_test_model command takes AIT packets generated
using the write_test_packets command and converts them into AIT memory write
sequence (in PDL form). Using the AIT memory write sequence, the AIT controller
loads the AIT memory through the IEEE 1500 or APB interface.
• read mode PDL: The write_test_model command takes AIT packets generated using
write_test_packets and converts them into AIT memory read sequence (in PDL

T-2022.03-SP3
Feedback
form). Using the AIT memory read sequence, contents of the AIT memory can be read
through the IEEE 1500 or APB interface.
• read_write PDL: read_write generates the write sequence followed by the read
sequence. Using the read_write sequence, you can validate the AIT to memory path
and the read/write logic of the AIT controller.
You can use the following options with the write_test_model command:
• -memory: The PDL sequences can be generated using this option.
Command usage: write_test_model -memory read|write|read_write

• -start_address: The AIT controller can read/write content from the memory. The start
address is provided while generating the read/write sequence. write_test_model
generates read/write sequence from a given start address. If start address is
not provided, by default start is 0. The value of start address must be less than
(memory_address_width) – 1
2 .
Command usage:
write_test_model -start_address \
"memory_start_addresses_in_integer"
• -input_memory: The location of the AIT packets, which is generated by the

write_test_packets command. The write_test_model command converts the AIT
packets into read, write, or read/write sequence.
Command usage:
write_test_model -input_memory \
"location_of_AIT_content_generated_by_write_test_packet"
• -output: Output PDL to which the read, write, or read/write PDL sequence is written
to.
Command usage: write_test_model -output "name_of_output_PDL".
The following flowchart shows how the write_test_model command functions in the
TestMAX Manager tool.

T-2022.03-SP3
Feedback
Figure 22 write_test_model Command in TestMAX Manager

Enable AIT with memory write capability
set_dft_access_element -type AIT
Generate AIT RTL with memory write functionality and ports

generate_dft
Connect AIT to the write interface of the memory

connect_dft
Convert the RTL-level XLBIST PDLs into AIT packets and generate
memory content
write_test_packets (RTL level)
Generate testbench based on RTL-level AIT PDL and run simulation for the
Server+AIT+XLBIST system
validate_dft -verify_access_system (RTL level)
Convert XLBIST PDLs from netlists into AIT packets

and refresh the original AIT PDL
write_test_packets (Gate level)
AIT memory read refreshed PDL
AIT memory write_test_model

packets memory_write, memory_read, or memory_read_write
AIT memory write PDL
Generate either a memory write or a memory write/read PDL for verification
AIT memory read PDL or memory write PDL
Read AIT PDL into TestMAX Mananger for testbench generation

read_test_model
Generate testbench based on either the refreshed AIT PDL

or the AIT memory write PDL (netlist level)
Run simulation for the Server+AIT+XLBIST system
validate_dft -verify_access_system (Gate level)

T-2022.03-SP3
Feedback
5
Advanced Peripheral Bus Support
When Advance Peripheral Bus (APB) is enabled in AIT using the TestMAX Manager tool,
you must generate and validate the APB hardware, testbench, and firmware code or
sequence.
To generate and validate the APB hardware and other required components, see
• APB and Other Protocols
• Generating APB Using TestMAX Manager
• APB Components
• Server With APB Interface
APB and Other Protocols

APB is a part of the Advanced Microcontroller Bus Architecture (AMBA) protocol family. It
defines low-cost interface that is optimized for minimal power consumption and reduced
interface complexity. APB is not pipelined and can be used to connect to low-bandwidth
peripherals that do not require the high performance of the Advanced eXtensible Interface
(AXI) protocol.
AMBA supports high-bandwidth external memory, on-chip memory, CPU, and direct
memory access (DMA) devices. AMBA provides a high-bandwidth interface between the
elements that are involved in the majority of data transfers and acts as a bridge to the
lower bandwidth APB.
APB provides the basic peripheral macro cell communication infrastructure as a secondary
bus from the higher bandwidth pipelined main system bus. APB consists of interfaces that
are memory mapped registers. APB is mainly used for connecting to simple peripherals
and enabling massive memory I/O access.

T-2022.03-SP3
Feedback
Chapter 5: Advanced Peripheral Bus Support
Figure 23 AMBA Architecture
High-performance High-bandwidth
ARM processor on-chip RAM
AHB to APB or ASB to APB

UART Timer
High-bandwidth AHB or ASB APB

external memory
interface
bridge
Keypad PIO
DMA bus master
Advanced High-Performance Bus (AHB) is used to address the requirements of high-

performance synthesizable designs. AHB supports high clock frequency systems such
as burst transfer, split transactions, single cycle bus master handover, single clock edge
operation, and wider data bus configuration such as 64 bits, 128 bits, and so on. This bus
uses full-duplex parallel communication.
Advanced System Bus (ASB) supports efficient connection of processors, on-chip
memories, and off-chip external memory interfaces with low-power peripheral macro cell
functions. This bus also provides access infrastructure for modular macro cell test and
diagnosis.
Figure 24 AHB to APB Interface

PSEL1
System bus
AHB PSEL2
slave interface
Selects
PSELn
PENABLE
Strobe
APB bridge
Read data PRDATA
PADDR
Address and
control
PWRITE
Reset
Clock PWDATA
Write data

T-2022.03-SP3
Feedback
Figure 25 Interfacing of APB Bridge (Master) and APB Slave

PSEL1
System bus PSEL2

AHB
slave interface
PSELn
PENABLE
APB master PADDR APB slave PRDATA

PRDATA
PWRITE
PWDATA
PRESETn
PREADY
PCLK PSLVERR
Note:
APB slave is the hardware inserted by the TestMAX Manager tool when APB is
enabled in the AIT controller. This hardware component is known as the APB
driver. The APB driver has only one PSEL enable.
Note:
The APB bridge or master is the hardware that is added to the SoC and
controlled using the system bus interface. The APB bridge or master hardware
is not discussed in detail in this document.
Table 11 APB Signals
Signal Direction Description
PCLK Input APB data transfer occurs at the rising edge of PCLK.
PRESETn Input System bus equivalent reset. The APB reset is active
low.
PADDR Input Single bit address line.
PSEL Input Slave device is selected, and a data transfer is

required.
PENABLE Input Indicates the second and subsequent cycles of the

APB transfer.
PWRITE Input Indicates write when high and read when low.
PWDATA Input 32-bit wide write data bus.
PREADY Output Ready to perform an APB transfer.

T-2022.03-SP3
Feedback
Generating APB Using TestMAX Manager
Table 11 APB Signals (Continued)
Signal Direction Description
PRDATA Output 32-bit wide read data bus.
PSLAVEERR Output Slave error. This signal indicates a transfer failure.
Generating APB Using TestMAX Manager

The TestMAX Manager tool allows you to access the BIST controllers (logic BIST and
memory BIST) and test them independently using the APB interface during in-system
testing.
To generate the APB hardware, you can use the following commands in both the TestMAX
SMS and TestMAX Access tools:
• To enable the default APB hardware, use the set_dft_access_element -type
top_server -parameter [system_interface_type 2] command.
• To enable the APB hardware with parity protection, use the set_dft_access_element
-type top_server -parameter [parity_enable 1] command. Parity protection for
APB hardware is enabled only when the system_interface_type parameter is set to
2.
APB Components
To learn more about the APB components, see
• APB Interface Driver
• APB Data Decoding
• APB to IEEE 1500 Data Converter
• APB Parity Protection

T-2022.03-SP3
Feedback
APB Components
APB Interface Driver

The following figure shows the APB interface driver with the SHS network.
Figure 26 APB Driver Interface With the SHS Network

JTAG TAP
Instruction AMBA_APB
captureDR APB interface
SMSGr_SEL
TCK shiftDR driver
TDO TDI RST_N updateDR SPIF TAP APB_1500
converter (FSM)
MUX spif_mode
Pipe 1
Pipe n
SMART pins Select

WSOR
Ring bypass pins
Server eFUSE
Other pins
IEEE 1500 rings
1 i j
Core 0 Subserver eFUSE

Core 0 IEEE 1500 rings
1 n
Core 0
Core m Core 0
Core k
APB Data Decoding

The APB driver consists of two registers for data decoding, which are addressed as
WORD0 and WORD1 (32-bit each). WORD0 is the configuration register and WORD1 is
the data register. The server can be accessed through these APB registers.
The width of the address bus, PADDR is 1 bit. 0 selects the WORD0 and 1 selects
WORD1. If the system APB uses PADDR for addressing data, then PADDR[2] must be

T-2022.03-SP3
Feedback
APB Components
connected to the PADDR signal of the server through the APB bridge and PADDR[1:0]
must be ignored.
Figure 27 APB Driver Registers

Configuration or header register
WORD0 [31:25] reserved [24] [23:0] WIR/WDR chain size
SMS GR access
Write/read data register

WORD1 [31:0] Data to/from server
The configuration register is used to pass the information about the size of the chain,
which is accessed in the next transaction. The read/write data register is used to transfer
data to and from the server using the APB PWDATA and PRDATA buses.
APB to IEEE 1500 Data Converter

The APB interface driver has the APB-to-1500 converter that bridges between the 32-bit
APB parallel data and the IEEE 1500 serial data. The APB driver generates the IEEE 1500
control signals for the server.
APB Parity Protection

APB parity protection adds the parity circuitry (even parity) for the PWDATA, PRDATA, and
PADDR data or address buses.
When the parity_enable server parameter is set to true,
• Extra 4 bits (P3-P0) are added to the 32-bit data buses containing parity information,
and an extra bit is added to PADDR.
• Dual-rail signaling is used for the APB control and status signals: PSEL, PENABLE,
PWRITE, PSLVERR, and PREADY.
• Dual-rail signals have only 2’b01 or 2’b10 as valid states: 2b’01 = LOW, 2b’10 = HIGH.
If there is an error in data or address parity, PSLVERR indicates the transfer failure.

T-2022.03-SP3
Feedback
APB Components
The following figures show the input and output parity.
Figure 28 Input Parity (PWDATA)

35 32 31 0
P3 P2 P1 P0 Byte 3 Byte 2 Byte 1 Byte 0
parity_in
Byte 3
P3
Byte 2
P2 input_parity_fail
Byte 1
P1
Byte 0
P0

T-2022.03-SP3
Feedback
APB Components
Figure 29 Output Parity (PRDATA)

35 32 31 0
P3 P2 P1 P0 Byte 3 Byte 2 Byte 1 Byte 0
parity_out
Byte 3 P3
Byte 2 P2
Byte 1 P1
Byte 0 P0
The following figure shows the functioning of the APB driver.
Figure 30 APB Driver

APB write data bus APB control bus APB read data bus
APB control
(FSM)
Write register Read register
Parallel2Serial Server control Serial2Parallel

converter (FSM) converter
WSI select_ipc_wir smsg_data

capture_dr
shift_dr

T-2022.03-SP3
Feedback
Server With APB Interface

After defining the user interface, the TestMAX Manager tool generates the required
APB hardware components along with the server hardware. The APB driver, APB21500
converter, and MUX logic are added in the server. The tool performs all required
connections automatically.
The following figure is a high-level representation of the server hardware along with the
APB interface.
Figure 31 Server Hardware With APB Interface

Ring N
SMSN SMSN+1
SMS1
JTAG TAP Ring 1
model
Repairable Repairable
memory memory
STAR
JPC_SFP
Non-repairable Non-repairable
SP_TAP memory memory
Ring N+M
AMS WrapperM AMS Wrapper1+j

APB driver
Ring N+1
AMS Wrapper1
Server
IP block
eFUSE

T-2022.03-SP3
Feedback
The following figure shows the pin diagram of the server with the APB interface.
Figure 32 Server With APB Interface -– Pin Diagram

PCLK
PADDR
APB interface
PSEL
PREADY
PENABLE
PSLERR
PWRITE
PRDATA[31:0]
PWDATA[31:0]
Server
SPIF_MODE
SYS_RST_N
TRSTN
TAP interface
TMS
TDO
TCK
TDI

T-2022.03-SP3
Feedback
6
Automotive Flow
This topic describes the automotive flow using the TestMAX Access tool. The difference
between the generic flow described in the preceding topics and the automotive flow is
generating the AIT controller, creating AIT packets, and validating the packets.
At the subsystem and SoC levels, the Access tool uses the components generated at
the core level. Depending on the configuration, you can insert the AIT controller at the
subsystem or SoC level. At the subsystem level, use the set_dft_access_element
-type sub-server command, and at the SoC level, use the set_dft_access_element
-type server command.

T-2022.03-SP3
Feedback
Chapter 6: Automotive Flow
Synopsys Automotive DFT Solution
Synopsys Automotive DFT Solution

The following figure shows the Synopsys automotive DFT solution.
Figure 33 Synopsys Automotive DFT Solution

SoC
TAP
AIT
SMART APB
eFUSE
Server
1500 ring 1
1687 ring 4
1500 ring 5
SMART
SMART
Ring 3
Subserver Subserver
AIT 1500 AIT
Third-party
wrapped IP IP1
Core1
1500
XLBIST SMS SMS XLBIST
wrapped IP
Core1 Core2 Core1
1500
XLBIST SMS
wrapped IP
Core2 Core3

T-2022.03-SP3
Feedback
SoC-Level Design Implementation Flow

This topic describes only the SoC flow. The subsystem flow is similar to the SoC flow. The
following figure shows the SoC-level view of the TestMAX Access tool.
Figure 34 SoC-Level View

TAP
AIT
Server
Subsystem1 Subsystem2 Core with XLBIST

(Test model) (Test model) (Test model)
The following figure shows the SoC-level design implementation flow.

T-2022.03-SP3
Feedback
Figure 35 SoC-Level Implementation Flow

Set up DFT
open_lib, analyze, elaborate, set_top
Read RTL design, NDMs for memories and standard cells, stub models for
subsystems, and test models for cores
Analyze, elaborate, and link the design
Configure DFT
read_test_model,set_dft_configuration,
set_dft_access_element, set_bsd_configuration
Read ICL/PDL that contains interface connectivity, ports, and patterns information
Define the top server, TAP controller, access elements, and ring architectures
Plan DFT
plan_dft
Generate ISH and RCL files
Perform RTL link checks using TestMAX Advisor and generate STAR Integrator
components
Generate DFT
generate_dft
Connect DFT
connect_dft
Modify the RTL design to instantiate the generated DFT IP and make the
Validate DFT
validate_dft
Perform connectivity checks on the modified RTL design using TestMAX Advisor
Write output files

Save protocol, test models, DFT constraints, ICL, PDL ... files

T-2022.03-SP3
Feedback
The following are the steps involved in the SoC-level design implementation:
1. Set up DFT.
To set up the design, use the following commands:
lappend search_path ./mylibdir
open_lib ./tpzn65lpgv2lt.nlib
analyze -f sverilog [glob RTL/*] -f sverilog -vcs "-f sources.f"
elaborate $design
set_top_module $design
2. Configure DFT.
To enable the DFT components, use the following commands:
-bsd enable
-dft_access enable
-ieee_1500 enable
-mbist enable
To configure BSD, use the following commands:

set_bsd_configuration -ir_width 4
set_dft_signal
-type tdi -port TDI -view spec
-type tdo -port TDO -view spec
-type tck -port TCK -timing [list 45 55] -view spec
-type tms -port TMS -view spec
-type trst -port TRSTN
set_bsd_instruction SMS_SEL -code 1000 -register SERVER1 -length 1
set_app_options -as_user_default -name \
dft.testmax_force_tlib_file_generation -value true
setenv test_enable_BModel true
3. Plan DFT.
To read the compiler library and generate the STAR Integrator files, use the following
command:
plan_dft
The plan_dft command generates the following output:

AIT Configuration
-------------------------------------------
MEM_DATA_WIDTH: 32
MEM_ADDR_WIDTH: 16
PROP_DLY_CNT_WIDTH: 5
PROP_DLY_CNT_VAL: 16
WRSTN_TOGGLE_PULSE_COUNT: 7
RESET_WAIT_COUNT: 10
TIMEOUT_STRAP_WIDTH: 5

T-2022.03-SP3
Feedback
NUM_XLBIST_CORES: 3
MAX_COMPARE_VALUE: 50
WSO_COMPARE_COUNTER_WIDTH: 6
Information: AIT IP Name: 'SOC_DFTTopIP_1'
Information: ICL file 'SOC_AIT.icl' generated successfully.
Information: PDL file 'SOC_AIT.pdl' generated successfully.
Information: Populating setup information.
Information: STAR Planner config file not set. Creating planner
config file
****************************************
Information: Generating design lib
file ./sms_plan_dft_gate_design.tlib
Information: Successfully created planner config file
'sms_plan_dft_planner_config.tcl'
Invoking STAR Planner...
Information: STAR Planner run started
Information: Read compiler library... done
Information: Generating integrator shell script... done
Information: STAR Planner run completed successfully
Information: Integrator Config File set to : scripts/SOC_prj.ish
Use command
'set_mbist_configuration/set_dft_access_configuration
-integrator_config' to change.
Generating report file...
Information: Report generation successful. Please check
"preview_dft.rpt" file for more details
The TestMAX Manager tool uses the test models (ICL and PDL) to generate a MASIS
model for the IEEE 1500- or IEEE 1687-wrapped IP blocks. The MASIS model contains
information about interface connectivity, ports, and test patterns.
read_test_model
/work_dir/des_unit_core_1687.icl -format icl -design des_unit_core
/work_dir/des_unit_core_1687.pdl -format pdl -design des_unit_core
4. Generate DFT.
To generate the DFT IP Verilog files and constraints, use the following command:
generate_dft
The generate_dft command generates the following output:

Client Status
--------- ---------
Scan Disable
Wrapper Disable
Logicbist Enable
Mbist Disable
Dft Access Enable
Scan_compression Disable
Pipeline_scan_data Disable
Clock_controller Disable

T-2022.03-SP3
Feedback
ieee_1500 Disable
Bsd Enable
Hsio Disable
Invoking STAR Integrator...
Information: STAR Integrator run started
Information: Read files... done
Information: Running "Generate" on component "des_unit_3"
Information: Running "Generate" on component "wrap_SOC_DFTTopIP_1_1"
Information: Running "Generate" on component "wrap_des_unit_1_1"
Information: Running "Generate" on component "srv_1"
Warning: [create_test_protocol] command was not run. (DFT-2906)
IEEE 1149 TAP Ports:
U_TDI_pad/C -> bsd_inst_0/TDI
bsd_inst_0/TDO -> U_TDO_pad/I
bsd_inst_0/TDO_EN -> U_TDO_pad/OEN
5. Connect DFT.
To modify the RTL design by instantiating the generated DFT IP blocks and making the
required connections, use the following command:
connect_dft
The modified RTL design files are written into ./output/Verilog. The connect_dft
command generates the following output:
RTL modifier run started
Information: RTL modifier design read complete.
Information: DFT IP instantiation complete.
Information: MBIST DFT IPs read complete.
Information: MBIST DFT IPs instantiation complete.
Information: Connections for MBIST DFT IPs complete.
Information: RTL modifier run completed successfully.
Information: Modified RTL with DFT IP generated
at /<work_dir>/TestMAX/output/Verilog directory.
RTL modifier Log
Directory: /work_dir/TestMAX/rtl_modifier_log/
RTL modifier
LogFile : /work_dir/TestMAX/rtl_modifier_log/gensys.log
Invoking STAR Builder to update side files...
6. Validate DFT.
To check the connectivity between the DFT IP blocks in the modified RTL design, use
the following command:
validate_dft -check connectivity

T-2022.03-SP3
Feedback
The validate_dft -check connectivity command generates the following output:

/$/spyglass -project spg_validate_dft_config.prj -goal dft_shell_goal
-batch
'BSD_TDI' group connection validation started...
'1' check(s) passed
'0' check(s) failed
'BSD_TDI' group connection validation completed
'BSD_TDO' group connection validation started...
'1' check(s) passed
'0' check(s) failed
---------------------------------------------------------------------
---
Results Summary:
---------------------------------------------------------------------
---
: 0
flip-flops : 55
Total sequential reconvergent paths to asynchronous pins of
flip-flops : 15
---------------------------------------------------------------------
---
7. Write output files.

To port the core-level XLBIST patterns to SoC-level PDL patterns, use the following
command:
port_patterns -access_interface ieee1149.1 -pdl on
The port_patterns command generates the following output:

port_patterns -access_interface ieee1149.1 -format pdl
Information: No masis files directory specified. Generating masis
files from the provided testmodels in 'masis_files' directory.
Use option '-masis_dir' to specify masis files
directory.
Information: Masis file generated successfully for 'SOC_AIT.icl' and
'SOC_AIT.pdl' testmodels.
Information: Masis file generated successfully for
'/core_work_dir/patterns/des_unit_1687.icl' and
'/core_work_dir/patterns/des_unit_1687.pdl' testmodels.

T-2022.03-SP3
Feedback

'/core_work_dir/patterns/des_unit_1687.pdl' testmodels.
'/core_work_dir/CORE_3/patterns/des_unit_1687.pdl' testmodels.
Information: Yield Accelerator run successfully.
Please check logs file
'ya_pdl_jtag_1/logs/ya_pdl_jtag_1.0.log' for more information.
To convert the XLBIST PDL patterns to AIT packets, use the following command:
write_test_packets
The write_test_packets command generates the following output:

source write_test_packet
*I: Packets will be generated in order of specified input PDLs as
sequence for core test is not specified
Args passed are:-
inputs :
ya_pdl_jtag/patterns/wrap_des_unit_1_1_2_pattern_1/wrap_des_unit_1_1_
2_pattern_1.pdl ya_pdl_jtag/patterns/
wrap_des_unit_2_1_3_pattern_1/wrap_des_unit_2_1_3_pattern_1.pdl
ya_pdl_jtag/patterns/wrap_des_unit_3_1_4_pattern_1/wrap_des_unit_3_1_
4_pattern_1.pdl
output file : output_individual.txt
Memory Data Width : 32
Core module to PDL List :
- des_unit_2 -> ../../CORE_2/patterns/des_unit_1687.pdl
Ring Order : core1 core2 core3
Level : server
Verbose : 1
Core module to instances:-
- des_unit_2 -> core2
Core Test Order :
One Shot : 1
Max WSO Compares : 50
WRSTN before EOT : 1
WRSTN Clock Off margin : 0
Update AIT PDL : 1
AIT PDL Path : ./SOC_AIT.pdl
AIT wait cycle margin : 0.8
XLBIST Status per core : 1
Active XLBIST Cores :
Refresh AIT PDL : 1
Memory Interface Check : 0
Stop At First Fail : 0
Wrong Packet Detection : 1

T-2022.03-SP3
Feedback
MISR Check : 1
MISR Mask Data :
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000
000
Server SMS Pipes : 0
TAP Server Pipes : 0
Before exiting the tool, write out the following files:

◦ IEEE1450.1 STIL protocol files
◦ IEEE1450.6 CTL test model
◦ IEEE1687 ICL and PDL files
◦ Constraint files for connecting XLBIST cores to scan chains in the Design Compiler
or Fusion Compiler tool
◦ SDC constraints for the PrimeTime tool and synthesis constraints for the Design
Compiler tool
◦ Constraint files for formal verification using the Formality tool
To write out test protocol files, use the following command:
write_test_protocol
-out ${design}.soc_top_sccomp.spf -test_mode {soc_top_sccomp}
-out ${design}.soc_top_scan.spf -test_mode {soc_top_scan}
-out ${design}.soc_core_sccomp.spf -test_mode {soc_core_sccomp}
-out ${design}.soc_core_scan.spf -test_mode {soc_core_scan}
-out ${design}.soc_core_wrp_if.spf -test_mode {soc_core_wrp_if}
To write out the test model, use the following command:

write_test_model -out ../outputs/${design}.ctl
To write out DFT constraints, use the following command:

-output ${design}_dft_constraints_shift
-test_mode defined -mode shift -occ active
-output ${design}_dft_constraints_capture
-test_mode defined -mode capture -occ active
-output {design}_dft_constraints_any
-test_mode defined -mode any -occ active

T-2022.03-SP3
Feedback
7
TestMAX Access IEEE 1687
The TestMAX Access IEEE 1687 feature provides access to IPs embedded in a design.
The architectural complexity of chips increases with advancement in technology. The
interoperability between multiple IPs can be managed by standard protocols such as
IEEE1149.1, IEEE 1500, and IEEE 1687. The main components of the IEEE 1687
standard are the test data register (TDR) and segment insertion bits (SIBs).
The following figure shows an example of the IEEE 1687 network. The network is
programmed to the required state through the IEEE 1687 interface, also called as the
client interface. The interface can be controlled using the IEEE 1149.1 signals. An IP or a
target instrument can be controlled through the host interface of the network.
Figure 36 TestMAX Access IEEE 1687 Interface
The IEEE 1687 standard also defines the instrument connectivity language (ICL) to
describe the connectivity of the TDR and SIB elements of the network. The procedural
description language (PDL) based protocols define the patterns that configure the IEEE
1687 network by programming the TDR and SIB elements.

T-2022.03-SP3
Feedback
Chapter 7: TestMAX Access IEEE 1687
IEEE 1687 at the Core Level
The following are the major IEEE 1687 features supported by the TestMAX Manager tool:
• Scan control at different levels
• Third-party IP integration

You can generate the RTL IP of the TDR and get the required files at the core level. For
more information, see Configuring DFT: Core Level.
Figure 37 IEEE 1687 at the Core Level
Generating TDR: Core Level

A core that uses scan-based test engines can have multiple modes. An IEEE 1687-
wrapped core uses a TDR to control the test mode bits. The configuration of the core
wrapper chain depends on the selection of the test mode. For more information about test
modes, see the define_test_mode man page.

T-2022.03-SP3
Feedback
The TestMAX Manager tool allows you to control the test mode bits and any other DFT
signal through an IEEE 1687 compliant TDR. The tool also observes and controls custom
pins in the design through the TDR.
You can enable the IEEE 1687 feature in the TestMAX Manager tool using the
set_dft_configuration -ieee_1687 enable command.
You can configure the IEEE 1687 pin interface, TDR length, and SIBs using the
set_dft_signal, set_scan_path, and set_dft_ring commands.
Generating ICL and PDL Patterns: Core Level

The TestMAX Manager tool can generate wrapper-, register-, and IEEE 1687-based TDRs
and SIBs at the RTL level. The tool generates the ICL description of the TDR and SIBs. At
the core level, ICL is created for the core module.
As the TDR is used for test mode control, it must be programmed to a different value to set
the core to a specific test mode. The patterns or values to be set in the TDR are described
in the PDL file. The TestMAX Manager tool can generate a PDL pattern file per mode. The
generated ICL and PDL files at the core level can be integrated and ported to higher levels
in the hierarchical design.
To generate the ICL and PDL files of the configured IEEE 1687 network, use the
write_test_model command.
Generating Test Patterns: Core Level

The test patterns at the core level are generated using the TestMAX ATPG tool. The core
for which test patterns are generated is initialized at the appropriate stage by providing
an input sequence called the test_setup, included in the SPF file. The test_setup
of the SPF test protocol generated by the TestMAX Manager tool includes the required
input sequence to program the TDR to control the test mode. The TestMAX Manager tool
generates the test_setup for test modes in the SPF file format.
To generate the SPF file per mode, use the write_test_protocol command. The core
does not have an Access component such as the top server or shadow server. Therefore,
a PDL is not required for SPF generation.
Configuring DFT: Core Level

To configure DFT at the block level, use the following commands.
#Enable ieee 1687 client
set_dft_configuration -ieee_1687 enable
#Define 1687 interface signals

T-2022.03-SP3
Feedback
IEEE 1687 at the Subsystem Level
set_dft_signal -view spec -type iTDI -port iTdi

set_dft_signal -view spec -type iTDO -port iTdo
set_dft_signal -view spec -type iTCK -port iTck
set_dft_signal -view spec -type iTRST -port iTrstn
set_dft_signal -view spec -type iCaptureEn -port iCaptureEn
set_dft_signal -view spec -type iShiftEn -port iShiftEn
set_dft_signal -view spec -type iUpdateEn -port iUpdateEn
set_dft_signal -view spec -type iSelect -port iSelect
#Configure TDR
set_scan_path TDR -class ieee_1687 -exact_length 10 -init_data 0000000000
-reset_state 0000000000
set_dft_ring RING -class ieee_1687 -ordered_elements {TDR} -sib enable
#TDR pin usage
set_dft_signal -type TestMode -tdr_pin TDR[0]
set_dft_signal -type TestMode -tdr_pin TDR[1] -usage occ
set_dft_signal -type TestControl -tdr_pin TDR[2] -connect_top
{inst/pin}
#Generate IP and connect

generate_dft
connect_dft
#Write ICL/PDL and SPF

write_test_model -format icl -output DFTcore.icl
write_test_model -format pdl -output DFTcore_mode1.pdl -test_mode
{mode1}
write_test_model -format pdl -output DFTcore_mode2.pdl -test_mode
{mode2}
write_test_protocol -test_mode mode1 -output DFTcore_mode1.spf
write_test_protocol -test_mode mode2 -output DFTcore_mode2.spf

The TestMAX Manager tool supports the IEEE 1687 feature for hierarchical designs with
or without core instantiation and glue logic. For more information, see Configuring DFT:
Subsystem Level.

T-2022.03-SP3
Feedback
Figure 38 IEEE1687 at the Subsystem Level
Generating TDR: Subsystem Level

At the subsystem level, the TestMAX Manager tool can generate the scan DFT engines
and scan fabric to configure the modes in the subsystem level. The tool uses the IEEE
1687 TDR to control test mode pins at the subsystem level. You can configure the IEEE
1687 pin interface, TDR length, and SIBs using the set_dft_signal, set_scan_path,
and set_dft_ring commands.
Generating ICL and PDL Patterns: Subsystem Level

To generate the ICL and PDL files for the IEEE 1687 TDR generated at the subsystem
level of the network, use the write_test_model command.
To generate ICL for the subsystem level including the hierarchical blocks, use the
write_test_model command with the -test_mode option set to shadow_server. The
subsystem-level ICL includes connections of integrated blocks and module definitions. To
generate the SoC-level ICL, the subsystem-level ICL must be ported to the SoC level.
Generating Test Patterns: Subsystem Level

The SPF for test modes defined at higher levels must contain the test_setup for the
subsystem level of TDR with the cores integrated in the TestMAX Access network. The
TestMAX Manager tool generates the test_setup for all IPs connected in the TestMAX
Access network using the ported test_setup.
At the subsystem level, use the PDL file because an Access component such as the
shadow server is used to connect lower-level blocks to the design. To generate PDL
patterns for a subsystem level TDR in the design, use the -target option with the
write_test_protocol command.

T-2022.03-SP3
Feedback
Integration to the Access Network

To integrate the IEEE 1687 IP to the TestMAX Access network, at the subsystem level,
you must use the shadow server. The necessary files for the TestMAX Access network
are generated in the form of WKS or ICT. To specify the ICL/MASIS models of cores or
WKS/ICL models of the hierarchical TestMAX Access network, use the read_test_model
command.
The lower-level IEEE 1687 cores and subsystem-level TDR can be configured as IPs in
a single or multiple IEEE 1687 rings. For more information, see Configuring the Access
Network.
Configuring DFT: Subsystem Level

To configure DFT at the subsystem level, use the following commands.
#Enable 1687 client
set_dft_configuration -ieee_1687 enable
#Define 1687 interface signals

set_dft_signal -view spec -type iTDI -port iTdi
set_dft_signal -view spec -type iTDO -port iTdo
set_dft_signal -view spec -type iTCK -port iTck
set_dft_signal -view spec -type iTRST -port iTrstn
set_dft_signal -view spec -type iCaptureEn -port iCaptureEn
set_dft_signal -view spec -type iShiftEn -port iShiftEn
set_dft_signal -view spec -type iUpdateEn -port iUpdateEn
set_dft_signal -view spec -type iSelect -port iSelect
#Configure TDR
#TDR pin usage

{inst/pin}
#intergration of TMM processed DFT cores or 3rd party cores with shadow
server
read_test_model core.masis -format masis -design core -type unwrapped
-class ieee1687
read_test_model DFTcore.icl -format icl -design DFTcore -type wrapped
-class ieee1687
read_test_model DFTcore_mode1.pdl -format pdl -design DFTcore
set_dft_access_element -type shadow_server
set_dft_access_configuration -compiler_libraries "embedit_compilers"
set_dft_access_configuration -project_name subsystem_prj

T-2022.03-SP3
Feedback
IEEE 1687 at the SoC Level
#Generate and connect

plan_dft
generate_dft
connect_dft

write_test_model -format icl -output DFTsubsystem.icl
write_test_model -format pdl -output DFTsubsystem_model1.pdl -test_mode
{mode1}
write_test_model -format pdl -output DFTsubsystem_model2.pdl -test_mode
{mode2}
write_test_protocol -output DFTsubsystem_model.spf
-test_mode {model} \
-target { {core_inst pattern1} \
{DFTcore_inst DFTcore_mode1.pdl} \
{DFTsubsystem DFTsubsystem_mode1.pdl} }
write_test_protocol -output DFTsubsystem_mode2.spf
-test_mode {mode2} \
-target { {core_inst pattern2} \
{DFTcore_inst DFTcore_mode2.pdl} \
{DFTsubsystem DFTsubsystem_mode2.pdl} }

The TestMAX Manager tool supports the IEEE 1687 feature with IEEE1149 TAP control
with or without core instantiation and glue logic. For more information, see Configuring
DFT: SoC Level.
Figure 39 IEEE 1687 at the SoC Level

T-2022.03-SP3
Feedback
Generating TDR: SoC Level

At the SoC level, the TestMAX Manager tool can generate the scan DFT engines and
scan fabric to configure the test modes. The tool uses the IEEE 1687 TDR to control
test mode pins at the SoC level. You can configure the TDR length and SIBs using the
set_scan_path and set_dft_ring commands. At the SoC level, the IEEE 1687 interface
specification is not required because the test access is through the IEEE1149 TAP
interface.
Generating ICL and PDL Patterns: SoC Level

To generate the ICL and PDL files for the IEEE 1687 TDR generated at the SoC level of
the network, use the write_test_model command.
Generating Test Patterns: SoC Level

To generate the SPF file per mode, use the -target option and the PDL files with the
write_test_protocol command. For more information, see Configuring DFT: SoC Level.
Integrating the IEEE 1687 IP to the Access Network With TAP

At the SoC level, the IEEE 1687 network can be driven using the IEEE1149 TAP. To
integrate the IEEE 1687 IP to the TestMAX Access network, read the WKS database and
ICL description at the lower levels using the read_test_model command. You must insert
the top server at the SoC level. To configure IPs in multiple rings, use the set_dft_ring
command.
Configuring DFT: SoC Level

To configure DFT at the SoC levels, use the following commands.
#Enable 1687 client
set_dft_configuration -ieee_1687 enable -bsd enable
#Define 1149 interface signals and instructions

set_dft_signal -view exist -type Tdi -port TDI
set_dft_signal -view exist -type Tdo -port TDO
set_dft_signal -view exist -type Tck -port TCK
set_dft_signal -view exist -type Tms -port TMS
set_dft_signal -view exist -type Trst -port TRSTN
set_bsd_instruction SMS_SEL -code 1101 -register SERVER
#Configure TDR

T-2022.03-SP3
Feedback
#TDR pin usage

{inst/pin}
#Integrate TestMAX Manager processed modules or 3rd party modules with

the top server
read_test_model core.masis -format masis -design core -type unwrapped
-class ieee1687
read_test_model DFTsubsystem_srv_1.ict.zip -format ict -design
DFTsubsystem
read_test_model DFTsubsystem.wks -format wks -design DFTsubsystem
set_dft_access_element -type shadow_server
set_dft_access_configuration -compiler_libraries "embedit_compilers"
set_dft_access_configuration -project_name soc_prj
set_dft_access_element -type top_server -module my_srv
-server_select_instruction SMS_SEL
#Generate and connect

plan_dft
generate_dft
connect_dft

read_test_model DFTcore.icl -format icl -design DFTcore -type wrapped
-class ieee1687
read_test_model DFTsubsystem.icl -format icl -design DFTsubsystem -type
wrapped -class ieee1687
write_test_model -format icl -output DFTSoC.icl
write_test_model -format pdl -output DFTSoC_model1.pdl -test_mode {mode1}
write_test_model -format pdl -output DFTSoC_model2.pdl -test_mode {mode2}
write_test_protocol -output DFTSoC_model.spf
-test_mode {model} \
-target {{subsystem_inst.core_inst core.pdl} \
{subsystem_inst.DFTcore_inst DFTcore_mode1.pdl} \
{subsystem_inst.- DFTsubsystem_model1.pdl} \
{core_inst pattern1} \
{SoC DFTSoC_model1.pdl} }
write_test_protocol -output DFTSoC_mode2.spf
-test_mode {mode2} \
-target {{subsystem_inst.core_inst core.pdl} \
{subsystem_inst.DFTcore_inst DFTcore_mode2.pdl} \
{subsystem_inst.- DFTsubsystem_model2.pdl} \
{core_inst pattern2} \
{SoC DFTSoC_model2.pdl} }

T-2022.03-SP3
Feedback
Configuring the Access Network
Configuring the Access Network

This topic describes how the TestMAX Manager tool is used to integrate and setup IPs
connected to the TestMAX Access network.
The TestMAX Manager tool allows you to access the IPs of a hierarchical system
using the SHS-based TestMAX Access network. The following figure shows one of
the configurations of the TestMAX Access network with the IEEE 1687 IP integrated in
different levels of the design.
Figure 40 TestMAX Access Network Configuration: IEEE 1687-Only Network
Integrating IPs
The TestMAX Manager tool allows you to access the IEEE 1687- and IEEE 1500-
wrapped or unwrapped IPs at any level through the TestMAX Access network. The IPs
are connected to the server (for flat designs) or shadow server/subserver (for hierarchical
designs).
The TestMAX Access network uses the description of the IEEE 1687 or IEEE 1500
interface through the IEEE 1687 standard ICL (or MASIS models) for integrating the cores

T-2022.03-SP3
Feedback
IEEE 1687 Support With TestMAX SMS
instantiated at any level. To specify the ICL/MASIS model of the cores or WKS/ICL model
of the hierarchical TestMAX Access network, use the read_test_model command.
Based on the level, a TestMAX Access component is inserted to control the rings. At the
SoC level, a server must be added for ring selection control. The TestMAX Manager tool
allows you to insert a single server or separate servers to control SMS and SHS rings. At
the subsystem level, a subserver or shadow server is required. Insertion of a TestMAX
Access component generates the components connection database in WKS and ICT
formats. To read the generated data at the lower levels and build the Access network
further, use the read_test_model command.
Access Network Ring Configurations

The TestMAX Manager tool allows you to define the rings in the network using a variable
number of IPs per ring. The rings must be defined homogeneously, that is, all the cores in
a ring must be of the same standard interface. IEEE 1500- and IEEE 1687-compliant IPs
cannot be part of the same ring.
To define the ring configuration, use the set_dft_ring command. If the IP instance is not
specified using the set_dft_ring command, it is generated as part of the default ring.
To review the ring configuration at a specific level, use report_dft_ring command. To
report the ring names in hierarchical designs, use the -hier option with this command.
For more information, see the man pages.
Access Network Configuration: Example Usage

To read lower-level Access network information, use the following commands:
read_test_model lower_module.ict.zip -format ict -design lower_module
read_test_model lower_module.wks -format wks -design lower_module
To preview lower-level ring information, use the following command:

report_dft_ring -hier
To configure the Access rings at a specific level, use the following command:
set_dft_ring ring_name -class IEEE_1687 -ordered_elements {instance_1
instance_2}

The TestMAX Manager tool supports the IEEE 1687 network only for the SMS or SMS
with scan flow. For the Access flow, IEEE 1687 TDR bits can be used for DFT mode (DM)
control. For the SMS with scan flow, you can configure the Access network using separate
servers or a single server.

T-2022.03-SP3
Feedback
To learn more about the IEEE 1687 support with the TestMAX SMS tool, see:
• DFT Mode Control in SMS Using IEEE 1687
• DFT Mode Control in SMS Using IEEE 1687: Example
• Configuring Access Network for SMS Using Separate Servers
• Configuring Access Network for SMS Using Separate Servers: Example
• Configuring Access Network for SMS Using a Single Server
• Configuring Access Network for SMS Using a Single Server: Example
DFT Mode Control in SMS Using IEEE 1687

The IEEE 1687 feature of the TestMAX Access tool can also be extended to control DM
pins of the TestMAX SMS IP (MBIST). By default, DM pins are propagated to the module
boundary. To restrict the propagation and make connection to the IEEE1687 TDR pins,
use the set_mbist_configuration command. The TDR bits used for DM control can be
specified using the set_dft_signal -usage sms_dm command.
The IEEE 1687 feature allows you to control DM pins with TDR at the same level of SMS
processors or higher. To identify DM pins of SMS processors of lower-level modules, read
the XML data using the read_test_model command. The XML data is created by default
after you exit the TestMAX Manager tool without errors.
DFT Mode Control in SMS Using IEEE 1687: Example

The following example shows how DM pins can be controlled using IEEE 1687 in the
TestMAX SMS IP.
#Limit the propagation of DM pins to the module boundary
set_mbist_configuration -setup_options [list
extract_rcl.limited_test_pin_propagation true
\
extract_rcl.connect_dm_to_tdr 1]
#Read the DM information of lower hierarchy (if propagated to the lower

module boundary)
read_test_model design_name_db.xml -format dft_db -design design_name
#Specify TDR bits to be used for DM control

set_dft_signal -type TestControl -tdr_pin TDR[0:5] -usage sms_dm

T-2022.03-SP3
Feedback
Configuring Access Network for SMS Using Separate Servers

At the SoC or top level, you can use two separate servers (TOP SERVER and RING SEL)
to control the SMS components and scan network. For this, follow these steps:
1. Insert the TAP and servers.
◦ Generate the top server RTL by integrating the SMS components to it.
◦ Configure the IEEE 1149.1 TAP with two instructions to control the servers. These
instructions are connected to each of the servers.
2. Configure the existing TAP and connect the servers.
◦ Generate separate servers with the hierarchical blocks and IEEE 1687 TDR bits
required for scan configuration.
◦ Configure the existing server instruction using the set_scan_path and
set_bsd_instruction commands with the -view option set to exist.
The following figure shows the Access network configuration for separate servers.
Figure 41 Access Network Configuration for Separate Servers
Configuring Access Network for SMS Using Separate Servers:

Example
The following example scripts show how separate servers are used to configure the
Access network.
Step 1: Insert the TAP and Servers
#Define instructions for two servers
set_bsd_instruction SMS_SEL -code 1000 -register SERVER1

T-2022.03-SP3
Feedback
set_bsd_instruction ACCESS_SEL -code 1100 -register SERVER2
#Configure server 1 with instruction

set_dft_access_element -type top_server -module my_srv_1
-server_select_instruction SMS_SEL
Step 2: Configure the Existing TAP and Connect the Servers

#Define existing server instruction
set_scan_path SERVER2 -class bsd -view exist -include {U_DFTBsdIP}
set_bsd_instruction ACCESS_SEL -code 1100 -register SERVER2 -view exist
#Configure server 2 with instruction

-server_select_instruction ACCESS_SEL
Configuring Access Network for SMS Using a Single Server

At the SoC or top level, you can use a single server (SERVER + RING SEL) to control the
SMS components and scan network. For this, follow these steps:
1. Insert the TAP and server.
◦ Insert the server, TAP, and SMS components.
◦ Generate the top-level TDR needed for scan control.
2. Configure the existing TAP and connect the server.
◦ Configure the TAP, server, and TDR using the set_scan_path command with the
-view option set to exist.
◦ To generate the test setup, after the connect_dft step, enable the -dft_access
option and read the Access (SHS) database.
The following figure shows the Access network configuration for a single server.

T-2022.03-SP3
Feedback
Figure 42 Access Network Configuration for a Single Server
Configuring Access Network for SMS Using a Single Server:

Example
The following example scripts show how a single server is used to configure the Access
network.
Step 1: Insert the TAP and Server
#Define server instruction
set_bsd_instruction SEL -code 1000 -register SERVER1
#Configure server with instruction

-server_select_instruction SEL
Step 2: Configure the Existing TAP and Connect the Server

#Define existing server instruction
set_scan_path SERVER1 -class bsd -view exist -include {U_DFTBsdIP}
#Configure server with instruction

-server_select_instruction SEL

T-2022.03-SP3

Accessug

Uploaded by

Copyright:

Available Formats

Accessug

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Accessug

Uploaded by

Copyright:

Available Formats

Synopsys TestMAX™ Access User

Synopsys TestMAX™ Access User Guide 2

1. Understanding TestMAX Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Working With TestMAX Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3. TestMAX Access Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Checking DFT at the Core Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Enabling IEEE 1500 Interface Only Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5. Advanced Peripheral Bus Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6. Automotive Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7. TestMAX Access IEEE 1687 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Generating Test Patterns: Subsystem Level . . . . . . . . . . . . . . . . . . . . . . . . . . 126

About This User Guide

Related Products, Publications, and Trademarks

Synopsys TestMAX™ Access User Guide 7

Courier Indicates syntax, such as write_file.

Courier italic Indicates a user-defined value in syntax, such as

Purple • Within an example, indicates information of special interest.

[] Denotes optional arguments in syntax, such as

... Indicates that arguments can be repeated as many times as

| Indicates a choice among alternatives, such as

\ Indicates a continuation of a command line.

/ Indicates levels of directory structure.

Bold Indicates a graphical user interface (GUI) element that has an

Synopsys TestMAX™ Access User Guide 8

Ctrl+C Indicates a keyboard combination, such as holding down the Ctrl

Contacting Customer Support

Synopsys TestMAX™ Access User Guide 9

Synopsys TestMAX™ Access User Guide 10

◦ Recognizes existing IEEE-compliant IP

Synopsys TestMAX™ Access User Guide 11

TestMAX Access Network Architecture

Synopsys TestMAX™ Access User Guide 12

Figure 1 TestMAX Access Network Without a Subserver

Subsystem1 Subsystem2 Subsystem3

Synopsys TestMAX™ Access User Guide 13

Figure 2 TestMAX Access Network With a Subserver

Subsystem1 Subsystem2 Subsystem3

The TestMAX Access tool

Synopsys TestMAX™ Access User Guide 14

• Provides compliance with the SystemVerilog IEEE 1800-2009 standard

TestMAX Access Network Architecture Types

Synopsys TestMAX™ Access User Guide 15

Figure 3 Star Architecture

SHS STAR SHS

Figure 4 Ring Architecture

Synopsys TestMAX™ Access User Guide 16

Figure 5 Hierarchical Architecture

SHS SHS SHS SHS SHS

SHS Server Architecture

Synopsys TestMAX™ Access User Guide 17

Figure 6 Access Server and Interfaces

eFUSE SFP JPC

Synopsys TestMAX™ Access User Guide 18

The following figure shows the server hierarchy.

Figure 7 Server Hierarchy

IEEE 1500 rings

Subserver eFUSE eFUSE

Core Core Core Core

Core Core Core Core Core