Synopsys Testmax™ Sms User Guide: Version T-2022.03-Sp3, July 2022

Synopsys TestMAX™ SMS 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™ SMS User Guide 2

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

TestMAX SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
TestMAX SMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
TestMAX SMS Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2. TestMAX SMS Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

TestMAX SMS Architecture With TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
TestMAX SMS Subsystem Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
SRAM Wrapper Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
ROM Wrapper Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Wrapped and Unwrapped Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Processor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
SMS Network Architecture Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Star Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Ring Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Hierarchical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
SMS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
3. Working With TestMAX SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Configuring TestMAX SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Using the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Defining the Search Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Setting Up Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Setting Up Binary Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3
Feedback
Contents
4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
5. Flow for Flat Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Flow Diagram for Flat Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Setting Up Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Reading the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Defining Memory Functional Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Enabling the BIST Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Configuring BIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Configuring the DFT Access Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Generating the Memory Grouping Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Generating the SMS (BIST) Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Connecting the SMS Components to the RTL Design . . . . . . . . . . . . . . . . . . . . . . . 60
Writing the TestMAX SMS DFT Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Writing the TestMAX SMS DFT Constraints for the Current Level . . . . . . . . . . . . . . 61
Validating the SMS Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Verifying the SMS-Generated Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Simulating the BIST System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Example Script: Overall Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6. Flow for Hierarchical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Hierarchical Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Enabling the Hierarchical Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Configuring BIST in the Hierarchical Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Reading Lower-Level SMS-Generated Components . . . . . . . . . . . . . . . . . . . . . . . . 70
Hierarchical Flow With Subserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Hierarchical Flow With Server and TAP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Enabling the TAP IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Hierarchical Flow With Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7. Custom BIST Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

FSM-Based BIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
4
Feedback
Contents
BIST Controller Hardware Components and Programmable Sources . . . . . . . . . . . 77

Test Algorithm Selection Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Hardwired Test Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Test Algorithm Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Test String Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Programmability Execution Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Running BIST With a Hardwired Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Running BIST With Multiple Algorithms in TAR . . . . . . . . . . . . . . . . . . . . . . . . . 80
Running BIST With a User-Defined March Element . . . . . . . . . . . . . . . . . . . . . 80
Customizing BIST Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Enabling the Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Customizing Hardwired and Soft Programmable Test Algorithms . . . . . . . . . . . 82
Generating Test Algorithm Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Predefined Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Generating Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Deleting Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Validating Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Test Algorithm Programmability: Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
8. BIST Production Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

Generating BIST Patterns Using STAR Yield Accelerator . . . . . . . . . . . . . . . . . . . . 88
TestMAX Manager Support for BIST Pattern Generation . . . . . . . . . . . . . . . . . . . . . 89
Predefined Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Creating BIST Production Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Creating Predefined Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Other Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Predefined Patterns: Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
9. Customizing BIST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Clocking Architecture: Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
IEEE 1500 Clock: WRCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Customizing Reset Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
Customizing SMS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Customizing the Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Customizing Pipeline Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5
Feedback
Contents
Configuring Wrappers Using the DFT Operations File . . . . . . . . . . . . . . . . . . . . . . 106

Customizing DFT Mode Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Defining the IEEE 1500 Interface at the Shadow Server or Subserver Level . . . . . 111
Disabling Propagation of Memory Functional Ports and Processor Control
Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Custom Memory Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A. Debugging Clock 29 Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B. Content-Addressable Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

TCAM Support in SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Challenges of TCAM BIST Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
C. Memory Grouping Using a Custom CSV File . . . . . . . . . . . . . . . . . . . . . . . . . . .120
6
Feedback
About This User Guide

The TestMAX SMS User Guide describes the high-level architecture, methodology flow,
and commands used for integrating TestMAX SMS components (BIST IP) into the RTL
design.
This document is intended for design engineers experienced in testability concepts and
for test and DFT engineers who want to understand how to integrate the TestMAX SMS IP
into the RTL design.
This preface includes the following topics:
• Related Products, Publications, and Trademarks
• Conventions
• Customer Support
Related Products, Publications, and Trademarks

For additional information about the TestMAX SMS 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 Access
• TestMAX Advisor
®
• Formality
®
• VCS
• Embed-It! STAR Integrator
• Embed-It! STAR Planner
• Embed-It! STAR Builder
• Embed-It! STAR Verifier
• STAR Yield Accelerator

T-2022.03-SP3
Feedback
Conventions
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.
Ctrl+C Indicates a keyboard combination, such as holding down the Ctrl

key and pressing C.
Customer Support
Customer support is available through SolvNetPlus.

T-2022.03-SP3
Feedback
Customer Support
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 SMS
This topic introduces the TestMAX SMS tool, describes the high-level SMS architecture
and integration of SMS components (BIST IP) into the RTL design, and provides the
license requirements for the tool.
The TestMAX SMS tool, built on the DesignWare STAR memory system (SMS), enables
testing memories of different configurations using the IEEE 1500 network. The TestMAX
SMS tool helps in generating custom memory built-in self-test (BIST) hardware with self-
repair capability and BIST production patterns with diagnostic capability. The SMS tool
runs on the TestMAX Manager platform that provides a common interface for TestMAX
DFT implementation capabilities.
To learn the basics of the TestMAX SMS tool, see
• TestMAX SMS
• TestMAX SMS Architecture
• TestMAX SMS Design Flow
• Licensing
TestMAX SMS
This topic describes the features of the TestMAX SMS tool.
The TestMAX SMS tool is a comprehensive and integrated test, repair, and diagnostics
solution that supports repairable and non-repairable embedded memories across
foundries, process nodes, and memory IP vendors. The automated design implementation
and diagnostic flow enables SoC designers to achieve quick design closure and improve
time-to-market and time-to-yield.
The TestMAX SMS tool provides
• Full RTL integration with the TestMAX Manager tool
• Hierarchical architecture and automated SoC integration and verification

T-2022.03-SP3
Feedback
Chapter 1: Understanding TestMAX SMS
TestMAX SMS Architecture
• Key components for embedded memory test and repair such as server, subserver,
processor, and wrapper, and then connects these components to the RTL design or
gates
• High-quality test with full memory defect coverage and minimal test time
• Rapid, cost-effective, and accurate identification, analysis, isolation, and classification
of memory faults when designs are readied for the transition from silicon to
manufacturing
• Automatic generation of test vectors for fault analysis and root cause failure guidance
based on the silicon test results
• SMS DFT constraints (synthesis, timing, and Formality), which can be used in the
downstream design process
• Test algorithm programmability, where you can either program the custom algorithm or
select from the list of algorithms in the library
• The built-in repair and redundancy allocation (BIRA) module, which identifies
redundant elements and determines the best redundancy configuration
• The built-in diagnosis module, which determines the location of memory defects and
provides error logging by scanning out the failure data for silicon debug
• Silicon bring-up and characterization by interactive communication with the SMS
infrastructure through the JTAG port
• High yield with efficient on-chip repair across multiple operating corners
• Superior diagnostics with physical fail bitmaps and XY coordinate identification that
determines the root cause of failures
For more information, see https://www.synopsys.com/implementation-and-signoff/test-
automation/testmax-sms.html.
See Also
• Licensing

This topic describes the major TestMAX SMS components and their features.
The following figure shows the TestMAX SMS architecture.

T-2022.03-SP3
Feedback
Figure 1 TestMAX SMS Architecture
CPU SoC
Test bus
Cache
eFUSE
group 1
Core1
1EEE 1500
Test bus
Cache SMS
TAP
1EEE 1149.1
ATE
group 2 server
1EEE 1500
1EEE 1500
SMS SMS SMS

processor subserver processor
Wrapper Wrapper Wrapper Wrapper

2P 1P DP DP
RF RF SRAM SRAM
SMS-inserted components
The main SMS components are the server, subserver, processor, wrapper, and the SMS
IEEE 1500 network. The interconnection of the SMS components with the SMS server
through the IEEE 1500 network depends on the user configuration.
The server provides access points to the Test Access Port (TAP) controller, system
processor TAP, Advanced Peripheral Bus (APB), and SMART. The server consists of two
main modules—shared fuse processor (SFP) and JTAG to IEEE 1500 converter (JPC).
The SFP module provides full control of the repair signature flow through the IEEE 1500
network between the eFUSE and SMS cores. The JPC module provides interface with the
IEEE 1500 functionality. For more information, see Figure 20.
SMART provides direct interface to run functionalities such as BIST, BIHR, and UDR
load. The JPC_SFP block executes SMART for both SMS and STAR Hierarchical System
(SHS) cores. The system processor TAP provides alternate path to access the SMS cores
for in-system test and diagnostics.
The SMS processor takes control of the memories through intelligent wrappers and
performs memory testing and repair. The SMS processor supports
• IEEE 1500 pipelined interface. For more information, see Customizing Pipeline Stages.
• Different memory configurations with a single processor

T-2022.03-SP3
Feedback
TestMAX SMS Design Flow
• Test algorithm programmability

th
• Stop-on-n error diagnostics with full and compressed diagnostic information
• Masking any march operation in a single march element in BIST or built-in self-
diagnostics (BISD) mode
• Hammering in BIST or BISD mode
• Index-based repair
• Soft repair
• Hard repair through external eFUSE
The SMS wrapper provides interface between the processor and memories. The SMS tool
generates separate wrappers for SRAM and ROM. The wrapper wraps the memory with a
wrapper logic that takes control of the sequencing of address, data, and control signals of
the memory. Multiple memory wrapping options are available. The SMS wrapper supports
• Processor-to-wrapper high-speed parallel interface
• Pipelined wrapper architecture
• Pipelined registers on the path from BIST to memory input and pipelined registers on
the path from memory output to BIST
• Multi-instance wrapper architecture
• Alternative serial access to specific memory pins such as read, data margins, light
sleep, deep sleep, and shut down through scannable or programmable memory
parameters registers (SMPR or PMPR)
See Also
• TestMAX SMS
• Licensing

This topic describes the TestMAX SMS flow that generates and integrates the SMS
components into the RTL design or gates and validate the RTL design or gates in a
hierarchical or flat design flow.

T-2022.03-SP3
Feedback
Perform the following steps to generate and integrate the SMS components into the RTL
design or gates and validate the modified RTL:
1. Set up DFT: Defines clocks, memories, files, and other parameters. The tool reads,
elaborates, and links the design files.
2. Plan DFT: Defines memory grouping information. The tool traces the clocks and makes
them controllable.
3. Generate DFT: Generates SMS components based on your configuration.
4. Connect DFT: Integrates the SMS-generated components into the RTL design or gates.
5. Validate DFT: Tests the SMS components individually. The tool also tests the RTL
design integrated with the SMS components.

T-2022.03-SP3
Feedback
Figure 2 TestMAX SMS Design Flow

Set up DFT
Set up design
Read design files
Configure DFT
Define memory and clock constraints
Plan DFT (plan_dft)

Perform RTL lint check
Perform memory clock control check
Generate DFT (generate_dft)

Generate DFT components
Connect DFT (connect_dft)

Integrate SMS components into
the RTL design
Validate DFT (validate_dft)

Perform TestMAX Advisor connectivity check
Perform rule check for SMS components
Perform lint check for SMS components
Simulate quality assurance (QA)
Generate and validate patterns
Verify SMS components
See Also
• TestMAX SMS
• Licensing

T-2022.03-SP3
Feedback
Licensing
Licensing
The following licenses (provided with the tool) and tools are required for the TestMAX SMS
tool:
• Test-Platform-RTL license: Only one copy of the Test-Platform-RTL license is checked
out upon invocation. The license cannot be released until you exit the tool. Set the
SNPSLMD_LICENSE_FILE environment variable to the license server hosting the Test-
Platform-RTL license.
• TestMAX-Platform-BIST license: Enables BIST 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.
• Embed-It! (Version R-2020.09-SP1-ALPHA-20200910): Enables the set of tools

required for integrating the TestMAX SMS components with the RTL design.
• VCS: Enables BIST simulation.
• The Tcl version must be set to 8.4 or higher.
See Also
• TestMAX SMS

T-2022.03-SP3
Feedback
2
TestMAX SMS Network Architecture
The TestMAX SMS network consists of multiple SMS cores compliant to the IEEE 1500
standard. The SMS cores are grouped together using a shared module called a server or
subserver. Different types of SMS cores, repairable or non-repairable memories can share
the same server or subserver.
The SMS cores are connected in a ring to the server or the subserver. The cores in a ring
have similar behavior. For example, the cores in a ring are in the same clock domain.
Figure 3 TestMAX SMS Network Architecture

JTAG TAP
captureDR select_ipc_wir
TCK shiftDR
TDO TDI RST_N updateDR
eFUSE
APB SP_TAP
SMART pins WSOR SelectWIR

Ring bypass pins
Server
Other pins
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

T-2022.03-SP3
Feedback
Chapter 2: TestMAX SMS Network Architecture
TestMAX SMS Architecture With TAP
To learn more about the TestMAX SMS architecture, see

• TestMAX SMS Architecture With TAP
• TestMAX SMS Subsystem Architecture
• SRAM Wrapper Architecture
• ROM Wrapper Architecture
• Wrapped and Unwrapped Architectures
TestMAX SMS Architecture With TAP

TestMAX SMS architecture consists of components such as intelligent wrappers,
processors, and the server. The following figure shows the TestMAX SMS architecture with
TAP.
Figure 4 TestMAX SMS Architecture With TAP

WSI
SMS 1 Wrap 1 Memory
shift_dr
capture_dr
update_dr
SMS SMS 2 Wrap i Memory
IEEE 1500
Server
TDI TAP
smsg_sel
TDO
SMS n Wrap m Memory
TMS
TCK smsg_data
WSOR
TRSTN
WRCK and WRSTN
TestMAX SMS Subsystem Architecture

The TestMAX SMS subsystem consists of the complete RTL assembly for at-speed testing
(BIST), diagnostics (BISD), and repair (BIRA) of embedded memories. The following figure
shows the TestMAX SMS subsystem architecture.

T-2022.03-SP3
Feedback
SRAM Wrapper Architecture
Figure 5 TestMAX SMS Subsystem Architecture
SMS Subsystem
IEEE 1500
interface
Memory functional ports

Intelligent wrapper
STAR processor
Memory
IW controller
SMS primary
memory interface
interface
Processor to
The intelligent wrapper (IW) consists of two blocks: control and int. The control block
• Receives an opcode (such as write, read, or NOP) from the processor and generates
memory interface signals
• Translates the processor-generated linear address into the memory logical address
• Adds user-defined JTAG TAP registers for user-defined memory pins
• Adds the memory boundary scan registers for memory control through the JTAG TAP
• Contains the memory repair allocation engine and stores the data related to memory
repair
By default, the memory is instantiated inside the int block. The int block
• Creates a direct interface to the memory
• Adds test MUXs if not available in the memory
• Adds an error comparator if not available in the memory
• Adds DFT control logic to make the memory controllable and observable
SRAM Wrapper Architecture

The following figure shows the SRAM wrapper architecture.

T-2022.03-SP3
Feedback
ROM Wrapper Architecture
Figure 6 SRAM Wrapper Architecture

SRAM wrapper
serial chain
Wrapper
Chain MUX
control signals
Command Data
Memory
generator comparator
Wrapper
SMPR
BIRA
Reconfiguration
PMPR
register chain
ECC output
ECC
MRR
(Optional logic)
The following are the blocks in the SRAM wrapper:

• Chain MUX: Multiplexes wrapper scan chains between the SI and SO ports
• Command generator: Generates control signals according to the instructions from the
processor
• Memory reconfiguration register (MRR): Stores the memory reconfiguration signature
• SMPR/PMPR: Provides auxiliary registers as alternate serial or parallel access to the
memory I/O ports
• Built-in redundancy analysis (BIRA): Analyzes memory faults, allocate redundancy, and
generates repair signature
ROM Wrapper Architecture

The following figure shows the ROM wrapper architecture.

T-2022.03-SP3
Feedback
Wrapped and Unwrapped Architectures
Figure 7 ROM Wrapper Architecture

ROM wrapper
serial chain
Wrapper
Chain MUX
control signals
Command Memory MISR

generator
Wrapper
SMPR
Data
PMPR comparator
The following are the blocks in the ROM wrapper:

• Chain MUX: Multiplexes wrapper scan chains between SI and SO ports
• Command generator: Generates control signals to read the ROM content
• SMPR/PMPR: Auxiliary registers provided as alternate serial or parallel access to
memory I/O ports
• Data comparator: Compares the ROM memory output with the expected data and
generates a one-bit error signal
• Multiple-input signature register (MISR): Implements BIST capability for ROM
memories

The following diagrams show the different types of wrapped and unwrapped architectures.

T-2022.03-SP3
Feedback
Figure 8 Memory Wrapping Enabled

User design
Intelligent wrapper
Memory
SMS processor
IW controller
Processor to Wrapper to
wrapper interface memory interface
Figure 9 Memory Wrapping Disabled

User design
Memory
SMS processor
IW controller
Processor to Wrapper to
wrapper interface memory interface

T-2022.03-SP3
Feedback
Figure 10 Dedicated Wrapper
SMS Subsystem
Intelligent wrapper
Single-instance wrapper
STAR processor
Wrapper to memory
IW controller Memory
wrapper interface
interface
Processor to
Figure 11 Shared Wrapper

SMS Subsystem
Intelligent wrapper
Multi-instance wrapper
Subwrapper
Wrapper to memory
Subwrapper
STAR processor
Memory
Shared IW logic
Dedicated IW logic
interface
wrapper interface
Processor to

T-2022.03-SP3
Feedback
The following are the SMS components that are shared:

• Memory test control and address generation logic
• Chain handling and multiplexing
• Reset synchronizers
• BIRA
• Error registers
• SMPR/PMPR
The following are the SMS components that are not shared:
• Data comparator
• BIST MUXes
• Clock MUXes
• DFT schemes
• Memory reconfiguration registers
Figure 12 Pipelined Wrapper

SMS Subsystem
Intelligent wrapper
Memory
Processor to wrapper
high-speed signals
IW controller
Wrapper to
memory interface

T-2022.03-SP3
Feedback
Processor Architecture
The TestMAX SMS processor provides an external interface for the RTL assembly. The
processor controls the memories though intelligent wrappers and performs testing and
repair. The following figure shows the architecture of the processor.
Figure 13 Processor Architecture

STAR Processor
IEEE 1500 piped interface
TCLK
IEEE 1500 interface/Clock control manager GFCS Wrapper

clock
Wrapper Chain MUX Synchronizers/Metastability

serial chain
Repair data
Controller MISR FSM Wrapper MISR
generator control signals
Wrapper
control signals
HW algorithm BIST Controller

box
Test string
TA FSM BIST FSM
register
Operation Address Data

decoder generator generator
Wrapper BIST control signals
The TestMAX SMS processor contains the following blocks:

• 1500 piped interface: Two-stage pipeline that improves the interface timing
• Glitch-free clock switching (GFCS): Switches the clock between the WRCK and
CLK_SMS signals

T-2022.03-SP3
Feedback
• Chain MUX: Multiplexes the memory chains

• Controller: Generates control signals and collects status bits from the wrapper and the
processor
• MISR finite state machine (FSM): Available for ROM. Generates control signals for the
wrapper to implement MISR algorithms
• Test algorithm (TA) FSM: Stores and executes hardwired test algorithms
• Test string register (TSR): Contains a single march element
• Hardware algorithm container: Stores test algorithms hardwired in the processor
• BIST FSM: Executes the single march element stored in the TSR or the hardwired
algorithms
SMS Network Architecture Types

The TestMAX SMS server can select a single SMS processor at a time to run the
test. The server can also select a fixed number of SMS processors in a daisy-chained
concatenation to run the test in parallel.
The three types of server architectures are:
• Star Architecture
• Ring Architecture
• Hierarchical Architecture
Star Architecture
The following are the features of a server that uses the star architecture:
• Server accesses each SMS processor individually
• More connections are available from all SMS processors to the server
• Number of connections is six times the number of SMS processors
• SMS processors can be daisy chained within the server
• Each SMS processor can be bypassed from the server daisy chain
• Server downloads the repair data from the SMS processors, compresses the data, and
stores the data in one-time programmable (OTP) non-volatile memory called eFUSE

T-2022.03-SP3
Feedback
Figure 14 Star Architecture

JTAG TAP
SMS1 SMS4
M
M
SMS2 STAR SMS5 M
server
M
Fuse box
M SMS3 SMS6
M
M
M
Ring Architecture
The following are the features of a server that uses the ring architecture:
• Server accesses each ring individually
• Server cannot access an SMS processor individually
• SMS processors can be daisy chained within the server
• Individual SMS processors in a ring cannot be bypassed from the server. Only a
complete ring can be bypassed.
• Controlled by the sms_grouping_list parameter of the server compiler.

T-2022.03-SP3
Feedback
Figure 15 Ring Architecture

JTAG TAP
SMS1 SMS9
SMS8
SMS2
SMS7
STAR
SMS3
server
Fuse box SMS6
SMS4 SMS5
Hierarchical Architecture
The following are the features of a server that uses the hierarchical architecture:
• Server accesses only its SMS processors or rings.
• SMS processors can be daisy chained within the server.
• Individual SMS processors in a ring cannot be bypassed from the server. Only a
complete ring can be bypassed.
• Controlled by the hier_mode=1 parameter of the server compiler.

T-2022.03-SP3
Feedback
Figure 16 Hierarchical Architecture

JTAG TAP
SMS1 SMS12
JTAG-ready
SMS2 SMS11
subserver
Fuse box
Subserver1 Subserver2
SMS3 SMS10
SMS5 SMS6 SMS7 SMS8 SMS9

SMS4
For more information about the architecture of the server, subserver, processor, and
wrapper, see the SMS Server User Guide and the SMS Processor User Guide.
SMS Server
The following figure shows the SMS server with different interfaces.
Figure 17 SMS Server and Interfaces

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

Ring 1
Ring 2
Ring n
The JTAG to IEEE 1500 converter (JPC) logic converts the IEEE 1149.1 signals into IEEE
1500 interface signals. The shared fuse processor (SFP) controls the repair signature flow
for all SMS cores in the SMS network through the IEEE 1500 interface. The SFP provides
an interface between the SMS cores and the eFUSE.

T-2022.03-SP3
Feedback
The JPC_SFP block controls the SMS SMART BIST functionality. The system processor
TAP interface provides alternate path to access SMS and all memories. This enables the
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, addressed as word0 and word1.
The server is connected in a two-level hierarchy. The server is always at the first level. The
second level of servers are called subservers. 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)
The following figure shows the server hierarchy.

T-2022.03-SP3
Feedback
Figure 18 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
When the server shares eFUSE with the subserver, the subserver must be generated with
the eFUSE option enabled. The server generates a copy of server repair data register,
buffer register, and user data register, which helps eFUSE to read/write. The subserver
contains SMART pins that support the BIHR flow for both SMS and SHS. The following
figure shows the sharing of eFUSE between the server and subserver.

T-2022.03-SP3
Feedback
Figure 19 Sharing eFUSE between the Server and Subserver

Server Subserver
Data registers Data registers
WIR WIR
(repair signal processing)
(repair signal processing)

BYP eFUSE eFUSE
BYP
driver driver
RR copy Repair
register
Controller
Controller
eFUSE eFUSE
UDR
Boundary Boundary
register register
Ring Ring
number number
Ring communicator Ring communicator

R-BYP R-BYP
The JPC register controls the JPC_SFP block using the signals received from the TAP.
The JPC is a sequential logic that connects the TAP I/O to the IEEE 1500 I/O signals
of the core rings. The synchronizer block is used for isolating the core rings using the
ring_bypass signals. The following figure shows the JPC block.

T-2022.03-SP3
Feedback
Figure 20 JPC Block

JPC
JPC Register
From/to Converter IEEE 1500

TAP signals
Synchronizer
The SMS tool supports OTP, multi-time programmable (MTP), and eFUSE from different
vendors. The server controls the transfer of data with eFUSE through the generic eFUSE
interface in test and SMART modes. The generic eFUSE interface consists of the write
buffer, FSM, and registered output. The eFUSE is user programmed. The following figure
shows the generic eFUSE interface.

T-2022.03-SP3
Feedback
Figure 21 Generic eFUSE Interface
eFUSE eFUSE
controller
Synchronizer
ef_addr ef_data
Registered outputs Write buffer
FSM
Repair buffer
Controller data register
Server

T-2022.03-SP3
Feedback
3
Working With TestMAX SMS
The TestMAX SMS tool can only be used through a command-line interface called
dft_shell.
To learn more about configuring the tool and using the commands, see
• Configuring TestMAX SMS
• Using the User Interface
• Getting Started
Configuring TestMAX SMS

Before invoking the TestMAX SMS tool, set the following environment variables:
• SNPSLMD_LICENSE_FILE: Specifies the license server hosting the Test-Platform-RTL
license.
• EMBEDIT_HOME: Specifies the path of the latest Embed-It! installation.
• VCS_HOME: Specifies 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 SMS tool, enter the tool invocation command, dft_shell in the
Linux shell.
At startup, the dft_shell command performs the following tasks:
• Displays the program header and dft_shell tool prompt
• Executes any script file or command specified by the -file option

T-2022.03-SP3
Feedback
Chapter 3: Working With TestMAX SMS
Getting Started
Running the TestMAX SMS 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.
To exit the tool, use the exit or quit command.
Getting Started
The TestMAX SMS tool uses a design library to store the design and its associated library
information. This topic describes how to define the search path and set up libraries and
binary paths.
To get started with the TestMAX SMS tool, see:
• Defining the Search Path
• Setting Up Libraries
• Setting Up Binary Paths
Defining the Search Path

The TestMAX SMS 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 the list of 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 uses the first matching file.
Use the search_path variable with the following commands:
• set_app_var – The following example adds 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 your directories to the default search
path, which is the directory from which you invoked the tool.
Example:
dft_shell> lappend search_path ./mylibdir

T-2022.03-SP3
Feedback
Chapter 3: Working With TestMAX SMS
Getting Started
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 for memories, standard cells, I/O pads, and so
on.
Example:
dft_shell> create_lib -ref_libs {../NDM/ \
cell_library_path ../NDM/saed32hvt_c.ndm} stdcell.nlib
Setting Up Binary Paths

Before running the TestMAX SMS tool, ensure that
• All required licenses are available. For more information, see Licensing.
• The tool executable locations are defined in the following environment variables:
◦ SPYGLASS
◦ EMBEDIT
◦ TestMAX
◦ VCS
For example,
% setenv SPYGLASS /spyglass_installation_path/SPYGLASS_HOME
% setenv EMBEDIT /embedit_installation_path/embedit/bin
% setenv VCS /vcs_installation_path/vcs/bin

T-2022.03-SP3
Feedback
4
Methodology
This topic describes the methodology for integrating and validating the memories in a
hierarchical or a flat flow. Perform these steps in the TestMAX Manager tool to integrate
and validate the inserted components:
• Set up DFT: Defines clocking, memories, design files, and so on. The tool reads,
elaborates, and links the design files.
• Plan DFT: Defines memory grouping information. The tool traces the clocks and makes
them controllable.
• Generate DFT: Generates SMS components based on your configuration.
• Connect DFT: Integrates the SMS-generated components into the RTL design.
• Validate DFT: Tests the individual components and the RTL design integrated with SMS
components.

T-2022.03-SP3
Feedback
Chapter 4: Methodology

The following figure shows the core-level methodology.
Figure 22 Core-Level Methodology

Set up DFT
Set up design
Read design files
Configure DFT
Plan DFT (plan_dft)


Generate DFT components

the RTL design

Simulate quality assurance (QA)
Generate and validate patterns

T-2022.03-SP3
Feedback

The following figure shows the subsystem-level methodology.
Figure 23 Subsystem-Level Methodology

Set up DFT
Set up design
Read design files
Configure DFT
Enable access and select access type
Read test model
Plan DFT (plan_dft)


Generate SMS components

the RTL design

Simulate QA
Verfify SMS components

T-2022.03-SP3
Feedback

The following figure shows the SoC-level methodology.
Figure 24 SoC-Level Methodology

Set up DFT
Set up design
Read design files
Configure DFT
Enable access and select access type
Read test model
Insert TAP controller

Enable BSD
Set IR instruction width
Define TAP signals
Define instructions
Plan DFT (plan_dft)



the RTL design

Simulate QA

T-2022.03-SP3
Feedback

In the following hierarchical flow example, the functional design has memories (without
repair capability) at the core and subsystem levels only and not at the SoC level. However,
in real designs, any level can have memory.
Figure 25 Functional Design With Memory at Core and Subsystem Levels

SoC
Subsystem1 Subsystem2
Memory Memory
Core1 Core2
Memory Memory
At the core level, the tool reads, elaborates, and links the design. Then, the tool reads the
memory and SMS interface standard (MASIS) files for the memories that must be inserted
with BIST. For setting the global options for the BIST controller, two options are available:
• Use the set_mbist_configuration command to configure the number of memories
per wrapper and the number of wrappers per processor.
• Let the tool decide the number of processors and wrappers using the default criteria.
By default, the memories are grouped per wrapper or processor based on the clock
domains.
The tool inserts the shadow server at this level. The tool also generates and validates
BIST patterns. As part of the pattern validation, the tool also performs connectivity and
integrity checks. For information about generating, validating, and verifying BIST patterns,
see Flow for Flat Design.

T-2022.03-SP3
Feedback

Figure 26 Processor Integration at the Core Level

SoC
Memory Memory
Core1 Core2
Memory + Memory +
Processor Wrapper Processor Wrapper
In this example, at the subsystem level, a few memories are present. The tool generates
• Processors and subservers for the memories
• Rings and connects the subsystem-level processors to core-level processors
Figure 27 Subserver Integration at Subsystem Level

SoC
Subserver Subserver
Processor Memory Processor Memory
Core1 Core2
Memory + Memory +
In this example, at the SoC level, there are no memories.

T-2022.03-SP3
Feedback

Note:
In real designs, the SoC level can contain memories. In this case, the tool
inserts processors and other BIST components for all the memories according
to the user configuration (using the set_mbist_configuration command). If
there is no user configuration, then the tool inserts processors according to the
default settings. For more information, see Enabling the BIST Client.
The tool performs the following functions:
• Integrates the TAP controller
• Integrates the server
• Generates rings
Note:
One ring is created per subserver and a separate ring is created for the
processors and shadow-server-based cores at the SoC level. In this example,
the tool does not create rings at the SoC level because there are no memories.
At the SoC level, the tool generates and validates test patterns comprehensively. TestMAX
SMS supports custom BIST production patterns at the SoC level. You can save the
patterns in different tester formats such as STIL and WGL. For information about custom
BIST production patterns, see BIST Production Patterns.
Figure 28 Server and TAP Integration at the SoC Level

SoC
TAP Server
Subserver Subserver
Processor Memory Processor Memory
Core1 Core2
Memory + Memory +

T-2022.03-SP3
Feedback

The following figure shows the steps and commands for generating, integrating, and
validating the TestMAX SMS components.
Figure 29 TestMAX SMS Integration

Set up DFT
analyze – Read the design
elaborate – Build the design
create_lib – Create library in memory and set it as the current library
Define clocks (create_clock)

Define memory clocks
Enable BIST (set_dft_configuration -mbist_enable)

Enable memory BIST client to insert the SMS components
Specify BIST (set_mbist_configuration)

Specify BIST configuration such as number of wrappers per processor
Plan DFT (plan_dft)

Generate clock transparency check, Integrator shell script (ISH) file
and DFT reports


Integrate the generated SMS components into the RTL design

Perform connectivity and lint check

T-2022.03-SP3
Feedback
5
Flow for Flat Design
This topic contains the following sections:
• Integrating SMS components (BIST IP) into the RTL design using the TestMAX SMS
tool
• Configuring BIST in the TestMAX platform shell for integrating the BIST IP into the RTL
design
To learn about the TestMAX SMS flow for flat designs, see
• Flow Diagram for Flat Design
• Setting Up Design Files
• Enabling the BIST Client
• Configuring BIST
• Configuring the DFT Access Elements
• Generating the Memory Grouping Information
• Generating the SMS (BIST) Components
• Connecting the SMS Components to the RTL Design
• Writing the TestMAX SMS DFT Constraints
• Writing the TestMAX SMS DFT Constraints for the Current Level
• Validating the SMS Connections
• Verifying the SMS-Generated Components
• Simulating the BIST System
• Example Script: Overall Flow

T-2022.03-SP3
Feedback
Chapter 5: Flow for Flat Design
Flow Diagram for Flat Design
Flow Diagram for Flat Design

The following figure shows the high-level flow of the TestMAX SMS tool for flat design.
Figure 30 High-Level Flow Chart for Flat Design

Set up DFT
Read RTL design files and NDMs for
memories and standard cells
Plan DFT (plan_dft)

and memory grouping

Generate SMS components such as
processors, wrappers, and server

the RTL design

Check structure and connection
between SMS-generated components,
generate patterns, and simulate
SMS-inserted design

T-2022.03-SP3
Feedback
Setting Up Design Files
Setting Up Design Files

The following topics describe how to set up the design files:
• Reading the Design
• Defining Memory Functional Clocks
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 the other modules of the design. This allows you to run multiple
elaborate commands run 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.
Linking the design and setting the top-level module is done using the set_top_module
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 in the remainder of
the design flow.
Example:
// Reading the RTL design files
set design des_unit_core
analyze -f sverilog [glob RTL/*]
elaborate $design set_top_module $design
Defining Memory Functional Clocks

Memory functional clocks must be defined for enabling the Embed-It! STAR Planner tool
to generate the initial memory grouping information based on the clock domains. Proper
constraints must be present for tracing the memory clock to a valid clock source. The tool
performs clock controllability checks and reports any clock rule violation when the tool
runs the plan_dft command. For information about debugging clock rule violation, see
Debugging Clock 29 Violations.
Use the create_clock command to define the clocks driving the memories in the
design. Use the create_generated_clock command to define internal clocks driving the
memories in the design. The following figure shows how the clocks are defined.

T-2022.03-SP3
Feedback
Enabling the BIST Client
Figure 31 Clock Definition

Generated clock – 500 MHz
REF_CLOCK (1GHz)
Divide by 2 Clock gating high_speed_mem_inst_1
RST
clk1000 (1000 MHz) high_speed_mem_inst_2
clk500 (500 MHz)
The following is an example for defining memory clocks:

#Define memory clocks
dft_shell> create_clock -name clkgrp_user_500 -period 2 -waveform {0 1 }
\
{ clk500 }
create_clock -name clkgrp_user_1000 -period 1 -waveform {0 .5} \
{ clk1000 }
create_clock -name REF_CLOCK -period 1 -waveform {0 .5} { ate_clk }
create_generated_clock -name DIV2_CLK [get_pins memory_inst/divider_inst/
\
out_clk]
-source REF_CLOCK -divide_by 2 -master_clock REF_CLOCK -add
#Case for memory clock propagation (Clock gate enable)
set_case_analysis 0 RST
For more information about the create_clock and create_generated_clock commands

usage, see the man pages.
Enabling the BIST Client

After the tool reads, elaborates, and links the design files, the tool checks for licenses. To
enable the BIST client, use the -mbist enable option with the set_dft_configuration
command.
Example:
set_dft_configuration -mbist enable
After enabling the BIST client, configure BIST as described in Configuring BIST.

T-2022.03-SP3
Feedback
Configuring BIST
Configuring BIST
Use the set_mbist_configuration command to define the BIST parameters for the
design.
For configuring BIST, use the following options with the set_mbist_configuration
command:
• -allow_module_override: Allows multiple definitions of modules for VCS during
simulation of the modified (BIST-inserted) design.
Example:
set_mbist_configuration -allow_module_override on|off
• -builder_config: Specifies the directory of the STAR Builder configuration file (RCL
file). The STAR Builder tool integrates the SMS-generated components into the RTL
design.
Example:
set_mbist_configuration -builder_config insert.rcl
Use this option to specify the configuration file (RCL file) for the STAR Builder
tool. The generate_dft -generate_connections command uses the RCL
file when launching the STAR Builder tool. By default, this is option is set to
sms_generate_dft_default.rcl. For information about modifying the RCL file, see
Customizing the Interface.
• -compiler_libraries: Lists the paths to the TestMAX SMS compiler libraries such as
the wrapper compiler, processor compiler, server compiler, and others. The compilers
are used to generate the wrapper, processor, server RTL, and other supporting files
such as testbench and synthesis views.
Example:
set_mbist_configuration -compiler_libraries "../complib.6x"
Note:
Use only compiler libraries recommended by Synopsys. Using other
compiler libraries can cause issues such as connectivity failures, simulation
mismatches, and incorrect hardware.
• -compout_path: Specifies the directory where the SMS components generated by
the Embed-It! STAR Integrator tool is written out. By default, this option is set to the
project_name/compout directory.

T-2022.03-SP3
Feedback
Configuring BIST
Example:
set_mbist_configuration -compout_path $design\compout
• -integrator_config: Specifies the directory of the Embed-it! STAR Integrator shell

script file (ISH file). The plan_dft command generates the ISH file.
Example:
set_mbist_configuration \
-integrator_config ./scripts/ shell_project.ish
Use this option to specify the configuration file (ISH file) for the Embed-It! Integrator
tool. The generate_dft command uses the ISH file when launching the Embed-It!
Integrator tool. By default, this option is set to scripts/project_name.ish.
• -masis_files: Specifies the directory that contains the MASIS files. MASIS files
specify the memory instance parameters that are necessary for the tool to interface
with the RTL design. MASIS files allow you to describe the physical core of the
memory. MASIS files (*.masis) include behavioral, structural, and other information of
the memory. MASIS files can be generated using the MASIS compiler.
Example:
set_mbist_configuration -masis_files "../masis"
• -max_mem_num_per_proc: Specifies the number of memories per processor.
Example:
set_mbist_configuration -max_mem_num_per_proc 11
• -max_mem_num_per_wrapper: Specifies the number of memories per wrapper.
Example:
set_mbist_configuration -max_mem_num_per_wrapper 4
• -planner_config: Specifies the path to user-defined Embed-It!STAR Planner

configuration file.
Example:
set_mbist_configuration -planner_config ./planner.tcl
The plan_dft command uses the planner configuration file when launching the STAR
Planner tool. By default, the plan_dft command creates the planner configuration file.
If you use this option to specify a user-defined planner configuration file, you must also
specify the -project_name option.

T-2022.03-SP3
Feedback
Configuring BIST
• -project_name: Specifies the Embed-It! STAR Planner project name. This also
specifies the directory where the SMS components generated by the Embed-It! STAR
Integrator are written out.
Example:
set_mbist_configuration -project_name $design\_compout
The default path is dft_shell_project. You must specify this option when you specify
the -planner_config option.
• -simulation_models: Lists the directories containing memory Verilog simulation
models or other simulation model files.
Example:
set_mbist_configuration -simulation_models "../simulation_models"
• –simulation_models_sourcelist: Specifies the paths to the source files, where

each source file contains the design files and other options (such as +define) that are
used for simulation.
Example:
set_mbist_configuration –simulation_models_sourcelist {./pad.f}
• -simulation_scripts: Specifies the path of simulation scripts for the Integrity

Checker tool. The default is sim_<design_name>.
Example:
set_mbist_configuration -simulation_scripts sim_top_block
• -verifier_options: Specifies the options of the script file, which will be used for
simulating the modified design.
Example:
set_mbist_configuration -verifier_options "–real design_list_svlog \
/*_ya_files/design_sv.lst"
• -verifier_script: Specifies the STAR Verifier simulation script path. For information
about STAR Verifier, see BIST Production Patterns.
Example:
set_mbist_configuration \
-verifier_script verifier_project_simulation/run_sim.scr

T-2022.03-SP3
Feedback
Configuring the DFT Access Elements
Configuring the DFT Access Elements

To define and configure DFT access elements, use the following options with the
set_dft_access_element command:
• -type: Specifies the type of component. Supported types include shadow_server,

sub_server, top_server, processor, mmb_processor, cam_processor, wrapper,
AIT, and subchip.
• -module: Specifies the module name of the generated IP.
For selecting processors using processor and mmb_processor types, you can use
keywords such as:
◦ SMS_ALL_SP_MEM_PROC: Single port processor mode
◦ SMS_ALL_MP_MEM_PROC: Multiport processor mode
◦ SMS_ALL_ROM_PROC: ROM processor mode
For example, the following command selects all single port processors:
set_dft_access_element -type processor -module SMS_ALL_SP_MEM_PROC
You can use this option to select wrapper and processor modules using a wildcard
entry. For example, the following command selects all wrappers whose names start
with core_wrap:
set_dft_access_element -type wrapper -module core_wrap.*
• -parameter: Specifies the TestMAX SMS parameters that overrides the default. The
tool uses this option to update the ISH file.
• -interface: Overrides the connections. When you use this option, the tool updates
the RCL file.
For more information about the set_dft_access_element command options, see the
manpages.
Generating the Memory Grouping Information

Use the plan_dft command to generate the memory grouping information. The plan_dft
command creates the sms_plan_dft_planner_config.tcl file, which has the information of
your BIST configuration, RTL design files, memory MASIS files, and so on.
The plan_dft command invokes the TestMAX Advisor and Embed-It! STAR Planner tools.
The TestMAX Advisor tool identifies the total number of memory instances using memory
NDM models and MASIS files and checks for clock transparency (clock 29 violations).

T-2022.03-SP3
Feedback
For more information, see Debugging Clock 29 Violations. The TestMAX Advisor tool
generates the dft_memory_report file, which reports memory-related information such as
clock frequency, clock source, count, and so on.
The Embed-It! STAR Planner tool uses the sms_plan_dft_planner_config.tcl and
dft_memory_report files generated by the TestMAX Advisor tool as input to generate the
initial memory grouping information and the Embed-It! STAR Integrator shell script (ISH)
file.
The ISH file is used as an input by the Embed-It! STAR Integrator tool when you run the
generate_dft command to generate the SMS components. The preview_dft.rpt report
file, which is an output of the Embed-It! STAR Planner tool contains the SMS components
and memory grouping information.
The following is an example output of the plan_dft command.
dft_shell> plan_dft
Information: Populating memory information.
Information: Using NDM models for memory identification
Information: Populating compiler information.
Information: Populating setup information.
Information: STAR Planner config file not set. Creating planner config
file
****************************************
Report : Reporting Mismatches
Version: R-2020.09-DEV
Date : Tue Sept 31 16:34:20 2020
****************************************
==============================
Library : stdcell.nlib
==============================
Mismatch Type Total Count Repaired Unrepaired
-----------------------------------------------------------------------
empty_logic_module 2 0 2
Information: Generating design lib file ./sms_plan_dft_gate_design.tlib
Information: Successfully created planner config file
'sms_plan_dft_planner_config.tcl'
Information: Number of memory instances found in design: 1
****************************************
Date : Tue Sept 31 16:34:21 2020
****************************************
==============================
==============================
-----------------------------------------------------------------------
Information: Generating design lib file ./spg_plan_dft_gate_design.tlib

T-2022.03-SP3
Feedback
Extracting memory clock information from SpyGlass...

/$/SPYGLASS_HOME/bin/spyglass -project spg_plan_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, 5 warnings, 9 Infos
-------------------------------------------------------------------
Results Summary:
-------------------------------------------------------------------
Total Flip flop count: 977
Scannable Flip flop count: 976
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
--------------------------------------------------------------------
Reports Directory:
/.../core/spg_plan_dft_config/consolidated_reports/des_unit_core_dft_she
ll_goal/
SpyGlass LogFile:
/.../core/spg_plan_dft_config/consolidated_reports/des_unit_core_dft_she
ll_goal/spyglass.log
Standard Reports:
spyglass_violations.rpt moresimple.rpt
MEMORY CLOCK REPORT

###################################################################
# This file has been generated by DFT rule 'Info_memories'.
# This report has two sections.
# - The first section contains the total memory count in the design
# followed by the number of memory instances per module
# - The second section contains memory instance specific information
# - shift_clock
# - capture_clock
# - functional clock(s) for all clock pins of all memory
instances
####################################################################
Total Memory Instance Count
: 1

T-2022.03-SP3
Feedback
Total Instance Count for memory module

sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00 : 1
memory_instance
-instance_name
"des_unit_core.memory_inst.high_speed_mem_inst_1.u_mem"
-master_name
"sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00"
-scanwrapped
-sgdc_memory
-clock_pin_1_name "CLK"
-clock_pin_1_shift_clock_name
"des_unit_core.memory_inst.divider_inst.out_clk"
-clock_pin_1_shift_clock_phase posedge
-clock_pin_1_capture_clock_name
-clock_pin_1_capture_clock_phase posedge
-clock_pin_1_fastest_functional_clock_name
-clock_pin_1_fastest_functional_clock_frequency 500.0000
-clock_pin_1_fastest_functional_clock_phase posedge
-clock_pin_1_func_clock_001_logical_name "DIV2_CLK"
-clock_pin_1_func_clock_001_root_name
-clock_pin_1_func_clock_001_frequency 500.0000
-clock_pin_1_func_clock_001_root_phase posedge
Invoking STAR Planner...

Information: STAR Planner run started
Information: Read masis files... done
Information: Read compiler library... done
Information: Generating memory group configurations... done
Information: Generating integrator shell script... done
Information: STAR Planner run completed successfully
Information: Integrator Config File set to :
scripts/des_unit_core_compout.ish
Information: Integrator Config File set to :
scripts/des_unit_core_compout.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

T-2022.03-SP3
Feedback
Generating the SMS (BIST) Components
The plan_dft command creates the following directories and files in the current working
directory:
• spg_plan_dft_sources.f – List of all RTL source files.
• spg_plan_dft_constraints.sgdc – TestMAX Advisor constraints such as Clocks, Async,
and TestMode.
• spg_plan_dft_config.prj – File required by the TestMAX Advisor tool to read the source
list and .sgdc files, and to define the checks that are run, such as clock 29 violations.
• spg_plan_dft_config/ – This directory contains the following report files that provide
information such as design-related violations and memory count:
◦ /spg_plan_dft_config/consolidated_reports/des_unit_core_dft_shell_goal/
spyglass_violations.rpt
◦ /spg_plan_dft_config/consolidated_reports/des_unit_core_dft_shell_goal/
moresimple.rpt
◦ ./spg_plan_dft_config/design_name/dft_shell_goal/spyglass_reports/dft/
dft_memory_report.rpt
• <design_name>_compout_mem.csv – This file contains the memory grouping
information.
• sms_plan_dft_sources.f – RTL source files.
• sms_plan_dft_planner_config.tcl – This file contains information such as BIST
configuration, RTL design files, and memory MASIS files, which is used by the Embed-
It! STAR Planner tool for ISH file generation.
• scripts/design_name.ish – Used as an input file by the Embed-It! STAR Integrator tool
when you run the generate_dft command.

After configuring the BIST implementation for your design, generate the BIST components
by using the generate_dft command.
The generate_dft command generates the following files:
• RTL files for SMS components such as processors, wrappers, and servers.
• Files required for the instantiation and connection of the SMS components at the
required level of hierarchy in the RTL design.
• Files required for validation by the validate_dft command.

T-2022.03-SP3
Feedback
The generate_dft command invokes the Embed-It! STAR Integrator and Embed-It! STAR
Builder tools internally. The Embed-It! STAR Integrator tool generates SMS components
such as servers, shadow servers, subservers, processors, and wrappers based on
the scripts/<project name>.ish file. This file contains server, processor, and wrapper
generation parameters.
The Embed-It! STAR Builder tool generates the necessary files required for the
instantiation and connection of the SMS components in the hierarchy of the RTL design.
The Embed-It! STAR Builder tool also generates the files that are required for validation
when you run the validate_dft command.
The following is an example output of the generate_dft command.
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 Disable
Wrapper Disable
Logicbist Disable
Mbist Enable
Dft Access Disable
Scan_compression Disable
Pipeline_scan_data Disable
Clock_controller Disable
ieee_1500 Disable
Bsd Disable
Hsio Disable
Invoking STAR Integrator...
Information: STAR Integrator run started
Information: Read files... done
Information: Running "Generate" on component
"sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00"
Information: Running "Generate" on component
"des_unit_core_wrap_sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00_1"
Information: Running "Generate" on component "des_unit_core_proc_1"
Information: Running "Generate" on component "des_unit_core_srv_1"
Information: STAR Integrator run completed successfully
Information: ICT files moved successfully to des_unit_core_srv_1.ict.zip
directory.
Information: Compout Path set to: des_unit_core_compout/compout
Use command
'set_mbist_configuration/set_dft_access_configuration -compout_path' to
change.
Date : Tue Sept 31 17:25:44 2020
****************************************
==============================
==============================

T-2022.03-SP3
Feedback

-----------------------------------------------------------------------
Information: Generating design lib
file ./sms_generate_dft_gate_design.tlib
Invoking STAR Builder to generate default rcl file...
Information: STAR Builder run started
Information: Design "des_unit_core" is loaded
Information: Design
"des_unit_core_wrap_sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00_1" is
loaded
Information: Design "des_unit_core_proc_1_sms" is loaded
Information: STAR Builder run completed successfully
Information: Builder Config File set to: sms_generate_dft_default.rcl
Use command
'set_mbist_configuration/set_dft_access_configuration -builder_config'
to change.
Invoking STAR Builder to generate connection file...
Information: STAR Builder run started
Information: Design "des_unit_core" is loaded
Information: Design
"des_unit_core_wrap_sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00_1" is
loaded
Information: Design
"des_unit_core_wrap_sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00_1_int_t
op_1" is loaded
Information: Design "des_unit_core_proc_1_sms_1" is loaded
Information: Design "des_unit_core_srv_1_sms_group" is loaded
Information: Design "des_unit_core_proc_1_sms" is loaded
Information: STAR Builder run completed successfully
****************************************
Date : Tue Sept 31 17:26:11 2020
****************************************
==============================
==============================
-----------------------------------------------------------------------
Information: Generating design lib file ./rtl_modifier_gate_design.tlib
Information: Generating RTL modifier input source list
file ./rtl_modifier_sources.f
Information: Generating RTL modifier commands
in ./rtl_modifier_connection_commands.tcl

T-2022.03-SP3
Feedback
Connecting the SMS Components to the RTL Design
The following are the files and directories created by the generate_dft command:
• <design_name>_compout/compout – The directory contains the RTL files for the
SMS-generated BIST components. TestMAX SMS components are written out by the
Embed-It! STAR Integrator tool.
• <design_name>_ya_files – The directory contains the design_sv.lst,
<design_name>_srv_1_chip_param.cpf, <design_name>_srv_1_uds.uds,
<design_name>_hier_paths_sms.txt, <design_compout>_hier_paths.txt files. These
files are used during simulations by the STAR Verifier tool.
• sim_<design_name> – The directory contains the simulation files for each of the SMS-
generated component. These files are used by Integrity Checker to validate the RTL of
the SMS-generated components.
• rtl_modifier_sources.f – List of RTL source files for the connect_dft command.
• rtl_modifier_connection_commands.tcl – Script file used by the connect_dft
command to modify the RTL design.
• rtl_modifier_sources_ip.f – List of source files of SMS-generated components for the
connect_dft command.
• spg_validate_dft_constraints.sgdc – This file contains connectivity and rule check

instructions for the validate_dft command.
• <design_name>_srv_1.ict.zip and <design_name>.wks – Files used as input test
models for the hierarchical flow.
Connecting the SMS Components to the RTL Design

The connect_dft command integrates the SMS-generated components into your RTL
design, connects it, and then generates the modified RTL in the output/Verilog directory.
This directory contains the source file content and the modified content. All the modified
files retain the original RTL name.
The command uses the rtl_modifier_connection_commands.tcl script file written out by the
generate_dft command.
The following is an example output of the connect_dft command.

dft_shell> connect_dft
Invoking RTL modifier...
RTL modifier run started
Information: RTL modifier design read complete.
Information: BIST DFT IPs read complete.
Information: BIST DFT IPs instantiation complete.
Information: Connections for BIST DFT IPs complete.
Information: RTL generation complete.

T-2022.03-SP3
Feedback
Writing the TestMAX SMS DFT Constraints
Information: RTL modifier run completed successfully.

Information: Modified RTL with DFT IP generated
at /.../core/output/Verilog directory.
RTL modifier Log Directory: /.../core/rtl_modifier_log/
RTL modifier LogFile : /.../core/rtl_modifier_log/gensys.log
The connect_dft command generates the following files and directories:

• output/Verilog: Directory for the modified RTL with the SMS (BIST) components
instantiated.
• output/stub: Directory for the stub Verilog file of the BIST-inserted RTL design of the top
module.
• spg_validate_dft_sources.f: List of source files for the validate_dft command.
• spg_validate_dft_config.prj: Instructions for the validate_dft command.
• Log and report files: Log and report files for the connect_dft command.
Example:
rtl_modifier_log/gensys.log
Writing the TestMAX SMS DFT Constraints

To write the SMS DFT constraints, use the write_dft_constraints -sms -sms_outdir
SMS_constraints command.
The SMS constraints are saved in the SMS_constraints/sg_output/design_name directory.
Writing the TestMAX SMS DFT Constraints for the Current Level
To write the SMS DFT constraints for the current level only, use the following command:
write_dft_constraints -sms -sms_outdir output_directory \
-setup_options [list TOP_CONSTR_ONLY 1]
You can also customize other parameters such as OUTPUT_DIR, DONT_USE_CELLS, and
SUBCHIP_FOLDERS. For more information, see the STAR Builder User Manual.
Alternatively, you can use a custom setup file. The .script_gen_plugin.setup file with
default parameter settings is generated by the tool during constraints generation. You can
customize the parameters in this file to make your own .setup file and pass the custom
parameters as follows:
write_dft_constraints -sms -sms_outdir output_directory \
-setup_file setup_file_path

T-2022.03-SP3
Feedback
Validating the SMS Connections
setup_file_path specifies the path to the file with the custom parameters. The SMS
constraints are saved in the SMS_constraints/sg_output/design_name directory.
Validating the SMS Connections

To validate the constraints generated for connections and rules, use the validate_dft
command. You can use the following options with the validate_dft command:
• -check: Specifies the checks to perform. Valid values are -check connectivity,
which performs connectivity checks between the BIST components and the RTL
design, as well as rule checks on the BIST components, and -check lint, which
performs lint checks on the BIST components.
• -load_gui: Controls whether to load the TestMAX Advisor GUI to help debug issues.
Valid values are on (launches the GUI), off (the TestMAX Advisor tool runs in batch
mode and generates reports), or run.
• -verbose: Generates verbose output during the connectivity check.
The following is an example output of the validate_dft -check connectivity

command.
dft_shell> validate_dft -check connectivity
Invoking SpyGlass...
/$/SPYGLASS_HOME/bin/spyglass -project spg_validate_dft_config.prj -goal
'BIST_IP_CONNECTIONS' group connection validation started...
'289' check(s) passed
'0' check(s) failed
'BIST_IP_CONNECTIONS' group connection validation completed
SpyGlass Message Summary: 0 error, 1 warning, 319 Infos
--------------------------------------------------------------------
Results Summary:
--------------------------------------------------------------------
: 0
flip-flops : 0
: 0
--------------------------------------------------------------------
Reports Directory:

T-2022.03-SP3
Feedback
Verifying the SMS-Generated Components
/.../core/spg_validate_dft_config/consolidated_reports/des_unit_core_dft
_shell_goal/
SpyGlass LogFile:
/.../core/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
Verifying the SMS-Generated Components

To verify the SMS-generated components, use the validate_dft -check
verify_mbist_components command. This command invokes the Integrity Checker tool
and does a simulation-based (VCS) check to validate the SMS-generated components.
The Integrity Checker tool uses the simulation files for the SMS components generated
by the validate_dft command in the sim_<design_name> directory. You can specify the
following options with the validate_dft -check verify_mbist_components command:
• -qa_sims on|off: This option controls whether the tool performs quality assurance
(QA) simulation. The default value is off.
• -qa_sims_options "-–rtl"|"--gates": This option sets the QA simulation
procedure option. The default value is "--rtl".
• -integrity_checker on|off: This option controls whether the Integrity Checker tool
is used. The default value is on.
The following is an example output of the validate_dft -check
verify_mbist_components -qa_sims on -qa_sims_options -–rtl command.
dft_shell> validate_dft -check verify_mbist_components \
-qa_sims on -qa_sims_options --rtl
Invoking STAR Integrity Checker...
Information: Integrity Check Passed Successfully. Please check
sim_des_unit_core/star_intergrity_checker.log for more details.
Invoking QA simulations...
Information: Simulation option "--rtl"

Information: Simulating component
"des_unit_core_wrap_sadclsgq4l1p4096x40m16b1w0c0p0d0t0s2sdz0rw00_1"
Information: Simulating component "des_unit_core_proc_1"

T-2022.03-SP3
Feedback
Simulating the BIST System
Simulating the BIST System

To simulate the BIST system, use the validate_dft -check verify_mbist_system
command. This command invokes the Embed-It! STAR Verifier tool and does a simulation-
based (VCS) check to validate the complete BIST system.
The Embed-It! STAR Verifier tool uses the <design_name>_ya_files files generated by the
validate_dft command as input to generate BIST patterns. The Embed-It! STAR Verifier
tool also generates the testbench for the generated BIST patterns. The BIST patterns and
the testbenches are written to the verifier_project directory. The simulation files are written
to the verifier_project_simulation directory.
You can specify the following options with the validate_dft -check
verify_mbist_system command:
• -testbench generate_only: This option generates the BIST patterns and

testbenches.
• -testbench simulate_only: This option simulates the testbench for the generated
BIST patterns.
By default, the validate_dft -check verify_mbist_system command generates the
testbench and simulates them as well.
Specify the -simulation_models or -simulation_models_sourcelist option with the
set_mbist_configuration command before executing the generate_dft command to
run the check.
Example Script: Overall Flow

The following is an example script for the overall SMS flow.
#Setup
set design des_unit_core
#Read the memory NDMs

create_lib -ref_libs {<memory_ndm> <std_cells.ndm>} $design.nlib
#Read the design

analyze -f sverilog [glob RTL/*] elaborate $design set_top_module \
$design

create_clock -name clkgrp_user_500 -period 2 -waveform {0 1 } { clk500}
create_clock -name clkgrp_user_1000 -period 1 -waveform {0 .5} \
{ clk1000}
create_clock -name ate_clk -period 1 -waveform {0 .5} { ate_clk }
create_generated_clock -name DIV2_CLK [get_pins memory_inst/divider_inst/

T-2022.03-SP3
Feedback
Example Script: Overall Flow
out_clk] -source ate_clk -divide_by 2 -master_clock ate_clk -add
#Case for memory clock propagation (Clock gate enable)

set_case_analysis 0 RST
#Enable BIST client

#Define the number of memories per shared wrapper

set_mbist_configuration -max_mem_num_per_wrapper 4
#Define the maximum number of memories per processor

set_mbist_configuration -max_mem_num_per_proc 11
#Directory where the SMS components are written to

set_mbist_configuration -project_name $design\_compout
#Directory that contains memory behavioral models required for SMS

simulations
set_mbist_configuration -simulation_models
"memory_simulation_models_path"
#Directory that contains the memory MASIS files

set_mbist_configuration -masis_files "masis_directory_path"
#Directory that contains the SMS compilers set_mbist_configuration

set_mbist_configuration -compiler_libraries "-compiler_libraries_path"
#Define the shadow server

set_dft_access_element -type shadow_server
#Generate the memory grouping information (ish file configuration based

on user configuration)
plan_dft
#Generate the SMS/Access components

generate_dft
#Integrate the SMS/Access components into the design

connect_dft
#Command to write out the SMS constraints

write_dft_constraint -sms -sms_outdir SMS_constraints
#Verify the connections made by Gensys

validate_dft -check connectivity
#Verify the connectivity between SMS/SHS components using Integrity

Checker
#Simulate the SMS/SHS inserted design BIST algorithms
validate_dft -check verify_mbist_components -check verify_mbist_system

T-2022.03-SP3
Feedback
6
Flow for Hierarchical Design
This topic describes how to enable the TestMAX SMS hierarchical flow and read the core-
level SMS-generated components.
To learn about the TestMAX SMS flow for hierarchical designs, see
• Hierarchical Flow Diagram
• Enabling the Hierarchical Flow
• Configuring BIST in the Hierarchical Flow
• Reading Lower-Level SMS-Generated Components
• Hierarchical Flow With Subserver
• Hierarchical Flow With Server and TAP Controller
Hierarchical Flow Diagram

The following figure shows the TestMAX SMS hierarchical flow.

T-2022.03-SP3
Feedback
Chapter 6: Flow for Hierarchical Design
Enabling the Hierarchical Flow
Figure 32 High-Level Flow Chart for Hierarchical Design
Set up DFT
Read RTL design files and NDMs for
memories and standard cells
Read test models of lower hierarchies
Plan DFT (plan_dft)

and memory grouping

Generate SMS components such as
processors, wrappers, and server

the RTL design

Check structure and connection
between SMS-generated components,
generate patterns, and simulate
SMS-inserted design
Enabling the Hierarchical Flow

To enable the TestMAX SMS hierarchical flow, use the set_dft_configuration
command with the -dft_access enable_mbist option.
Example:
set_dft_configuration -dft_access enable_mbist

T-2022.03-SP3
Feedback
Configuring BIST in the Hierarchical Flow

To define the BIST parameters for the design, use the set_dft_access_configuration
command .
For configuring BIST, use the following options with the set_dft_access_configuration
command:
• -allow_module_override: Allows multiple definitions of module for VCS during the
simulation of the modified (BIST-inserted) design
Example:
set_dft_access_configuration -allow_module_override on/off
• -builder_config: Specifies the path to the STAR Builder configuration file (RCL file).
Example:
set_dft_access_configuration -builder_config_file insert.rcl
Use this option to specify the configuration file (RCL file) for the STAR Builder tool.
The generate_dft -generate_connnections command uses this configuration
file when launching the STAR Builder tool. By default, this option is set to
sms_generate_dft_default.rcl.
• -compiler_libraries: Lists the directories containing the TestMAX SMS compiler

libraries.
Example:
set_dft_access_configuration -compiler_libraries "../complib.6x"
• -compout_path: Specifies the directory where the TestMAX SMS components

generated by the Embed-It! STAR Integrator tool are written out. By default, this option
is set to the project_name/compout directory.
Example:
set_dft_access_configuration -compout_path $design\compout
• -integrator_config: Specifies the path to the STAR Embed-it! Integrator

configuration file (ISH file).
Example:
set_dft_access_configuration -integrator_config_file ./scripts \
/shell_project.ish
Use this option to specify the configuration file (ISH file) for the Embed-It!
Integrator tool. The generate_dft command uses this configuration file when

T-2022.03-SP3
Feedback
launching the STAR Embed-It! Integrator tool. By default, this option is set to
scripts/project_name.ish.
• -max_mem_num_per_proc: Specifies the number of memories per processor.
Example:
set_dft_access_configuration -max_mem_num_per_proc 11
• -max_mem_num_per_wrapper: Specifies the number of memories per wrapper.

Example:
set_dft_access_configuration -max_mem_num_per_wrapper 4
• -planner_config: Specifies the path to the user-defined configuration file for the
Embed-It! STAR Planner tool.
Example:
set_dft_access_configuration -planner_config_file ./planner.tcl
The plan_dft command uses the planner configuration file when launching the STAR
Planner tool. By default, the plan_dft command generates the Embed-It! STAR
Planner configuration file. If you use this option to specify a user-defined planner
configuration file, you must also specify the -project_name option.
• -project_name: Specifies the project name of the Embed-It! STAR Planner tool. This
also specifies the path where the SMS components generated by the Embed-It! STAR
Integrator tool are written out.
Example:
set_dft_access_configuration -project_name $design\_compout
• -simulation_models: Lists the directories containing the memory simulation models

or other simulation model files.
Example:
set_dft_access_configuration -simulation_models "../simulation_models"
• –simulation_models_sourcelist: Specifies the list of directories that contain the

source files. Each source file contains the design files and other options (such as
+define), which are used for simulation.
Example:
set_dft_access_configuration –simulation_models_sourcelist {./pad.f}
• -simulation_scripts: Specifies the path to the Integrity Checker simulation script.

The default is sim_<design_name>.

T-2022.03-SP3
Feedback
Reading Lower-Level SMS-Generated Components
Example:
set_dft_access_configuration -simulation_scripts sim_top_block
• -sverilog_extensions: Identifies System Verilog files.

Example:
set_dft_access_configuration -sverilog_extensions [list sv sv1]
• -verifier_options: Specifies options for the script file used for simulating the
modified design.
Example:
set_dft_access_configuration -verifier_options –real
design_list_svlog/*_ya_files/design_sv.lst
• -verifier_script: Specifies the path to the STAR Verifier simulation script.

Example:
set_dft_access_configuration -verifier_script \
verifier_project_simulation/run_sim.scr
• -verilog_extensions: Identifies Verilog files.

Example:
set_dft_access_configuration -verilog_extensions [list v v1]
Note:
If both the BIST and dft_access (hierarchical) flows are enabled, the
dft_access flow gets higher priority for common options.
Reading Lower-Level SMS-Generated Components

To specify the SMS-generated test models of the lower blocks, use the read_test_model
command. Use the following options to control the behavior of the read_test_model
command:
• -format ict|wks|hdl: Specifies the type of test model.
◦ ict: compout directory. For lower-level BIST cores, specify the file at a higher level
of the design hierarchy.
◦ wks: Workspace file path. For lower-level BIST cores, specify the file at a higher
level of the design hierarchy.
◦ hdl: Stub file path of the lower blocks.

T-2022.03-SP3
Feedback
Hierarchical Flow With Subserver
• -design: Specifies the top module name of the design.

Example:
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 \
-design des_unit_core
Hierarchical Flow With Subserver

The following is an example script for the TestMAX SMS hierarchical flow with a subserver.
#Setup
set design subsystem
#Read the memory NDMs

#Read the design

analyze -f sverilog .//user_core_work_area/core/output \
/core_top_module_name.v
elaborate $design set_top_module $design
#Define clock commands

create_clock -name mem_clock_subsystem -period 2 -waveform {0 .5} \
{ clk500 }
#Enable SHS client

#Enable BIST client

#Define the subserver

set_dft_access_element -type sub_server

set_mbist_access_configuration -masis_files "masis_directory_path"
#Directory that contains the SMS compilers

set_dft_access_configuration -compiler_libraries \
"compiler_libraries_path"
#Directory that contains the memory behavioral models required for SMS
simulations
set_dft_access_configuration -simulation_models \
"memory_Simulation_models_path"

T-2022.03-SP3
Feedback
Hierarchical Flow With Server and TAP Controller

#Read the core level components(ICT and WKS)

read_test_model /<user_core_run_path>/$design_srv_1.ict.zip -format ict \
-design $design ##($design is top_module_name_at_core_level) \
read_test_model /<user_core_run_path>/$design.wks -format wks -design \
$design ##($design is top_module_name_at_core_level)
read_test_model /<user_core_run_path>/output/stub/$design.v -format hdl \
design $design ##($design top_module_name_at_core_level)
#Generate the memory grouping information (ISH file generation based on

user configuration)
plan_dft
#Generate the SMS/SHS components

generate_dft
#Integrate the SMS/SHS components into the RTL design

connect_dft
#Write out the SMS constraints

#Verify the connections made by Gensys

validate_dft -check connectivity

checker
validate_dft -check verify_mbist_components

validate_dft -check verify_mbist_system
For information about writing the TestMAX SMS DFT constraints, see Writing the TestMAX
SMS DFT Constraints.

The following topics describe the hierarchical flow with server and TAP controller:
• Enabling the TAP IP Configuration
• Hierarchical Flow With Server
Enabling the TAP IP Configuration

Enable the test access port (TAP) IP at the system level. To enable the TAP IP, use the
set_bsd_configuation command with the -bsd enable option.

T-2022.03-SP3
Feedback
The set_dft_signal command identifies IEEE 1149.1 TAPs by placing an attribute on the
specified port. The attribute value is the same as the signal type keyword.
To define each TAP you intend to create in your boundary-scan design, use the
set_dft_signal command.
set_dft_signal -view [spec|existing_dft] -type signal_type \
-port port_list -hookup_pin pad_output_name
Table 1 Test Signals
Signal Type Description

Keyword
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)

Example:
set_dft_configuration -bsd enable
set_bsd_configuration -ir_width 4
set_dft_signal -type Tdi -port TDI -view spec
set_dft_signal -type Tdo -port TDO -view spec -active_state 1
set_dft_signal -type Tck -port TCK -view spec
set_dft_signal -type Tms -port TMS -view spec
set_dft_signal -type Trst -port TRSTN
set_bsd_instruction SMS_SEL -code 1000 -register SERVER1
-length 1
Hierarchical Flow With Server

The following is an example script for the TestMAX SMS hierarchical flow with the server.
#Setup
set design <top_module_name>
#Read the design

analyze -fsverilog/<user_subsystem_worklog_area>/output/stub/subsystem.v
\
analyze -f sverilog /user_core_work_area/core/output/top_module_name.v \
elaborate $design

T-2022.03-SP3
Feedback
set_top_module $design setup_rtl_flow

create_clock -name clk1000_grp -period 1 -waveform {0 .5} \
{ i_pll_top/ pll_clk_out }
create_generated_clock -name SOC_DIV2_CLK [get_pins \
i1_frequency_divider_by2/out_clk] -source pad_clk_50MHz -divide_by 2
#Case for PLL clock propagation

set_case_analysis 0 pll_bypass_en #SHS client enable
#Enable BIST client

#Enable client for JATG TAP insertion

set_dft_configuration -bsd enable
#Define efuse logic in the server

set_dft_access_element -type top_server -parameter [list efuse default]

set_dft_acecss_configuration -masis_files "masis_directory_path"
#Directory that contains the SMS compilers

set_dft_access_configuration -compiler_libraries
"compiler_libraries_path"
#Directory that contains the memory behavioral models required for SMS
simulations
set_dft_access_configuration -simulation_models
"memory_Simulation_models_path"

#Read the core and subsystem level components(ICT and WKS)

read_test_model /<user_core_run_path>/$design_srv_1.ict.zip -format ict
-design $design ##($design is top_module_name_at_core_level)
read_test_model /<user_core_run_path>/$design.wks -format wks -design
$design ##($design is top_module_name_at_core_level)
read_test_model /<user_core_run_path>/output/stub/$design.v -format hdl \
design $design ##($design is top_module_name_at_core_level)
read_test_model /<user_subsystem_run_path>/$design_srv_1.ict.zip -format
\
ict -design $design ##($design is top_module_name_at_subsystem_level)
read_test_model /<user_subsystem_run_path>/subsystem.wks -format wks
-design $design ##($design is top_module_name_at_subsystem_level)
read_test_model ../subsystem/output/stub/subsystem.v -format hdl -design
$design ##($design is top_module_name_at_subsystem_level)
#Boundary scan configuration details

set_bsd_configuration -ir_width 4

T-2022.03-SP3
Feedback
set_dft_signal -type tdi -port TDI -view spec set_dft_signal -type tdo \
-port TDO -view spec
set_dft_signal -type tck -port TCK -timing [list 45 55] -view spec \
set_dft_signal -type tms -port TMS -view spec
set_dft_signal -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
#Generate the memory grouping information (ISH file generation based on

user configuration)
plan_dft
#Generate the SMS/SHS components

generate_dft
#Integrate the SMS/SHS components into the design

connect_dft
#Write out the SMS constraints

validate_dft -check_connectivity

Checker
validate_dft -check verify_mbist_components

validate_dft -check verify_mbist_system

T-2022.03-SP3
Feedback
7
Custom BIST Algorithm
Embedded memories occupy the largest part of the chip area. Memories are structured
and designed tightly to the limits of the technology. This makes memories more prone to
failures than logic. Memory test algorithms must cover the fault models corresponding to
the target fabrication process and memory design.
Some fault models are not known during the design of the product. The flexibility that
allows you to select memory test algorithms on-the-fly during silicon debug helps you to
identify unexpected failures in the fabrication process. Programmable memory BIST allows
you to select memory test algorithms that cover a wide variety of faults, thereby reducing
area cost. The FSM-based BIST solution is used to customize BIST algorithms.
To learn more about BIST algorithm programmability, see
• FSM-Based BIST
• BIST Controller Hardware Components and Programmable Sources
• Programmability Execution Flow
• Customizing BIST Algorithms
• Test Algorithm Programmability: Use Cases
FSM-Based BIST
Finite state machine (FSM) based BIST allows you to select the test algorithm from a
predetermined set of algorithms using macro commands. The test algorithm is generated
through a set of march elements. This solution has two FSMs: one selects the test
algorithm and the other controls the read/write operation. This solution reduces area and
test time.
The FSM-based BIST controller supports
• Hard algorithm programmability: During the design, either Synopsys-programmed or
user-programmed memory test algorithms can be hardwired into the BIST controller.
Any of these algorithms can be applied to each memory through run-time control. Test
time can be optimized by selecting shorter test algorithms for wafer sort on the ATE.

T-2022.03-SP3
Feedback
Chapter 7: Custom BIST Algorithm
BIST Controller Hardware Components and Programmable Sources
• Soft or field algorithm programmability: User-programmed memory test algorithms can

be downloaded to the BIST controller during in-system testing or while on the ATE.
This capability allows you to test the fabrication-related defects without a design respin.
This capability provides automation to download the algorithm through a TAP or a
specified CPU interface.
BIST Controller Hardware Components and Programmable

Sources
The following hardware components allow you to program BIST controller algorithms in
the TestMAX SMS processor.
• Hardware algorithm container: Stores the test algorithms hardwired in the processor.
• Test algorithm FSM: Stores and executes hardwired algorithms and also contains the
test algorithm register (TAR).
• Test string register (TSR): Contains a single march element. Executes a short single
march element algorithm for initialization or fast execution.
• BIST FSM: Executes the single march element stored in the TSR or hardwired in the
test algorithm (TA) FSM. Generates control signals, addresses, and data sequences for
the wrapper.
The following figure shows the test algorithm sources that can be programmed.
Figure 33 Test Algorithm Sources

STAR Processor
Test algorithm register

IEEE 1500
Test string register
Hardwired test algorithm 1

Test algorithm
selection register
Hardwired test algorithm n
ALGO_SEL
BIST engine
TBOX_SEL

T-2022.03-SP3
Feedback
BIST Controller Hardware Components and Programmable Sources
The test algorithm sources are described in the following topics:

• Test Algorithm Selection Register
• Hardwired Test Algorithm
• Test Algorithm Register
• Test String Register
Test Algorithm Selection Register

Test algorithm selection register (ASR) is a serially accessible register for selecting the
algorithm sources for programming.
To select one of the available algorithm sources, use the ALGO_SEL processor instruction.
The ASR must be loaded with the opcode of the algorithm source. For more information,
see the Processor Compiler User Guide.
Hardwired Test Algorithm

TestMAX SMS allows multiple test algorithms to be hardwired in the processor RTL code.
User-defined and manufacturing algorithms can be selected as hardwired algorithm at the
test patterns generation stage. Each of these algorithms is assigned a specific code that is
loaded to the ASR to select the hardwired algorithm for execution.
Test Algorithm Register

A TAR is a serially accessible register for programming user-defined or manufacturing test
algorithms. To access and program a TAR, use the TBOX_SEL processor instruction. For
more information, see the Processor Compiler User Guide.
Test String Register

A TSR is a serially accessible register for programming and executing a single march
element test algorithm. To access and program a TSR, use the TREG_SEL processor
instruction. For more information, see the Processor Compiler User Guide.

T-2022.03-SP3
Feedback
Programmability Execution Flow

The following topics describe the different programmability configurations in which you can
run BIST:
• Running BIST With a Hardwired Algorithm
• Running BIST With Multiple Algorithms in TAR
• Running BIST With a User-Defined March Element
Running BIST With a Hardwired Algorithm

To run BIST with a selectable hardwired algorithm:
1. Select the ASR.
2. Load the ASR with the opcode of the hardware algorithm that is selected as the
algorithm source.
3. Load the wrapper instruction register (WIR) with the BIST_RUN instruction and execute.
4. Wait for the instruction to complete.
5. Read out the status register.
Figure 34 BIST Run With Default and Selectable Hardwired Algorithm
BIST run with default hardwired BIST run with selectable

algorithm hardwired algorithm
BIST_RUN ALGO_SEL
WAIT Load code for hardwired algorithm
SHIFT_STATUS BIST_RUN
WAIT
SHIFT_STATUS

T-2022.03-SP3
Feedback
Running BIST With Multiple Algorithms in TAR

To run BIST with multiple programmable algorithms in the TAR:
1. Select the TAR.
2. Load the TAR with the user-defined or manufacturing algorithm.
3. Load the WIR with the BIST_RUN instruction and execute.
Figure 35 BIST Run With Default and Multiple Programmable Algorithms in TAR
BIST run with default algorithm BIST run with multiple programmable
in TAR algorithms in TAR
TBOX_RST TBOX_SEL
ALGO_SEL and load value to Load ALGO_CODE in TAR

select TAR
BIST_RUN BIST_RUN
WAIT WAIT
SHIFT_STATUS SHIFT_STATUS
Running BIST With a User-Defined March Element

To run BIST with a user-defined march element:
1. Select the TSR.
2. Load the TSR with the user-defined march element.
3. Load the WIR with the BIST_RUN instruction and execute.

T-2022.03-SP3
Feedback
Customizing BIST Algorithms

Figure 36 BIST Run With Predefined and User-Defined March Element

BIST run with march element BIST run with user-defined
predefined in TSR march element
TREG_RST TREG_SEL
ALGO_SEL ALGO_SEL
TSR_CODE MARCH_ELEMENT_CODE
BIST_RUN BIST_RUN
WAIT WAIT
SHIFT_STATUS SHIFT_STATUS

The following topics describe the user interface used in customizing BIST algorithms:
• Enabling the Hardware
• Customizing Hardwired and Soft Programmable Test Algorithms
• Generating Test Algorithm Reports
• Predefined Algorithms
• Generating Test Patterns
• Validating Test Patterns

T-2022.03-SP3
Feedback
Enabling the Hardware

To enable the hardware, use the set_mbist_configuration command.
You can specify the following options with the set_mbist_configuration command:
• -custom_algorithm on|off: The tool sets the following SMS parameters in the ISH
file when the value is on:
◦ talgo_prog_enable TRUE
◦ treg_enable TRUE
◦ treg_algo TRUE
• -load_user_defined_algorithms [list file1.alg file2.alg …]: The tool loads

the user-defined algorithms in the .alg format. The tool sets the user_defined_test
[NAME1 NAME2…] SMS parameter in the ISH file.
• -test_register_size auto|n|hardwired_algorithm_size: You can pass the

following arguments to this option:
◦ auto: Register length is the largest of the lengths of the user-loaded algorithms and
the internal algorithm
◦ n: User-defined test algorithm register size
◦ hardwired_algorithm_size: The TAR is limited to the hardwired algorithm only

and the programmable algorithm is split. This reduces additional area overhead.
Customizing Hardwired and Soft Programmable Test Algorithms

To customize hardwired and soft programmable test algorithms, use the
set_dft_access_element command. The syntax of the command is as follows:
set_dft_access_element -type processor|mmb_processor|cam_processor
-module module_name
-algorithm [list -default NAME -hardwired NAME1 NAME2…
-soft_programmable NAME3 NAME4…]
You can use the following options with the set_dft_access_element command:
• -type: Specifies the type of processor.
◦ processor: SMS processor
◦ mmb_processor: MMB processor
◦ cam_processor: CAM processor
• -module: Specifies the module name of the generated SMS IP

T-2022.03-SP3
Feedback
• -algorithm: The list of hardwired and soft programmable test algorithms
◦ -default: Specifies the default algorithm. The default algorithm must be one
among the algorithms specified for the -soft_programmable and -hardwired
options.
◦ -hardwired: Specifies the hardwired algorithms
◦ -soft_programmable: Specifies the soft programmable algorithms
Use the command multiple times to give different settings to different processors. Ensure
that the same algorithm is not defined in both hardwired and soft programmable algorithm
lists.
The set_dft_access_element command sets the following SMS parameters in the ISH
file:
• hardwired_test = [NAME1 NAME2…]
• default_algo_name = NAME
• selected_tests = [NAME3 NAME4…]
Generating Test Algorithm Reports

To generate test algorithm reports, use the report_mbist_configuration command.
The syntax of the command is as follows:
report_mbist_configuration -algorithm userdefined | predefined | all
To get the list of predefined and user-defined algorithms, run this command before and
after running the set_dft_access_element command.
Specify one of the following values with the -algorithm option:
• userdefined: Reports the list of custom algorithms loaded using the
-load_user_defined_algorithm option.
• predefined: Reports the list of predefined algorithms supported by the TestMAX SMS
tool. The -selected_tests list… option in the ISH file generates processor output
views in the algo_name.alg file in the algos folder.
• all: Reports the complete list of user-defined and predefined algorithms.
Predefined Algorithms
Table 2 lists the field and manufacturing test algorithms for memories.

T-2022.03-SP3
Feedback
Table 2 Field and Manufacturing Test Algorithms
Test Memory Type Fault Coverage Comments

Algorithm
VLSP Single-port • Traditional faults Recommended default algorithm

• Address decoder faults for single-port memories
• Static unlinked faults
• Static linked faults
• Bit write enable faults
• Bitline leakage faults
• Memory enable faults
VLMP Multi-port • Traditional faults Recommended default algorithm

• Address decoder faults for multi-port memories (when
• Static unlinked faults the memories are targeted by
• Static linked faults the processor for testing)
• Bit write enable faults
• Bitline leakage faults
• Memory enable faults
Inter-port faults
• Static weak faults
VLP1 Single-port / • Two-operation dynamic Recommended to ensure

Multi-port unlinked faults two-operation dynamic fault and
• Delay coupling faults delay coupling fault coverage
VLP2 Single-port / • Two-operation dynamic Recommended to ensure

Multi-port unlinked faults two-operation dynamic fault and
• Delay coupling faults delay coupling fault coverage
VLP3 Single-port / Two-operation dynamic unlinked Recommended to ensure

Multi-port faults two-operation dynamic fault
coverage
VLP4 Single-port / Data path faults Recommended

Multi-port
VLP5 Single-port / Address decoder activation Recommended

Multi-port delay faults
VLP6 Single-port / Bit write enable faults Recommended

Multi-port
VLP7 Single-port / Address decoder deactivation Recommended for memories

Multi-port delay faults with single-bank or multi-bank
structure, where the column
decoder is common for all banks
VLP8 Single-port / Address decoder deactivation Recommended when VLP7 is

Multi-port delay faults selected

T-2022.03-SP3
Feedback
Table 2 Field and Manufacturing Test Algorithms (Continued)

Algorithm
VLP9 Single-port / Address decoder activation VLP5 provides the necessary

Multi-port delay faults coverage for address decoder
activation delay faults. Not
recommended because it might
add additional stress to the
background.
VLP10 Single-port / Memory biasing faults Recommended

Multi-port
VLP11 Multi-port • Memory read-write contention Recommended when testing

faults multi-port memories
VLP12 Multi-port • Memory read-write contention Recommended when testing

faults multi-port memories
VLP13 Single-port / • Address decoder activation Traditional GALPAT algorithm.

Multi-port delay faults Not recommended because the
• Address decoder deactivation complexity of the test algorithm
2
delay faults is 0 (N ). The faults covered
by this test algorithm are also
covered by VLP5, VLP7, VLP8,
and VLP15.
VLP14 Single-port / Address decoder activation Traditional walking 1/0

Multi-port delay faults algorithm. Not recommended
because the complexity of
2
the test algorithm is 0 (N ).
The faults covered by this test
algorithm are also covered by
VLP5.
VLP15 Single-port / Address decoder deactivation Recommended for multi-bank

Multi-port delay faults memories, where each bank has
its own column decoder (if VLP7
and VLP8 are not selected)
VLP16 Multi-port Write dominance faults Recommended for multi-port

memories having write-dominant
port
VLP17 Single-port Write-thru faults Recommended for single-port

memories supporting
write-through operation
VLP18 Single-port / Bank address decoder faults Recommended for multi-bank

Multi-port memories

T-2022.03-SP3
Feedback
Table 2 Field and Manufacturing Test Algorithms (Continued)

Algorithm
VLP19 Single-port / Read-write mask faults Recommended for memories

Multi-port having common read-write
enable mask
VLP20 Single-port / Write enable faults Recommended for memories

Multi-port having write-enable bus
VLP21 Single-port / Links between static and Recommended for testing links
Multi-port dynamic faults between static and dynamic
faults
VLP22 Multi-port Bitline precharge faults Recommended
Generating Test Patterns

To generate test patterns, use the create_mbist_pattern command with the -name,
-algorithms, and -sms_list options.
• -name: Specifies the name of the pattern.
• -algorithm: Specifies the list of algorithms for which patterns are generated.
• -sms_list: Specifies the list of processors on which the defined algorithm patterns are
generated.
For example, three processors P1, P2, and P3 support the following algorithms:
• P1 – A1, A2, and A5
• P2 – A3 and A5
• P3 – A1, A5, and A6
Consider the case where the processors must run the following algorithms:
• P1 – A1
• P2 – A5
• P3 – A6
In this case, run the following commands:
create_mbist_pattern -name SMS_Pat_1 -algorithms [list A1] \
-sms_list [list P1]
create_mbist_pattern -name SMS_Pat_2 -algorithms [list A3 A5] \

T-2022.03-SP3
Feedback
Test Algorithm Programmability: Use Cases
-sms_list [list P2]

create_mbist_pattern -name SMS_Pat_3 -algorithms [list A5] \
-sms_list [list P3]
Deleting Test Patterns

To delete an existing test pattern, use the delete_mbist_pattern command with the
-name option, as shown in the following example:
delete_mbist_pattern -name pattern_1
Validating Test Patterns

To validate test patterns, use the validate_dft command.
You can specify the following options with the validate_dft command:
• -check verify_mbist_system
• -verify_patterns {list_of_pattern_names}: Used while generating BIST

patterns
• -execution_type serial|parallel
If you specify only the -check_verify_mbist_system option, the tool executes all
hardwired algorithms in parallel.
Test Algorithm Programmability: Use Cases

Use Case 1
Test algorithm programmability is disabled for all processors.
set_mbist_configuration -custom_algorithm disable
Use Case 2
Test algorithm programmability is partially enabled. Only multiple hardwired algorithms are
selected.
set_dft_access_element [list proc1] -type processor \
-parameter [list talgo_prog_enable true treg_enable false]
Use Case 3
Test algorithm programmability is enabled for soft and hardwired algorithms.
set_mbist_configuration -custom_algorithm enable

T-2022.03-SP3
Feedback
8
BIST Production Patterns
To learn about generating BIST production patterns, see
• Generating BIST Patterns Using STAR Yield Accelerator
• TestMAX Manager Support for BIST Pattern Generation
• Predefined Patterns
• Creating BIST Production Patterns
• Predefined Patterns: Use Cases
Generating BIST Patterns Using STAR Yield Accelerator

BIST test patterns can be customized at two stages:
• Pre-silicon: Test patterns are generated based on the memory configuration
• Post-silicon: Test patterns are generated based on the silicon defects
The STAR Yield Accelerator tool provides the ability to test, diagnose, and repair SMS IP
cores embedded within an SoC. The Yield Accelerator tool contains the following in-built
tools:
• STAR Verifier: Generates a top-level testbench and performs full-chip verification of the
pre-silicon design.
• STAR Vector Generator: Generates customized manufacturing test patterns in different
tester formats such as STIL and WGL.
• Silicon Debugger: Processes tester output log files and provides detection, localization,
and classification of errors, failures, and faults, which allows you to perform repair
analysis.
• STAR Silicon Browser: Enables silicon bring-up and memory characterization of target
chips.

T-2022.03-SP3
Feedback
Chapter 8: BIST Production Patterns
TestMAX Manager Support for BIST Pattern Generation
Figure 37 Yield Accelerator: Design Verification, Test Manufacturing, and Diagnosis

SoC w/SMSN SMSN.xml
UDS
User defined Chip/TAP
parameters
STAR Yield Accelerator
STAR Verifier STAR Vector ATE Silicon

Generator Debugger
Chip-level testbench Manufacturing test vectors Information about failures,

faults, and defects and repair

TestMAX Manager supports both the STAR Verifier and STAR Vector Generator tools.
STAR Verifier
• Performs pre-silicon full-chip validation
• Generates a chip-level Verilog testbench
• Enables Verilog pattern generation
◦ Fault injection
◦ Redundancy usage simulation
For pre-silicon validation, TestMAX Manager uses the validate_dft -check
verify_mbist_system command.

T-2022.03-SP3
Feedback
Figure 38 STAR Verifier: Input and Output
SMSN model (compout) STAR Verifier Generated output
Chip parameters file (.cpf)

Verilog pattern (.vb)
UDS file (.uds)
Top-level Verilog testbench
(<chip_name>_tb.v)
Hierarchical path log file (.txt)
Fault injection Verilog files
Fault injection template (.vb)
(fault_injection.inj)
chip_paths.vb
Fault injection files (.inj)
run_sim.scr
design_real.lst
design_virtual.lst
STAR Vector Generator

• Manufactures test patterns
• Automates pattern generation (STIL and WGL)
• Generates stop-on-nth-error (SONE) patterns
• Manipulates algorithm and test vectors for silicon analysis

T-2022.03-SP3
Feedback
Predefined Patterns
Figure 39 STAR Vector Generator: Input and Output
SMSN model (compout) STAR Vector Generated output

Generator
TAP parameters file (.tap)
WGL test vectors (.wgl)
UDS file (.uds)
STIL test vectors (.stil)
UDS template
(udsTemplate.uds)
STIL protocol file (.spf)
Cycle number look-up table

(.clt)
Serial vector format (.svf)
Cycle accurate Verilog

pattern (.wgl.patt)
Reserved TAP instruction

code (CustomIR.code)
Look-up table (.soe)
ICL/PDL file (.icl/.pdl)
Predefined Patterns
TestMAX SMS supports the following predefined test patterns:
• Manufacturing
• Memory dump
• Process variation: Tests process variation failures and the corresponding fault models:
read destructive fault (RDF), transition fault (TF), incorrect read fault (IRF) and
destructive fault (DF). The pattern must be run at different PVT corners.
• Production
• Retention: Parallel wait for the selected group of SMS processors between loading and
sequential running of test algorithm segments.
• Random telegraph noise induced failures (RTNF): Runs at low voltages and high
temperatures.
• SONE

T-2022.03-SP3
Feedback
Creating BIST Production Patterns
• Repair verification: Generates instructions to run repair flow for memories.

• Signature register check: Observes the test results by checking the signature registers
for all SMS processors and wrappers.
• Connectivity check: Checks the integrity of clock, reset, and IEEE 1500 circuits for
SMS rings.
• Fast BIST: Generates instructions that identify failing memories within limited address
space.
• Status test: Observes the test results by checking the status registers.
• BIST all: Runs BIST for all SMS processors expecting no fails in SMS memories
including the TBOX_SEL instruction.
• BIST all fail: Runs BIST for all SMS processors expecting no fails in SMS memories
except the TBOX_SEL instruction, which performs write/read operation (W(D), R(~D)).

To create test patterns, use the create_mbist_pattern command. You can specify the
following options with the create_mbist_pattern command:
• -predefined predefined_pattern_name: Specifies the predefined patterns such
as SONE, retention, and manufacturing from the Yield Accelerator tool. For more
information, see the STAR Yield Accelerator SMS User Manual.
• -name pattern_name: Specifies the name of the pattern that is written out.
• -parameters list_of_parameters: List of pattern-specific parameters. For more

information, see the STAR Yield Accelerator SMS User Manual.
• -sms_list proc_and_memory_names: Specifies the SMS processors and memories.
• -fault_inj list_of_fault_injection_files: List of fault injection files from the

STAR Yield Accelerator tool.
• -uds_path uds_file_path: Specifies the path of the user-defined sequence (UDS)
file generated by the tool.
• -custom_instruction_file file_name.txt: Specifies the user-defined file that
contains the sequence of SMS or SHS instructions.
• -user_tcl_file YA_script_path: Specifies the path of the Yield Accelerator script.

T-2022.03-SP3
Feedback
To modify the UDS or chip parameter file (CPF), use the update_dft_setup command.
You can specify the following options with the update_dft_setup command:
• -format format: Specifies the format (UDS or CPF) to be updated.
• -port name: Specifies the existing port name.
• -active_state value: Specifies the value applied to the port during simulation. This
value must match the port width. Test vector ports can also take a single value, which
is applied to all bits.
• -string string_value: For the UDS, it specifies the value of a string applied to a
port. For the CPF, it specifies a key value pair to be added or updated in the selected
CPF section. This option has priority over the -active_state option.
• -sequence FILE_NAME.txt: Specifies the text file containing the test sequence.
• -section string_value: Specifies the section name in the CPF. This option can be
used with the CPF format only.
The following examples show how the UDS or CPF file can be modified:
# Provide the active state value, 1010 to the RST_N port in the UDS file.
update_dft_setup -format uds -port RST_N -active_state "1010"
# Provide the string value, virtual_clk to the CLK_A port in the UDS
file.
update_dft_setup -format uds -port CLK_A -string "virtual_clk"
# Update the my_reset, pll_init, and reset_all sequences using

the ./seq1.txt, ./seq2.txt, and ./seq3.txt files respectively.
update_dft_setup -format uds -sequence \
[list my_reset ./seq1.txt pll_init ./seq2.txt reset_all ./seq3.txt]
# Modify TCK_SHAPE, which is a TAP_OPTION to a value, 0000111110.

update_dft_setup -format cpf -section TAP_OPTIONS -string \
[list TCK_SHAPE 0000111110]
# Assign core_proc_1_1 with the value 1.6 and add it to the RATIOS
section in the CPF file.
update_dft_setup -format cpf -section RATIOS -string \
[list core_proc_1_1 1.6]
The following is an example preview report generated by the plan_dft command.
|--(0) SHADOW_SERVER : des_unit_core_srv_1

|
|--(1) RING : RING_1
|
|--(2) PROCESSOR : des_unit_core_proc_1
|

T-2022.03-SP3
Feedback
|--(3) SMS_WRAPPER :
des_unit_core_wrap_sadsls0c4l2p2048x32m8b1w0c0p0d0r1s2z1rw00_1_gen
|
|--(4) MEMORY :
des_unit_core.memory_core.high_speed_mem_inst_2
|--(4) MEMORY :
|
|--(2) PROCESSOR : des_unit_core_proc_2
|
|--(3) SMS_WRAPPER :
des_unit_core_wrap_sadsls0c4l2p2048x32m8b1w0c0p0d0r1s2z1rw00_2_gen
|
|--(4) MEMORY :
Creating Predefined Patterns

The following are example commands for generating predefined patterns:
SONE
create_mbist_pattern -predefined sone -name sone_pattern \
-parameters { sone_counter 1 } -sms_list { proc_1 {} proc_2 {}} \
-uds_path "des_unit_core2_ya_files/srv_1_uds.uds"
SONE TBOX
create_mbist_pattern -predefined sone_tbox -name sone_tbox_pattern \
-parameters { sone_counter 1 } -sms_list { proc_1 {} proc_2 {} } \
Manufacturing
create_mbist_pattern -predefined manufacturing -name
manufacturing_pattern \
-sms_list { proc_1 {} proc_2 {} } \
Production
create_mbist_pattern -predefined production -name production_pattern \
Connectivity check
create_mbist_pattern -predefined connectivity_check -name \
connectivity_check_pattern -parameters { ringlist 1 } -sms_list \
{ proc_1 {} proc_2 {} } -uds_path "des_unit_core2_ya_files/srv_1_uds.uds"
Signature register check

T-2022.03-SP3
Feedback
create_mbist_pattern -predefined signature_reg_check -name \

signature_reg_check_pattern -sms_list { proc_1 {} proc_2 {} } \
RTNF
create_mbist_pattern -predefined rtnf -name rtnf_pattern \
Process variation
create_mbist_pattern -predefined process_variation -name \
process_varaiation_pattern -parameters { delay 10 } -sms_list \
{ proc_1 {} proc_2 {} } -uds_path "des_unit_core2_ya_files/srv_1_uds.uds"
Retention test
create_mbist_pattern -predefined retention_test -name \
retention_pattern -parameters { delay 100 } -sms_list { proc_1 {} proc_2
{} } \
Repair verification
set_mbist_configuration -fault_inj_path scripts
create_mbist_pattern -predefined repair_verification -name
repair_verification_pattern \
-sms_list { proc_1 {} proc_2 {} } -uds_path
"des_unit_core2_ya_files/srv_1_uds.uds" \
-fault_inj "repair_faults.inj"
Memory dump
create_mbist_pattern -predefined memory_dump -name memory_dump_pattern \
Fast BIST
create_mbist_pattern -predefined fast_bist -name fast_bist_pattern \
Other Commands
To reuse existing Yield Accelerator Tcl scripts through the TestMAX SMS tool, use the
create_mbist_pattern -name user_pattern_1 -user_tcl_file /disk/A/B/
YA_user_pattern_1.tcl command.
To modify the UDS file with a custom init sequence, use the -format UDS -sequence
[list reset ./X/Y/init_seq.txt] option.

T-2022.03-SP3
Feedback
Predefined Patterns: Use Cases
Predefined Patterns: Use Cases

Use Case 1
Create a SONE pattern called sone_pattern. The parameter that is passed for pattern
creation includes the value of the SONE counter. The pattern targets one memory under
the des_unit_core_proc_1 processor and two memories under the des_unit_core_proc_2
processor. The path to the UDS file is provided using the -uds_path option.
create_mbist_pattern -predefined sone -name sone_pattern -parameters
{sone_counter 1} \
-sms_list {des_unit_core_proc_1
{des_unit_core.memory_inst.high_speed_mem_inst_1} \
des_unit_core_proc_2 {des_unit_core.memory_inst.mem_inst1.u_mem
des_unit_core.memory_inst.mem_inst2}} \
-uds_path des_unit_core_ya_files/des_unit_core_srv_1_uds.uds
Use Case 2
Create a SONE pattern called sone_pattern_1. The pattern targets all the memories under
the des_unit_core_proc_1 and des_unit_core_proc_2 processors.
create_mbist_pattern -predefined sone -name sone_pattern_1 \
-parameters {sone_counter 1} -sms_list {des_unit_core_proc_1 {}
des_unit_core_proc_2{}} \
Use Case 3
Create a SONE pattern called sone_pattern_2. The pattern targets all the memories under
the des_unit_core_proc_1 processor.
create_mbist_pattern -predefined sone -name sone_pattern_2 -parameters \
{sone_counter 1} -sms_list {des_unit_core_proc_1{}} \

T-2022.03-SP3
Feedback
9
Customizing BIST
To customize BIST, see
• Clocking Architecture: Use Cases
• IEEE 1500 Clock: WRCK
• Customizing Reset Handling
• Customizing SMS Parameters
• Customizing the Interface
• Customizing Pipeline Stages
• Configuring Wrappers Using the DFT Operations File
• Customizing DFT Mode Signals
• Defining the IEEE 1500 Interface at the Shadow Server or Subserver Level
• Disabling Propagation of Memory Functional Ports and Processor Control Signals
• Custom Memory Grouping
Clocking Architecture: Use Cases

The TestMAX SMS tool supports different clocking architectures. This topic describes a
few customizations.
Use Case 1
The memory has only one clock that is shared between the BIST operation and the
functional operation.
Default behavior of the tool: An additional port is created at the boundary interface to drive
the BIST clock that controls the BIST logic. The MUX logic is inserted in the wrapper to
control the functional clock and the BIST clock. The enable signal that controls the clocks
is also generated by the processor.

T-2022.03-SP3
Feedback
Chapter 9: Customizing BIST
User logic
clk_1 (func)
tclk_sms
vl_sms_*clk1* clk_sms clk (func)
biste
Processor Memory
Wrapper
Customization support: To set the same clock to drive the BIST operation and the
functional operation, use the set_mbist_configuration -setup_options [list
extract_rcl.connect_proc_clocks 1] command.
User logic
clk_1 (func)
tclk_sms
clk_sms clk (func)
biste
Processor Memory
Wrapper
Use Case 2
The memory has a dedicated functional clock and test clock.
the BIST controller.
User logic
clk_2 (func)
tclk_sms

tclk (test)
Processor Memory
Wrapper
Customization support: To set the functional clock to drive the BIST controller operation
and the functional operation, use the set_mbist_configuration command with the
extract_rcl.connect_proc_clocks 1 parameter.

T-2022.03-SP3
Feedback
clk_2 (func)
clk_3 (func)
User logic
tclk_sms
clkb (func)
clk_sms
clka (func)
tclka tclka (test)
tclkb tclkb (test)
Processor
Wrapper Memory
Use Case 3
The memory has a dedicated functional clock and test clock. The functional clock is
controlled by the PLL.
the BIST controller.
PLL
tclk_sms

tclk (test)
Processor Memory
Wrapper
Customization support: To set the functional clock to drive the BIST controller operation
and the functional operation, use the set_mbist_configuration command with the
extract_rcl.connect_proc_clocks 1 parameter.
PLL
User logic
tclk_sms
clk_sms clk (func)

tclk (test)
Processor Memory
Wrapper

T-2022.03-SP3
Feedback
IEEE 1500 Clock: WRCK

The TestMAX SMS tool handles the IEEE 1500 (WRCK) clock at different levels as shown
in the following figures.
Figure 40 Core Level

Core
vl_sms_WRCK WRCK
Processor 1
WRCK
Processor 2
WRCK
Processor 3
Figure 41 Subsystem Level

Subsystem Subsystem
vl_srv_WRCK
vl_srv_WRCK
Core Core
vl_sms_WRCK vl_sms_WRCK
WRCK WRCK
Processor 1 Processor 1
WRCK WRCK
Subserver Processor 2 Processor 2
WRCK WRCK
Core Core
vl_sms_WRCK vl_sms_WRCK
WRCK WRCK
WRCK WRCK
WRCK WRCK
WRCK WRCK

T-2022.03-SP3
Feedback
Figure 42 SoC Level
Subsystem
TCK
Test CLK
Core
Pad vl_sms_WRCK
MUX
WRCK
(functional)
vl_srv_WRCK
In-system CLK Processor 1
WRCK
Subserver Processor 2
WRCK
WRCK
TCK
Processor 3
TAP
Server
Core
vl_sms_WRCK
WRCK
Processor 1
WRCK
Processor 2
WRCK
Test CLK
MUX WRCK
eFUSE Processor 1
(functional)
In-system CLK Processor 3
Subsystem
Core
vl_sms_WRCK
WRCK
vl_srv_WRCK
Processor 1
vl_sms_WRCK WRCK
Processor 2
Core
WRCK
WRCK
Processor 1
Processor 3
WRCK
Processor 2
Core
vl_sms_WRCK
WRCK WRCK
WRCK
Processor 2
WRCK
WRCK
Processor 1
Processor 3
SoC

T-2022.03-SP3
Feedback
Customizing Reset Handling
Customizing Reset Handling

Default behavior of the tool: Generates a dedicated reset signal for each processor.
Core
vl_sms_WRSTN WRSTN
vl_sms_*proc_1_rst_sms rst_sms
vl_sms_*proc_2_rst_sms Processor 1
rst_sms
vl_sms_*proc_3_rst_sms
Wrapper
WRSTN
rst_sms
Processor 2
rst_sms
Wrapper
WRSTN
rst_sms
Processor 3
rst_sms
Wrapper
Customization support: To merge the RESET signal with WRSTIN, use the
set_mbist_configuration command with the extract_rcl.connect_proc_resets 1
option.

T-2022.03-SP3
Feedback
Customizing SMS Parameters
Core
vl_sms_WRSTN WRSTN
rst_sms
Processor 1
rst_sms
Wrapper
WRSTN
rst_sms
Processor 2
rst_sms
Wrapper
WRSTN
rst_sms
Processor 3
rst_sms
Wrapper
Customizing SMS Parameters

Use the following command to change the SMS processor compiler parameters:
set_dft_access_element -type processor -parameter [list …]
For example, consider this SDC command:

create_clock -name clkgrp_user_1000 -period 1 -waveform {0 .5} {clk 1000}
The ISH file generated after executing the plan_dft command:

component $c set_parameter clk_sms_freq 1000.0
The command to modify the processor clock frequency:

set_dft_access_element -instance my_processor -type processor -parameter
{clk_sms_freq 1500MHz}
The modified ISH file:

component $c set_parameter clk_sms_freq 1500.0

T-2022.03-SP3
Feedback
Customizing the Interface
Customizing the Interface

The -interface option defines the connection of the pins of the SMS components in a pin
conn pair. For each pair, pin is the pin name of the component andconn can be a top-level
port, a hierarchical pin, an empty string (for hanging connections), or a constant (such as
1'b0).
You can use the set_dft_access_element command with the -interface option to
control port propagation in components such as processors, top servers, subservers, and
subchips. The syntax of the command is as follows:
set_dft_access_element -type module_type
-module module_name
-interface [list pin conn]
TestMAX SMS components are connected to higher levels using the RCL file. In the
following example, the user-defined connections of clk_sms, rst_sms, and the DFT mode
bits of two processors are shown.
The default RCL file:
sms $Test_case2_proc_2_sms_2_tcl add_top_level_port "clk_sms" \
"vl_sms_proc_2_sms_2_clk_sms"
sms $Test_case2_proc_2_sms_2_tcl add_top_level_port "rst_sms" \
"vl_sms_proc_2_sms_2_rst_sms"
sms $Test_case2_proc_2_sms_2_tcl add_top_level_port "dm0" \
"vl_sms_proc_2_sms_2_dm0"
sms $Test_case2_proc_1_sms_1_tcl add_top_level_port "dm0" \
"vl_sms_proc_2_sms_2_dm0"
To modify the RCL file, use the following commands:

set_dft_access_element -instance proc_2 -type processor -interface \
{ list clk_sms top_clk_sms rst_sms top_rst_sms dm0 top_dm0}
set_dft_access_element -instance proc_1 -type processor -interface \
{ list dm0 top_dm0}
The modified RCL file:

sms $Test_case2_proc_2_sms_2_tcl add_top_level_port "clk_sms" \
"top_clk_sms"
sms $Test_case2_proc_2_sms_2_tcl add_top_level_port "rst_sms" \
"top_rst_sms"
sms $Test_case2_proc_2_sms_2_tcl add_top_level_port "dm0" "top_dm0"
sms $Test_case2_proc_1_sms_1_tcl add_top_level_port "dm0" "top_dm0"

T-2022.03-SP3
Feedback
Customizing Pipeline Stages
Customizing Pipeline Stages

The TestMAX SMS tool supports customizing the pipeline stages between the various
infrastructure elements of the SMS architecture. This can be done by modifying the
parameter values of the corresponding compilers.
The following figure shows the supported pipelining.
Figure 43 Supported Pipelining

Subsystem
Server Ctrl
Inpipe P
TAP P P
JPC P
P
Processor
P
Int Memory
P
P
SFP P P
P
To control the number of pipeline stages between the TAP and server, use the following
command:
set_dft_access_element -type server -parameter [tap_srv_pipes "N"]
To enable pipelining between the server and the IEEE 1500 rings, use the following
command:
set_dft_access_element -type server -parameter [srv_sms_pipes "N"]
Similarly, to enable pipelining between the wrapper and memory, you can customize
the wrapper parameters such as pipe_lined_bist_inputs,pipe_lined_read, and
pipeline_regs_on_wr_inputs. For more information on the available options, see the
STAR Wrapper Compiler User Guide.
To enable pipelining between the wrapper and memory, use the following commands:
set_dft_access_element -type wrapper -parameter \
[pipe_lined_bist_inputs "N"]
set_dft_access_element -type wrapper -parameter \
[pipe_lined_read "N"]

T-2022.03-SP3
Feedback
Configuring Wrappers Using the DFT Operations File
Configuring Wrappers Using the DFT Operations File

The dft_ops_file parameter allows you to define DFT modes and assign memory inputs
as well as wrapper controls to specific values for each DFT mode. DFT operations are
described through Tcl commands in the dft_ops.tcl file.
Figure 44 Configuring Wrapper Using dft_ops_file
The following is an example for the STAR Embed-It! Integrator ISH command:
component wrapper_name set_parameter dft_ops_file
“/remote/user/my_dft_operation_files/sample_dft_operations.tcl”
DFT operations in the dft_ops.tcl file must be specified using the following format:
set dft_op_table(dft_mode_name:dm_pin_values)
{memory_port_name:port_value … wrapper_control_name:ctrl_value}
set dft_insertion_mode dft_insertion_mode_name
The following parameters are used to specify the DFT operations:

• dft_mode_name: Name of the user-specified DFT mode.
• dm_pin_values: Represent the values of dm2, dm1, and dm0 signals for which
dft_mode_name is activated. 000 is reserved for BIST and functional modes and
cannot be specified in the DFT table.
• memory_port_name: Name of the memory port assigned to port_value during DFT
mode.
• wrapper_control_name: Name of the wrapper control signal assigned to ctrl_value
during DFT mode.

T-2022.03-SP3
Feedback
Customizing DFT Mode Signals
• port_value and ctrl_value: The values to which the memory port or the wrapper
control signal is assigned during DFT mode. port_value and ctrl_value can be
either binary digits (such as 0, 1, or 1010), force_active, or force_inactive.
If the force_active or force_inactive argument is used, the wrapper automatically
detects the memory port active level from the MASIS file (based on the ActiveLevel or
SafeValue parameter) or uses High (1) and Low (0) by default if the parameters are not
specified in the MASIS file.
• dft_insertion_mode_name: Name of the DFT mode for which the scan insertion is
done. The mode must be set as one of the modes specified by the dft_op_table
parameter.
For example,
set dft_op_table(bist_basic_ATPG:100) {DFTMODE:1}
set dft_op_table(mem_bypass_ATPG:010)
{TD:force_inactive wr_tclk_en_int:force_active
RME:force_active RM:force_inactive DFTMODE:force_active
mem_chain_bypass:force_inactive} set dft_op_table(non_scan_ATPG:111)
{MEB:force_active SE:force_active CD:0 TADR:0}
set dft_insertion_mode bist_basic_ATPG
For configuring memory inputs and wrapper controls using TestMAX SMS commands,
you can use the dft_ops_file parameter as an input. This can be done either using the
set_dft_ops command or the set_dft_access_element command.
To create the dft_ops.tcl file, you can use the set_dft_ops command:
set_dft_ops -name mode_name
-mode mode_value
-pins [list name value]
-dft_insertion_mode mode_name
-ram_seq_mode mode_name_list
Alternatively, you can also pass the existing file through the set_dft_access_element
command.
set_dft_access_element -type wrapper
-parameter [list dft_ops_file file_path]

By default, the DFT mode pins (dm0, dm1, and dm2) of the processors are propagated
to the higher design hierarchical level. The following figure shows how each of the three
core-level processors is controlled by a separate core-level port.

T-2022.03-SP3
Feedback
Figure 45 Default DFT Mode Pins Propagation: Core Level
The following figure shows how each of the six core-level processors and one subsystem-
level processor are connected to separate subsystem-level ports individually.
Figure 46 Default DFT Mode Pins Propagation: Subsystem Level

T-2022.03-SP3
Feedback
To customize the DFT mode pins propagation, use the set_mbist_configuration

command with the following parameters:
• extract_rcl.disable_dm_propagation 1: Disables DFT mode bit propagation
• extract_rcl.connect_proc_dms 1: Merges the DFT mode signals (dm0, dm1, and

dm2) of all the processors
The following figure shows how the DFT mode pins of the three core-level processors
are tied to the binary value 0 by using the extract_rcl.disable_dm_propagation
parameter.
Figure 47 Disabling DFT Mode Pins at Core Level
The following figure shows how the DFT mode pins of the three core-level processors are
merged before propagation.

T-2022.03-SP3
Feedback
Figure 48 Merging DFT Mode Pins at Core Level
The following figure shows how the DFT mode pins of the core-level processors are
merged at the subsystem level before propagation.

T-2022.03-SP3
Feedback
Defining the IEEE 1500 Interface at the Shadow Server or Subserver Level
Figure 49 Merging DFT Mode Pins at Subsystem Level
Defining the IEEE 1500 Interface at the Shadow Server or

Subserver Level
To define the IEEE 1500 port interface, which is used during SMS IP insertion, use the
following commands:
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 -hookup buf1/out
set_dft_signal -type WRSTN -port WRSTN -view spec -hookup buf2/out
set_dft_signal -type CaptureWR -port CAPTUREWR -view spec
set_dft_signal -type ShiftWR -port SHIFTWR -view spec
set_dft_signal -type UpdateWR -port UPDATEWR -view spec
set_dft_signal -type SelectWIR -port SELECTWIR -view spec
The hookup pins must be unconnected so that the SMS tool can connect these pins to the
newly created signals.

T-2022.03-SP3
Feedback
Disabling Propagation of Memory Functional Ports and Processor Control Signals
Disabling Propagation of Memory Functional Ports and

Processor Control Signals
To disable propagation of memory functional ports and processor control signals, use the
following command:
set_dft_access_configuration -setup_options \
[list extract_rcl.limited_test_pin_propagation true]
The memory functional ports are defined using the None tag in the MASIS
file and are not connected to the design boundary in the input RTL. The
extract_rcl.limited_test_pin_propagation parameter also disables the propagation
of the processor status signals to the design status boundary. This parameter is passed to
the SMS setup file.
The following figure shows how the memory functional ports are propagated by default.
Figure 50 Default Propagation of Memory Functional Ports
Read margin,
New ports read margin enable,
TEST1, BC1, and so on
Light sleep, deep sleep,

New ports
shutdown, and so on
The following figure shows how the memory functional ports propagation is disabled using
the extract_rcl.limited_test_pin_propagation parameter.

T-2022.03-SP3
Feedback
Custom Memory Grouping
Figure 51 Disabling Propagation of Memory Functional Ports
Read margin,
read margin enable,
TEST1, BC1, and so on
Disabled
Light sleep, deep sleep,

shutdown, and so on
Disabled

You can customize memory grouping using the following options with the
set_memory_grouping command:
• -instance: Specifies the memory instance whose configuration needs to be

customized. You can use a wildcard entry to specify this option.
• -module: Specifies the memory module. You can use a wildcard entry to specify this
option.
• -processor: Specifies the processor in which the memory instance is placed. If the
specified processor already exists, the memory instance is placed in this processor. If
the specified processor does not exist, the tool creates it.
For example, the following command groups all the memory instances starting with
mem_ under the wrap_3 wrapper, which are under the proc_3 processor:
set_memory_grouping -instance [list mem_.* ] -processor proc_3
-wrapper wrap_3

T-2022.03-SP3
Feedback
If the proc_3 processor does not exist, the tool creates the processor.
• -wrapper: Specifies the wrapper in which the memory instance is placed. If the
-processor option is specified and the specified wrapper does not exist, the tool
creates it under the processor. If the -processor option is not specified, the tool
creates the specified wrapper under the processor in which the memory instance was
already present.
For example, the following command groups all the memory instances ending with
inst_1 under the wrap_1 wrapper:
set_memory_grouping -instance [list .*inst_1 ] -wrapper wrap_1
If the processor is specified and the wrap_1 wrapper does not exist, the tool creates
the wrapper. If the processor is not specified, the tool creates the wrap_1 wrapper
under the processor in which the memory instances are present.
• -wrapper_type: Specifies the wrapper type. For the shared type (default), multiple
instances of identical memories can be placed under a wrapper. For the dedicated
type, only one memory instance can be placed under a wrapper.
• -file: Specifies the path of the CSV file that contains information about the memory
instance, processor, and wrapper. This option must be specified alone.
For example, set_memory_grouping -file csv_file_path.
The following example shows the format of the CSV file.
Memory, Processor Name, Wrapper Name
block.mem_inst1.mem_1, proc_3, wrap_3
block.mem_inst2.mem_1, proc_2, wrap_2
For custom memory grouping using additional parameters, see Memory Grouping
Using a Custom CSV File.

T-2022.03-SP3
Feedback
A
Debugging Clock 29 Violations
The clock 29 rule ensures that all clock sources of memories or hard macros are
controlled by the test clock in shift/capture mode. This rule ignores the no-scan memories
and hard macros.
The following report shows the clock 29 violations during the execution of the plan_dft
command.
Extracting memory clock information from SpyGlass...
$SPYGLASS_HOME/bin/spyglass -project spg_plan_dft_config.prj -goal
SpyGlass Message Summary: 1 error, 8 warnings, 8 Infos
-------------------------------------------------------------------
Results Summary:
-------------------------------------------------------------------
: 0
flip-flops : 0
: 0
-------------------------------------------------------------------
Reports Directory:
./CORE/spg_plan_dft_config/consolidated_reports/des_unit_core_dft_shell_
goal/
SpyGlass LogFile:
./CORE/spg_plan_dft_config/consolidated_reports/des_unit_core_dft_shell_
goal/spyglass.log
Standard Reports:

T-2022.03-SP3
Feedback
Appendix A: Debugging Clock 29 Violations

Information: Resolve all memory clock(Rule: Clock_29) violations to

proceed forward. Use 'plan_dft -load_gui on' to debug the violations.
You can find the errors reported during the TestMAX Advisor checks in the
spg_plan_dft_config/ consolidated_reports/$design_dft_shell_goal/moresimple.rpt file.
To view the clock 29 violations:
1. Use the plan_dft -load_gui command to open the GUI.
2. Click the clock_29 (1) violation message. A pop-up window appears.

T-2022.03-SP3
Feedback
Appendix A: Debugging Clock 29 Violations

3. Right-click the memory instances and select Incremental Schematic to view the
blockage.

T-2022.03-SP3
Feedback
B
Content-Addressable Memories
Content-addressable memories (CAMs) are a class of memories that compare the search
data against a table of stored data and return the address of the matching data, unlike
RAMs, which search for a specific memory location and provide the data stored in this
address.
CAMs with superior search speed find a role of their own in applications where intensive
data handling is required.
Unlike RAM, which has simple storage cells, each individual memory bit in a fully parallel
CAM must have its own associated comparison circuit to detect a match between the
stored bit and the input bit. This makes CAMs to have more physical size than other types
of memories.
CAMs come in two major types: binary CAMs (BCAMs) and ternary CAMs (TCAMs).
BCAMs are the simplest type of CAMs that use only 1s and 0s in the stored word. TCAMs
allow a third matching state X or “don’t care” for one or more bits in the search word.
TCAM Support in SMS

To simplify testing of TCAMs, the TCAM-SMS flow provides a robust solution. The TCAM-
SMS flow is same as the generic SMS flow for other classes of embedded memories.
The SMS tool reads the memory and SMS interface standard (MASIS) files (*.masis),
which include behavioral, structural, and other information of the memory. MASIS files
specify the memory instance parameters that are necessary for the tool to interface with
the RTL design. Similar to other embedded memories, MASIS files for TCAM can be
generated using the MASIS compiler.
MASIS files are provided using the following command:
set_mbist_configuration -masis_files "masis_directory_path"
The generated MASIS file is used in the plan_dft stage with the design RTL for .ish file
generation.
In the TestMAX SMS tool, there are separate Silicon IP generator compilers for CAMs. In
addition to the wrapper and processor compiler, the SMS tool includes CAM processor,
CAM wrapper, and virtual memory compilers for CAM.

T-2022.03-SP3
Feedback
Appendix B: Content-Addressable Memories
Challenges of TCAM BIST Testing
It is necessary to include these compiler files along with the general SMS compilers in the
compiler library path provided to the tool.
set_mbist_configuration -compiler_libraries "-compiler_libraries_path"
The .ish file is used to run the Integrator tool, which uses the CAM processor and CAM
wrapper compilers to generate CAM-specific processors and wrappers.
Challenges of TCAM BIST Testing

Testing of TCAMs is both complex and time consuming due to the unique mix of logic and
memory. Conventional BIST algorithms do not meet this requirement. It is important to
have specific BIST algorithms for TCAMs to deliver coverage of all failure mechanisms
and do so in an efficient manner.
Features
The TCAM flow supports all the features supported by the generic SMS flow, including the
following:
• Compiler parameter update for the CAM processor and CAM wrapper compiler
• Location and instance name control for the CAM processor compiler
• Custom algorithm support for the CAM processor compiler
• A unified TCAM-SMS flow for designs having both CAMs and other classes of
memories

T-2022.03-SP3
Feedback
C
Memory Grouping Using a Custom CSV File
While the plan_dft command runs, the Embed-It! STAR Planner tool uses the
sms_plan_dft_planner_config.tcl and dft_memory_report files generated by the TestMAX
Advisor tool as inputs to generate the initial memory grouping information and the Embed-
It! STAR Integrator shell script (ISH) file. This memory grouping information is stored in the
design_name_compout_gr.csv file.
You can use the custom CSV flow to control memory grouping. This is done by creating
a custom CSV file and passing it to the TestMAX SMS tool before running the plan_dft
command, as follows:
set_mbist_configuration -custom_csv_file csv_file_path
The Embed-It! STAR Planner tool uses the custom CSV file to generate the ISH file.
You can customize the following parameters in the CSV file for memory grouping:
• Memory Instance
• Memory Type
• Memory Instance Count
• Wrapper Name
• Wrapper Instance Count
• Processor Name
• Server Name
• Clock Source
• Clock Domain Name
• Frequency
• Proximity Domain Name
• Power Domain Name
• User-Defined Domain Name

T-2022.03-SP3
Feedback
Appendix C: Memory Grouping Using a Custom CSV File

For grouping based only on the processor, the Proximity Domain Name, Power Domain
Name, and User-Defined Domain Name parameters are not required in the custom CSV
file.
For example, the following design_name_compout_gr.csv file is generated by default by
the SMS tool.
Memory Instance,Memory Type,Memory Instance Count,Wrapper Name,
Wrapper Instance Count,Processor Name,Ring Info,Server Name,Clock Source,
Negedge,Processor Path,Clock Domain Name,Frequency,Proximity Domain Name,
Power Domain Name,User-Defined Domain Name
des_unit_core0.memory_inst.high_speed_mem_inst_2,
sadsls0c4l2p2048x32m8b1w0c0p0d0r1s2z1rw00,2,
des_unit_core0_wrap_sadsls0c4l2p2048x32m8b1w0c0p0d0r1s2z1rw00_1_gen,1,
des_unit_core0_proc_1,1:1,des_unit_core0_srv_1,clk500_grp2,
,des_unit_core0.memory_inst,clkgrp_user_500_grp_2,500.0000,,,
des_unit_core0_wrap_sadsls0c4l2p2048x32m8b1w0c0p0d0r1s2z1rw00_1_gen,
1,des_unit_core0_proc_1,1:1,des_unit_core0_srv_1,clk500_grp2,
1,des_unit_core0_proc_2,1:2,des_unit_core0_srv_1,clk500_grp1,
The memory grouping information of this file is:
Processor Wrapper Memory Instance
des_unit_core des_unit_core0_wrap_sadsls0c4l2p2048x32m8 des_unit_core0.memory_inst.hi

0_proc_1 b1w0c0p0d0r1s2z1rw00_1_gen gh_speed_mem_inst_2
(clkgrp_user_5
00_grp_2) des_unit_core0_wrap_sadsls0c4l2p2048x32m8 des_unit_core0.memory_inst.hi
b1w0c0p0d0r1s2z1rw00_1_gen gh_speed_mem_inst_3

(clkgrp_user_5
00_grp_1)
You can use the following custom CSV file to customize the default file.
Memory Instance,Memory Type,Memory Instance Count,Wrapper Name,
Wrapper Instance Count,Processor Name,Ring Info,Server Name,Clock Source,
Negedge,Processor Path,Clock Domain Name,Frequency,Proximity Domain Name,
Power Domain Name,User-Defined Domain Name

T-2022.03-SP3
Feedback

1,des_unit_core0_proc_3,1:1,des_unit_core0_srv_1,clk500_grp2,,
des_unit_core0.memory_inst,clkgrp_user_500_grp_2,500.0000,,,
The memory grouping information of this file is:
Processor Wrapper Memory Instance

(clkgrp_user_5
00_grp_2)

(clkgrp_user_5
00_grp_2)

(clkgrp_user_5
00_grp_1)
Here, the des_unit_core0_proc_1 processor in the default CSV file is changed

to the des_unit_core0_proc_3 processor in the custom CSV file. Therefore, the
des_unit_core0.memory_inst.high_speed_mem_inst_2 memory instance, which
was controlled by the des_unit_core0_proc_1 processor, is now controlled by the
des_unit_core0_proc_3 processor.
The SMS tool performs the following checks on the custom CSV file:
• Memory instances in the custom CSV file and the design are the same
• Clock sources in the custom CSV file are valid

T-2022.03-SP3
Feedback

• A path between the clock source and memory clock pin exists
• Memories under a processor have the same clock source, clock domain, proximity
domain, and power domain
• Each wrapper exists under one processor only
• Each wrapper contains memories of the same type only
• The number of memories under a wrapper or processor is within the defined limit set by
the set_mbist_confguration command
set_mbist_configuration -max_mem_num_per_proc
set_mbist_configuration -max_mem_num_per_wrap
In the custom CSV flow, the TestMAX SMS tool considers the user-specified MBIST clock
in the custom CSV file even if the clock is not related to or not in the path of the memory
functional clock. You must specify this clock as a clock source in the input SMS scripts.
Note:
The TestMAX Advisor tool traces the MBIST clock to a traceable point in the
path of the memory functional clock. Therefore, you can ignore the TestMAX
Advisor clock trace report if the custom CSV clock is not in the traceable path.

T-2022.03-SP3

Synopsys Testmax™ Sms User Guide: Version T-2022.03-Sp3, July 2022

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

Synopsys Testmax™ Sms User Guide: Version T-2022.03-Sp3, July 2022

Uploaded by

Copyright:

Available Formats

Synopsys TestMAX™ SMS User Guide

Version T-2022.03-SP3, July 2022

Synopsys TestMAX™ SMS User Guide 2

1. Understanding TestMAX SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. TestMAX SMS Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3. Working With TestMAX SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5. Flow for Flat Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6. Flow for Hierarchical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7. Custom BIST Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

BIST Controller Hardware Components and Programmable Sources . . . . . . . . . . . 77

8. BIST Production Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

Configuring Wrappers Using the DFT Operations File . . . . . . . . . . . . . . . . . . . . . . 106

A. Debugging Clock 29 Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

B. Content-Addressable Memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

C. Memory Grouping Using a Custom CSV File . . . . . . . . . . . . . . . . . . . . . . . . . . .120

About This User Guide

Related Products, Publications, and Trademarks

Synopsys TestMAX™ SMS 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

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

Synopsys TestMAX™ SMS User Guide 8

Contacting Customer Support

Synopsys TestMAX™ SMS User Guide 9

Synopsys TestMAX™ SMS User Guide 10

TestMAX SMS Architecture

Synopsys TestMAX™ SMS User Guide 11

Figure 1 TestMAX SMS Architecture

SMS SMS SMS

Wrapper Wrapper Wrapper Wrapper

Synopsys TestMAX™ SMS User Guide 12

• Test algorithm programmability

TestMAX SMS Design Flow

Synopsys TestMAX™ SMS User Guide 13

Synopsys TestMAX™ SMS User Guide 14

Figure 2 TestMAX SMS Design Flow

Plan DFT (plan_dft)

Generate DFT (generate_dft)

Connect DFT (connect_dft)

Validate DFT (validate_dft)

Synopsys TestMAX™ SMS User Guide 15

• Embed-It! (Version R-2020.09-SP1-ALPHA-20200910): Enables the set of tools

Synopsys TestMAX™ SMS User Guide 16

Figure 3 TestMAX SMS Network Architecture

SMART pins WSOR SelectWIR

Subserver eFUSE eFUSE

Core Core Core Core

Core Core Core Core Core

Synopsys TestMAX™ SMS User Guide 17

To learn more about the TestMAX SMS architecture, see

TestMAX SMS Architecture With TAP

Figure 4 TestMAX SMS Architecture With TAP

WRCK and WRSTN

TestMAX SMS Subsystem Architecture

Synopsys TestMAX™ SMS User Guide 18

Figure 5 TestMAX SMS Subsystem Architecture