ILane Mainstream Flow Application Note

Synopsys® TestMAX™
Mainstream Flow Application

Note
Version T-2022.03-SP1, May 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 Mainstream Flow 2

Contents
About This Guide .....................................................................................................................6
Audience ..............................................................................................................................6
Related Publications ............................................................................................................6
Understanding Synopsys® TestMAX™ Mainstream Flow .......................................................7
TestMAX™ Mainstream Flow ..................................................................................................8
Product and License Requirements .....................................................................................8
TestMAX Products and Licenses .................................................................................... 8
Additional Products and Licenses ................................................................................... 8
Tool Configuration ........................................................................................................... 9
Libraries to Execute the Test Cases ....................................................................................9
Installing the Testcase .......................................................................................................10
Verification Steps ...............................................................................................................11
Features in the iLane Mainstream Flow .................................................................................12
DFT Features in Mainstream Flow .....................................................................................13
Design Overview ....................................................................................................................14
Block Diagram of the Design .............................................................................................14
Clock Network ....................................................................................................................15
Asynchronous Reset ..........................................................................................................16
Memories ...........................................................................................................................16
SMS Hierarchical Network .................................................................................................17
DFTMAX/DFTMAX Ultra Fabric Network ...........................................................................18
IEEE 1149.1 TAP Controller and Boundary Scan ..............................................................19
Final Design ...........................................................................................................................20
Detailed Flow Description ......................................................................................................22
Structure of the Folders .........................................................................................................25
Fusion Compiler Reference Methodology ..............................................................................26
Reference Methodology Retrieval System (RMgen) ..........................................................27
Executing the Core Level Tasks ............................................................................................28
Core: 00_0_RTL_to_Gate_compile (Optional) ..................................................................28
Core: 00_testmax ...............................................................................................................28
Core: 01_testmax ...............................................................................................................29
Core: 10_formal .................................................................................................................31

Core: 20_fc ........................................................................................................................31
Core: 20_dc .......................................................................................................................32
Core: 21_formal ................................................................................................................33
Core: 30_pt .......................................................................................................................33
Core: 40_tmax_atpg ..........................................................................................................33
Core: 42_tmax_atpg_advanced_fault_model ....................................................................34
Core: 50_vcs_sms .............................................................................................................35
Core: 61_tmax_diagnosis ..................................................................................................35
Core: Summary ..................................................................................................................35
Subsystem Level Tasks .........................................................................................................37
Subsystem: 00_testmax .....................................................................................................37
Subsystem: 01_testmax .....................................................................................................40
Subsystem: 10_ formal ......................................................................................................42
Subsystem: 20_fc ..............................................................................................................42
Subsystem: 20_dc .............................................................................................................43
Subsystem: 21_formal ......................................................................................................44
Subsystem: 40_tmax_atpg ................................................................................................44
Subsystem: 42_tmax_atpg_advanced_fault_model ..........................................................45
Subsystem: 50_vcs_sms ...................................................................................................46
Subsystem: 51_vcs_atpg ...................................................................................................46
Subsystem: 61_tmax_diagnosis ........................................................................................48
Subsystem: Summary ........................................................................................................48
SoC Level Tasks ....................................................................................................................49
SoC: 00_testmax ...............................................................................................................49
SoC: 01_testmax ...............................................................................................................51
SoC: 10_formal ..................................................................................................................53
SoC: 20_fc .........................................................................................................................53
SoC: 20_dc ........................................................................................................................54
SoC: 21_formal .................................................................................................................55
SoC: 40_tmax_atpg ...........................................................................................................55
SoC: 50_vcs_sms ..............................................................................................................56
SoC: 51_vcs_atpg..............................................................................................................57
SoC: 53_vcs_bsd ...............................................................................................................61
SoC: 61_tmax_diagnosis ...................................................................................................61

SoC: 70_vtran ....................................................................................................................61
TestMAX Vtran Blocks .................................................................................................. 62
Requirements ................................................................................................................ 63
Implementation Details.................................................................................................. 63
Example Outputs........................................................................................................... 66
SoC: Summary...................................................................................................................67

About This Guide
The TestMAX Mainstream Flow application note defines a set of flows and
features that are verified and validated on a sample SoC to guide users and
developers through the proven path.
Audience
This manual is intended for design engineers who are experienced in
testability concepts and test and design-for-test (DFT) engineers who want to
understand how to insert DFT IP by using the TestMAX tools.
Related Publications
For additional information about TestMAX tools, see the documentation on the
Synopsys SolvNetPlus support site at the following address:
https://solvnetplus.synopsys.com/s/
You might also want to read the documentation for the following related
Synopsys products: TestMAX DFT, Formality, Fusion Compiler, and Design
Compiler®.

Understanding Synopsys® TestMAX™ Mainstream Flow
TestMAX Manager supports multiple features and technologies. You can
apply the features to several design flows and hierarchies. Each technology
also has various options. This flexibility leads to nearly infinite combinations of
a Design for Test (DFT) implementation. The TestMAX Mainstream flow
guides you through the proven path of the DFT implementation.
Synopsys® TestMAX™ Mainstream flow targets the hierarchical SoC designs
that need manufacturing test and scan compression to reduce test time and
test data volume.
The following figure shows the major stages demonstrated in TestMAX
Mainstream flow from the perspective of the tools used to perform the DFT
implementation.
Figure 1: Mainstream Flow

TestMAX™ Mainstream Flow
This topic describes the Mainstream Flow test case design, flow, and features
implemented in the example test case.
The Mainstream Flow test case aims to represent a generic System on Chip
(SoC) implementation flow.
Note:
The Mainstream flow testcase is intended to guide you through the
flow, important configuration steps, and the common challenges.
Therefore, the Mainstream flow testcase provides you an example of
the script and its execution. It is not intended to demonstrate
performance and quality of results (QoR).
The features implemented might not be exhaustively replicating all the
usages of the tool.
Product and License Requirements

The following products and licenses are required to execute the testcase.
TestMAX Products and Licenses

The following TestMAX products and licenses packages are required to
execute the testcase:
 TestMAX Manager (TestMAX DFT Apex)
 TestMAX DFT (TestMAX DFT Apex)
 TestMAX Advisor (TestMAX Advisor Base and VC SpyGlass Base)
 TestMAX SMS (TestMAX SMS Base)
 TestMAX ATPG (TestMAX ATPG Elite)
The following TestMAX products and license packages are optional (see the
common_setup.csh file):
 TestMAX Diagnosis (TestMAX Diagnosis Base)
 TestMAX ALE (TestMAX ALE Base)
 TestMAX Vtran (TestMAX Vtran Base)
Additional Products and Licenses

The following products and license packages are required, in addition to
TestMAX products, to execute the implementation and verification tasks
outside the TestMAX Manager or TestMAX ATPG environments:
 Design Compiler (Design Compiler Base Pkg)
 Fusion Compiler (Fusion Compiler Base Pkg)
 Formality (Formality Base)

 PrimeTime (PrimeTime Base)
 VCS (VCS Base)
This flow requires Test-CA licenses for running the stil2verilog
command.
There is an option to run the PrimePower tool, for which you require the
following license package:
 PrimePower (PrimePower Base)
Tool Configuration
Several tools are used in the iLane test cases. The tool versions must be
correct to guarantee a consistent installation configuration.
Run the setup.csh script to verify if your setup has appropriate licenses and
tool versions to run the current version of iLane.
This is the list of tools and their versions used in the iLane Mainstream flow:
 TestMAX Manager (dft_shell): T-2022.03-SP1
 Fusion Compiler: T-2022.03-SP1
 Design Compiler: T-2022.03-SP1
 TestMAX ATPG (tmax2): T-2022.03-SP1
 Formality: R-2020.09-SP5
 Stil2Verilog: T-2022.03-VAL-20220411
 STILGen: T-2022.03-VAL-20220411
 Stil2pdl: T-2022.03-SP1-VAL-20220414
 TestMAX ALE: T-2022.03-SP1
 Spyglass: S-2021.09-SP2
 VCS: S-2021.09-SP2-1
 PrimeTime: T-2022.03-SP1
 TestMAX Vtran: T-2022.03-SP1
The STAR memory system (SMS) and STAR hierarchical system (SHS)
compilers and binaries are picked up from the TestMAX Manager build path.
The versions of the tools defined in the common_setup.csh file must match
the versions above.
Libraries to Execute the Test Cases

The library files used or generated in the TestMAX Mainstream flow are for
flow demonstration purposes. It does not necessarily reflect any foundry
process characteristics.
The following libraries are used:

 NDM libraries (.NDM): Use NDM libraries in the TestMAX Manager
environment when memories are instantiated or a mapped netlist is used
as an initial design.
o NDM libraries are also used in the Fusion Compiler or Design Compiler
tool to map the design to the mapped logic.
 Verilog ATPG libraries: Use Verilog libraries in TestMAX ATPG for ATPG
and simulation.
Note:
Use the Verilog primitive function or user-defined primitives (UDP). Do
not use the behavioral simulation models for ATPG.
 Verilog Simulation Libraries: Full functional simulation libraries are needed
for 0-delay and back-annotated functional simulation. The VCS tool is
used for simulation.
 MASIS: Use the MASIS model in the TestMAX SMS tool to enable
Memory BIST and repair implementation through the tool.
 DB (.db) and Liberty (.lib): DB files and Liberty files are used by the Design
Compiler, Formality, and PrimeTime tools.
Note:
Contact the Synopsys customer support team, for the .tar testcase
files.
After installing the design and library files, update the following shell scripts to
configure the appropriate tools:
cd <my_iLane_work>/iLane_Mainstream_Design_rev_6.0
#edit this file to match your settings, library and tool version
vi ./ common_setup.csh
run_flow
Installing the Testcase

The testcase is available in the form of a compressed tar file:
iLane_Mainstream_Rev7.0.tar.gz
The tar file includes the design, the scripts, and the required directory
structure. The tar file does not include outputs to minimize the file size.
The libraries are not included in the design tar file. The libraries should be
installed separately using the following tar file:
iLane_Libs_rev.7.0.tar.gz
Install the libraries in the same directory where the design tar file is installed.
Note:
Contact the Synopsys customer support to obtain the .tar testcase files
Perform the following steps to install the full testcase environment:

mkdir <my_iLane_work>
cd <my_iLane_work>
gtar xvf ../iLane_Mainstream_Rev7.0.tar.gz
gtar xvf ../iLane_Libs_rev.7.0.tar.gz
Note:
Change my_iLane_work to the directory name you prefer.
After installing the design and library files, update the following shell scripts to
configure the appropriate tools:
cd <my_iLane_work>/iLane_Mainstream_Rev7.0
#edit this file to match your settings, library and tool version
vi ./common_setup.csh
run_flow
Note:
The library and tools installed should match those indicated in the
common_setup.csh file.
Verification Steps
The Mainstream flow testcase includes static and dynamic verification.
The following validation steps are used to validate the implemented features:
RTL validations:
 RTL validation for the SMS IP using the TestMAX validate_dft
command
 RTL testbenches for SMS simulation using the VCS tool
 RTL testbenches for codec validation
 Formal Verification (RTL vs DFT-inserted RTL Formality)
 DRC validations:
 Connectivity checks using the TestMAX validate_dft command
 TestMAX ATPG DRC
Gate-level validations:
 SMS pattern testbenches simulation using the VCS tool
 TestMAX ATPG using the run_sim command
 Gate-level 0-delay simulation of patterns using the VCS tool
o ATPG manufacturing patterns: Serial and parallel
 Static timing analysis (STA), synthesis constraint validation, and post-
processing
o Scan shift mode
 Formal verification using the Formality tool
 Boundary scan patterns simulation

Features in the iLane Mainstream Flow
The following features and functionalities are a part of the TestMAX iLane
Mainstream flow:
 Netlist-based flow
 Improved multi-hierarchical pattern porting
 SoC DUT configuration with design variations (upgraded to two different
subsystems and cores)
 Clock network configuration upgraded to cascaded OCC
 Improved QoR for the Fusion Compiler flow
 Optional encrypted Verilog RTL
 Three-level pipeline for compression mode (core, subsystem, and SoC)
 Shell netlist write out or read in for hierarchical DFT flow
 RTL-level codec validation testbench
 1149.1 TAP for boundary scan
 TAP driven TDR for DFT configurations
 Fuse UDR register
 Programmable algorithm MBIST
 SMART interface
 APB support for the TestMAX SMS IP
 SMS pipeline
 DEF-based memory grouping
 Double shadow server (Subsystem0 and core level) and top server
 Shadow server (only core-level) and subserver (subsystem1) and top
server
 SMS signature register programming feature enable
 SMS soft programmable algorithm hardware enable
 TestMAX Manager command line customization of SMS parameters for
processors, wrappers, and servers
 (STA and synthesis constraint validation and post-optimization
 Formality check for R2R and R2G
 BSD segment support
 Function pad reuse for scan input and output channel
 TDR test mode auto decoding into SPF
 Manual workarounds removal
 Diagnostic flow enablement
 Shared input dedicated output (SIDO) for identical cores

 Shared core wrapping
 Custom or predefined MBIST production pattern support
 ATPG advanced fault model pattern generation
 Design Compiler compile_ultra command support
DFT Features in Mainstream Flow

The following DFT features are implemented in the testcase:
 DFTMAX/DFTMAX Ultra scan compression
o Shared functional pads
o Shell netlist write-out and read-in (for the Design Compiler flow only)
o Enable diagnostic (DFTMAX Ultra only)
 Dedicated scan wrapper in the TestMAX Manager tool
o Compression wrp_if mode
o Scan wrp_if mode
o Scan wrp_of mode
 Dedicated scan wrapper in the Design Compiler or Fusion Compiler tool
o Scan wrp_if mode
o Scan wrp_of mode
 Shared scan wrapper
o Scan wrp_if mode
o Scan wrp_of mode
 On-chip clock controller
 Random resistant test point insertion
 Generation of SDC constraints
 Low-Power in DFTMAX
 TestMAX SMS for memory BIST and repair
o SMS wrapper
o SMS processor
o SMS shadow server (ring). For information about the shadow server,
see the TestMAX SMS User Guide.
o SMS double shadow server (ring)
o SMS subserver
o SMS server

o SMS shared eFUSE processor
o Soft programmable algorithm hardware
o Design exchange format (DEF) file-based memory grouping
o Smart BIST mode
o Custom production pattern set
 Hierarchical ATPG (pattern porting)
o DFTMAX/DFTMAX ultra pattern porting
o SMS pattern porting
 TAP controller insertion
o Boundary scan insertion
o Boundary scan segment support
o JTAG TDR insertion with auto SPF updates
Design Overview
The flow is implemented on a small size RTL design using a bottom-up flow.
The bottom-up flow is implemented across the following hierarchical levels:
 Core
 Subsystem
 SoC
Block Diagram of the Design

The following figure shows the block diagram of the design.

Figure 2: Hierarchical Design for the iLane Mainstream Flow
Each core and hierarchical level include logic (combinational and sequential)
that is included in a scan chain. A few memories are also instantiated in each
core and hierarchical level.
Clocks are generated by simple free-running clock module generators acting
as PLL. The sequential logic receives different clock sources and can be reset
asynchronously. The cores shaded in green, for example, core0, is
instantiated multiple times in subsystem and SoC levels.
At SoC level, in addition to the additional core0, some glue logic and
memories are present: A pad control logic (PCL), which includes pads and
direction control for all ports of the design, and an additional custom block,
which includes a few pads already connected with their boundary scan
register (BSR) to realize a BSR segment that is recognized and reused.
Clock Network
The clock network is controlled through automatically inserted OCC
controllers to enable high-quality at-speed testing.
Ensure that the following requirements are met:
1. Multiple external clocks are visible at SoC level
o ATE test clock,to control shift operations
o TCK test clock, to drive IEEE 1149.1 interface and logic
o Reference clock, to trigger and provide reference clock to PLL
2. Multiple clocks are generated internally by the PLL generators from a
dedicated reference input clock. The reference clock is dedicated to trigger

the PLL frequency. The reference clock is a free-running clock, and it is
not used as an ATE_CLK, TCK, WRCK, or logical clock.
3. A dedicated external ATE Clock is used for all the test-related operations
such as scan, scan compression, and so on.
4. An external TCK is used to control the IEEE 1149.1 TAP and to produce
the internal WRCK to drive the IEEE 1500 resources. The TCK and the
derived WRCK are not used in this flow to provide the external ATE_CLK
used for the shift by the scan chains operations.
The ATE clock has the same period as the TCK. The reference clock has a
period different period from the ATE clock.
The following figure shows the clock network implemented in the example design.
Figure 3: iLane Mainstream Flow Clock Network
For hierarchical ATPG and pattern porting, the OCC is added at the core level
(for example, the OCC #2) as well at the higher level (for example, OCC #3).
This configuration (also referred to as cascaded OCC) allows you to use the
core-level OCC #2, when core level patterns are exercised (OCC #3 is
disabled), and higher-level OCC #3 when the cores are in EXTEST (wrp_of)
mode (OCC #2 is disabled). This configuration is added in the iLane
mainstream flow.
Asynchronous Reset
The asynchronous reset external pins are used as asynchronous resets for
the cores, the subsystem, and the SoC DFT logic.
The asynchronous reset signals are not used for any other purpose, for
example, WRSTN, occ_reset, or TRSTN.
Memories
Multiple memories with repair logic are included in the design to allow the
TestMAX SMS flow to be implemented. Each core instance of the design

instantiates three memories each. One additional memory instance is added
at the subsystem SoC levels.
Memory repair flow is implemented using a generic eFUSE interface and a
validation eFUSE model.
SMS Hierarchical Network

The following diagram shows a simplified view of the SMS network.
Figure 4: SoC-Level IEEE 1500 Network Including SMS IPs
In each core, a separate ring is implemented for the SMS (shadow subserver
configuration).
At the subsystem level, the additional processors are connected in a ring that
includes the rings pre-implemented in the cores. The SMS rings of the two
subsystems are handled differently. A shadow server is added at the
Subsystem0 level. This is a double shadow server on top of the shadow
server inside its core. A subserver is implemented in subsystem 1. The
subserver implemented in Subsystem1 drives the SMS rings.
On the other hand, subsystem0 adopts the double shadow server feature. All
the processors in subsystem0 and its cores are connected in one SMS ring.
This ring is further connected to top-level directly.
At the SoC level the following are implemented:
 An SMS processor in the core is instantiated at the top-level
 A top-level processor
 A server to drive the subsystem1 and the SMS ring in subsystem0 and
SoC
The top-level server includes a shared fuse processor that is used to manage
the eFUSE and memory repair for the entire chip. The eFUSE is accessible
through a generic eFUSE interface.

An APB interface is enabled in the server to allow in-system tests through a
safety manager processor.
The DEF based memory grouping feature is also implemented in core1 SMS.
A SMART interface is enabled to allow in-system SMS self-test during
function mode. There are two SMART interface groups, one for subserver to
test the SMS IP in subsystem1 and another for top-Server to cover the SMS
IPs in subsystem0 and SoC.
DFTMAX/DFTMAX Ultra Fabric Network

The following diagram shows the fabric network that allows scan and
compression testing of the design hierarchy and enables the porting of the
scan patterns.
Figure 5: DFTMAX/DFTMAX Ultra Fabric Network
Each core is wrapped with a wrapper cell.

With the option “share_wrapper_en” in the common_setup.csh file, you can
enable the implementation of shared core wrapper cells in each core.
The following modes are implemented:
 wrp_if (non-compressed scan mode with wrapper in in-forward mode)
 sccomp (compressed mode with the wrapper in in-forward mode)
 wrp_of (non-compressed scan mode with the wrapper in EXTEST mode)
The shell netlist of each wrapped core is written out for the subsystem, SoC
ATPG and simulation when the cores are used in wrp_of mode.
Each subsystem is wrapped with a dedicated wrapper cell.

The cores are accessible from the subsystem level in compressed (sccomp)
and uncompressed (wrp_if) modes.
Subsystem0, which implements identical cores, integrates the cores using the
SIDO scan channel configuration. In this configuration, the inputs from cores
are shared and the output channels remain directly observable. The following
figure shows a simplified SIDO configuration.
Figure 6: SIDO Configuration
In addition to the core modes, each subsystem implements wrp_if (non-

compressed scan mode with subsystem wrapper in in-forward mode and
cores in wrp_of mode), sccomp (compressed mode with the subsystem
wrapper in in-forward mode and cores in wrp_of mode), and wrp_of (non-
compressed scan mode with subsystem wrapper in EXTEST mode).
The shell netlist of each wrapped subsystem is written out for the SoC ATPG
and simulation.
Note:
The shell netlist feature is supported only in the Design Compiler flow.
At the SoC level, the cores and the subsystem are accessible individually in
compressed (sccomp) and uncompressed (wrp_if) modes.
In addition to the core and subsystem modes, the SoC implements wrp_if
(non-compressed scan mode with the subsystem wrapper and cores in
wrp_of mode) and sccomp (compressed mode with subsystem and cores in
wrp_of mode).
IEEE 1149.1 TAP Controller and Boundary Scan

When the SoC level DFT logic is implemented, an IEEE 1149.1 standard TAP
controller is inserted and connected to the design to control the following
features:
 Insert boundary Scan to the pads
 Reuse existing BSR Segments
 Create an internal TDR and use it through JTAG for test mode control
(automatic update of the SPF to include proper initialization)
 Reuse existing pads

 SMS network through the SMS server
Final Design
The following diagram shows the final design with all the major DFT features.
There are some differences between the two subsystems, which are not
shown in the diagram. Subsystem0 uses the shadow server and Subsystem1
uses the subserver.

Figure 7: Final Design

Detailed Flow Description
The following figure shows the steps, high-level tasks, and tools used in the
Mainstream flow.
Figure 8: Flow Description
Note:
Each step or task refers to one or more tool execution. In most cases,
tool execution in the previous step must be successful to progress to
the next step.
At each level in the design, you implement the required DFT features to test
the logic and memory in the design, optimize the manufacturing test, and
apply the scan compression methodology on DFTMAX/ DFTMAX Ultra to
reduce the test cost.
The following steps describes the features that you insert in the core.
1. Insert the TestMAX SMS IP to generate custom memory built-in self-test
(BIST) hardware with self-repair capability and BIST production patterns
with diagnostic capability. The TestMAX SMS network consists of multiple
SMS cores compliant to the IEEE 1500 standard.
For more information about enabling the TestMAX SMS hierarchical flow,
see the TestMAX SMS User Guide.
2. After implementing the SMS flow, enable the hierarchical adaptive scan
flows for DFTMAX/DFTMAX Ultra. This provides hierarchical support for
the cores and SMS IPs.
For more information about configuring, see the TestMAX Manager User
Guide.

3. To check the functional equivalence between your RTL and the DFT-
inserted RTL, use the formal verification constraint files generated by the
write_dft_constraints command using the Formality tool.
For more information about using the Formality tool, see the Formality
User Guide.
4. Perform the synthesis and the scan-stitching operations using the Design
Compiler or Fusion Compiler tool.
For more information about the design flow in the Design Compiler Tool,
see the Design Flow in the Design Compiler User Guide.
For more information about the synthesis design flow in the Fusion
Compiler tool, see the Fusion Compiler User Guide.
The write_dft_constraints command writes out the constraints to

stitch the scan chains to the DFT IP during synthesis in Design Compiler
or Fusion Compiler tool. For more information about writing DFT synthesis
constraints, see the TestMAX Manager User Guide.
5. Validate the timing performance of the design by checking all possible
paths for timing violations. The PrimeTime tool breaks the design into
timing paths, calculates the signal propagation delay along each path, and
checks for violations of timing constraints inside the design and at the
input/output interface.
For more information about the Prime Time (STA), see the PrimeTime
User Guide.
6. You can use an equivalence checking tool to verify that your gate-level
netlist is functionally equivalent to your RTL. This verification step ensures
that the synthesis process or manual design changes did not introduce
functional errors.
For more information about verifying functional equivalence, see the
Formality User Guide.
7. The TestMAX ATPG tool is used for design rule check (DRC) in different
test modes and subsequent pattern generation. For more information
about manufacturing ATPG simulation and diagnostics, see the TestMAX
ATPG and TestMAX Diagnostics User Guide.
For a TestMAX ATPG command script template to run DRC and ATPG,
see the TestMAX Manager User Guide.
For detailed instructions about core-level tasks, see Core- Level Tasks.

The following steps describes the features that you insert in the subsystem.
Repeat the tasks that you performed on the core. Additionally, include the
following functionalities in the subsystem. These steps integrate and connect
the core- level SMS IEEE 1500 rings implemented in the cores of the design.
1. The ATPG patterns generated at the core level are ported at the
subsystem level for validation and simulated using the VCS tool.
For more information about pattern porting and simulation see the
TestMAX ATPG and TestMAX Diagnosis User Guide.
2. Fault simulation determines the test coverage obtained by an externally
generated test pattern. To perform fault simulation, use functional test
patterns that were developed to test the design and were simulated in a
logic simulator to verify the correctness.
For more information about fault simulation, see the TestMAX ATPG and
TestMAX Diagnosis User Guide.
3. The TestMAX Diagnosis tool determines the root cause of failures
observed during the testing of a chip. The data obtained from diagnostics
identifies, cells and scan chains with defects, and any logic with defects.
Generate the reports that locate the candidate defects with match
percentage score.
For more information about applying the TestMAX Diagnosis tool to

manufacturing test failures, see the TestMAX ATPG and TestMAX
Diagnosis User Guide.
For detailed instructions about subsystem level tasks, see Subsystem-
Level Tasks.
At the SoC level, integrate the pre implemented cores and subsystem, which
are treated as hard-cores, and add the required DFT features to test the
remaining logic and memories that exist in the SoC hierarchy.
At SoC level, a TAP complying to the IEEE 1149.1 standard is implemented to
control the internal IEEE 1500 network and resources. The same TAP is used
to control the Boundary Scan of the SoC which includes existing BSD
segment and embedded PADs in the design.
For more information about inserting boundary scan cells in the SMS - SHS
design, see the SMS and SHS Designs article.
For more information about boundary-scan design and verification flow, see
the TestMAX DFT Boundary Scan User Guide.
For detailed instructions about SoC-level tasks, see SoC Level Tasks.
The scripts have detailed comments which describe the operations and scope
of the tasks.

Structure of the Folders
The following folder structure is predefined in the testcase:
 Inputs: This folder includes the source RTL code and libs used by the
tools.
o RTL: This folder contains the source RTL files of the design.
o Scripts/syn: This folder contains the common scripts called by
synthesis
 core0 core1: These two folders contain the files needed to execute the
core-level flow.
 subsystem0 subsystem1: These two folders contain the files needed to
execute the subsystem-level flow.
 SoC: This folder contains the files needed to execute the SoC-level flow
Each of the five design folders (core0, core1, subsystem0, subsystem1, and
SoC) includes additional sub-folders which guide you through the
implementation and verification steps. These folders are common to all the
hierarchical directories.
The following the sub-folders:
 00_testmax: Inserts SMS logic in the RTL design and stitch IEEE 1500
rings.
 10_formal: Compare the source RTL design and the DFT-inserted RTL
using the Formality tool.
 20_dc: Synthesis and scan stitching using the Design Compiler tool and a
bottom-up flow.
 20_fc: Synthesis and scan stitching using the Fusion Compiler tool and the
reference methodology (RM) flow.
 21_formal: Compare the source RTL design and the scan synthesized
netlist using the Formality tool.
 30_pt: Validate scan or MBIST timing constraints.
 40_tmax_atpg: Run TestMAX ATPG to generate ATPG patterns and
validate the patterns using the VCS tool.
 50_vcs_sms: Simulate the SMS validation tasks on the gate-level
synthesized netlist. The patterns are validated using the VCS tool.
The following folders are specific to hierarchical levels (defined inside
parenthesis):
 01_testmax (only core): Incrementally insert the DFTMAX, and other DFT
in the RTL design.
 01_testmax (only subsystem and SoC): Incrementally inserts DFTMAX
and other DFT logic in the RTL design.
 42_tmax_atpg_advanced_fault_model (only core0 and subsystem0): Run
TestMAX ATPG to generate ATPG patterns and validate patterns using

the VCS tool for the advanced fault model. This includes cell-aware faults,
bridging and dynamic bridging faults, slack-based transition faults and
IDDQ faults. This is a stand-alone task with checked in netlist and SPF
files. This task is controlled by the adv_fault_model option in the
common_setup.sh file.
 51_vcs_atpg (only Subsystem and SoC): Perform pattern porting for
hierarchical ATPG, reuse the core-level patterns and reapply them through
the DFTMAX/DFTMAX Ultra fabric from the subsystem- level or SoC-level
scan channels. The patterns are validated using the VCS tool.
 53_vcs_bsd (only SoC): Simulate the BSD pattern generated by Design
Compiler tool.
 61_tmax_diagnosis (only core0, subsytem0 and SoC): Inject fault in
DFTMAX Ultra mode and diagnose candidate defects using the TestMAX
Diagnosis tool.
The sub-folders follow the same structure for easy identification of sources
and output files:
 Inputs: This folder includes the source files used by the tools. The input
folder is created by the shell script of the currently executed task,
retrieving the results of the previous task. The possible files in this
directory can be source RTL, Verilog netlist, SPF protocols, SDC
constraints, and so on.
 scripts: This folder includes the scripts executed by the tools. Usually, a
single master script is executed. The scripts can be parametrized when
required.
 logs: All the logs for which you defined the location are collected in this
folder. Default logs and reports are generated in the WORK directory,
where the commands are currently executed.
 reports: The reports are collected in this folder.
 outputs: In this folder, all files that are needed for the subsequent steps
(RTL, netlist, protocols, constraints, models, and so on) are collected.
 WORK (created): The WORK folder is created at the beginning of the task.
All the commands are executed from this folder. Therefore, the output files
and directories that are generated by default in the current directory are
available in the WORK folder at the end of the task.
Fusion Compiler Reference Methodology

The TestMAX Mainstream testcase uses the Fusion Compiler reference
methodology to synthesize the design when the Fusion Compiler tool is
selected. The Synopsys reference methodology provides a set of product-
specific reference scripts that shows you the latest recommended
methodology for a specific product and release.

These scripts can be used as a starting point to build your design. You can
also use these scripts as a template for developing your flows. The scripts
have embedded comments that explain the commands.
The Fusion Compiler Reference Methodology documentation is available at
the following location:
https://solvnetplus.synopsys.com/s/article/Reference-Methodologies-and-the-
Retrieval-System-RMgen-1576135572616
Reference Methodology Retrieval System (RMgen)

The reference methodology retrieval system (RMgen) on
the SolvNetPlus online support site provides an easy-to-use web-based
environment for obtaining default or customized reference methodology
scripts for your design environment. The user interface has web pages
for selecting, configuring, and downloading the reference methodology scripts.
The flow for obtaining the reference methodology scripts using the web-based
interface consists of the following steps:
1. Select the product and release.
2. Configure the scripts.
3. Download the scripts.
The following figure shows the web-based interface.
The Fusion Compiler RM scripts are available at the following location:

https://solvnet.synopsys.com/rmgen/

Executing the Core Level Tasks
At the core level, implement the required DFT features to test the logic and
memory in the design, optimize the manufacturing test and apply the scan
compression methodology on the DFTMAX/ DFTMAX Ultra tool to reduce the
test cost. It is assumed that the core is a safety-critical element. You must
perform the self-test for the power-on in-system test and periodic testing.
Core: 00_0_RTL_to_Gate_compile (Optional)

This task is optional and is enabled in the common_setup.csh file by the
environment variable, setenv netlist_flow yes.
When the netlist flow is enabled, core0 is synthesized to gates. Then, the
synthesized gate-level netlist (instead of the RTL) is used in the next steps.
Core: 00_testmax
Read the source RTL design (unless setenv netlist_flow yes),
generate, insert, and connect the TestMAX SMS components in the design.
The design files are read based on the user configuration file.
After reading the design, the SMS client is enabled. The script configures the
required settings to point the directory to the location of the MASIS models of
the memories, required SMS compilers, and signal settings needed to
implement memory BIST in the core.
Figure 9: SMS IP Insertion

In this task, the following steps are executed:
1. plan_dft: Memories are identified in the design based on clock tracing by
the TestMAX Advisor (SpyGlass) tool and a memory report is generated.
The STAR planner tool defines the memory grouping, based on the
requirements specification, and generates the grouping CSV file.
The defined memory grouping is used by the next step. The DEF-based
memory grouping feature is implemented only in the SMS IP of core1. This
feature supports the memory group based on the proximity domain
parameter. For more information, see the TestMAX SMS User Guide.
2. generate_dft: TestMAX SMS MBIST components: such as SMS Wrappers
and SMS processors are created. The Smart BIST element and interface
in the processor are also created for the SMS self-test in function mode.
The UDS and CPF files are generated for the validate_dft command
and the connection file is generated for the connect_dft command.
3. connect_dft: The TestMAX SMS MBIST components created by the
generate_dft command, instantiated, and connected in the design.
4. validate_dft: The implementation is verified statically, (connectivity checks)
and dynamically (integrity check and simulation) checks to validate the
components, the connections, and the entire SMS core-level system.
The dynamic validation is performed using four pre-defined basic sets of

SMS test patterns generated by the STAR Verifier tool. Additional pre-
defined patterns are also generated targeting specific processors in core0.
This task uses the run_testmax.csh shell script. The TCL script used by
the dft_shell is scripts/testmax.tcl
This task generates the following output files:
 ICT and WKS (Workspace) for integration at higher levels
 Modified RTL Verilog
 TestMAX SMS RTL components
 Constraint files
 UDS and CPF files for user-defined pattern generation
Core: 01_testmax
Read the RTL design created by the previous step. This task also generates,
inserts, and connects the scan compression (DFTMAX/DFTMAX Ultra) and
OCC components to the design. The list of files to be read is created by the
previous task.
DFTMAX Ultra scan compression inserted by default. To insert DFTMAX
instead of DFTMAX Ultra, change the environment variable Compr to scan in
the common_setup.csh file.

After reading the RTL design, the TestMAX Manager clients such as scan,
compression, IEEE 1500 wrapper, pipeline_scan_data, and OCC controller
are enabled. The script configures the required settings to define the DFT
signal, ports, options, and test modes.
Settings and configurations for individual clients are made in the scripts to
generate appropriate DFT components. An IEEE 1500 core wrapper is also
generated to allow pattern porting and interconnectivity tests.
To switch to the dedicated scan wrapper (in the Design Compiler or Fusion
Compiler tool) or shared scan wrapper flow, disable RTL core wrapper
insertion in the TestMAX Manager tool.
At the end of the task, the VCS tool uses the RTL testbench to validate the
DFTMAX/DFTMAX Ultra codec, ensuring the correctness of the behavior and
connectivity of the modified RTL.
Figure 10: Core-Level DFTMAX Ultra and Wrapper RTL Insertion

1. check_dft: The RTL of the design is analyzed to identify potential coverage
issues by applying DFT checks and pointing to potential DFT violations
that should be fixed. You can run this step in GUI mode for an interactive
debug.
2. generate_dft: TestMAX DFT components: such as wrapper,
DFTMAX/DFTMAX Ultra CODEC, Pipeline Scan Data, and OCC controller
are created.
3. connect_dft: The DFT components created by the generate_dft
command are instantiated in the design and connected.

4. validate_dft: The implementation is verified using connectivity checks to
validate the components and the connections.
This task uses the run testmax.csh shell script. The Tcl script used by the
dft_shell is scripts/testmax.tcl.
This step produces the following output files:
 Modified RTL Verilog Design
 TestMAX DFT IP RTL components
 Constraints files
To support the in-compile flow in the Fusion Compiler tool, a constraints
file (<file>.synth_fc.tcl or <file>.dft_fc.tcl) is generated by the TestMAX
Manager tool.
 STIL Protocol Files (one for each implemented mode): CTL, ICT, and
compout
Core: 10_formal
Run the Formality tool to perform the following formal verification:
 RTL (original) against the SMS-inserted RTL
This task uses the run_fm.csh shell script. The Tcl script used by fm_shell:
scripts/fm.tcl
This task generates reports for each check step:
reports/*fmv_unmatched_points.rpt
Core: 20_fc
The DFT-inserted core-level RTL is synthesized using the Fusion Compiler
tool if the environment variable $syn is set to fc.
The design is synthesized from RTL to the mapped logic and optimized using
the linked technology library. The scan chains are routed and connected to
the existing codec’s inserted by the 01_testmax step.
The script includes commands of the following implemented features:
 Ability to exclude logic from a specific test mode
 Random resistant test points to improve the codec coverage and reduce
ATPG test patterns
 Dedicated scan wrapper insertion or shared scan wrapper insertion
 Flow enhancement to support the in-compile flow in the Fusion Compiler
tool
The modified design can run an optional incremental compile to fix hold
violations. The resulting netlist can then be verified and simulated using back
annotation.

This task uses the run_fc.csh shell script.
The following script reproduces the RM flow:
# Copy the FC RM 2.0 files in WORK
cp -rf ../../../FC-RM_ S-2021.06/* ./
# Copy the FC RM 2.0 design_setup in WORK
mv ./rm_setup/design_setup.tcl
./rm_setup/design_setup.tcl_original
cp -f ../scripts/design_setup.tcl ./rm_setup/design_setup.tcl
make -f rm_setup/Makefile clean_all
make -f rm_setup/Makefile init_design
make -f rm_setup/Makefile compile
The default design_setup.tcl file from the RM is replaced with the one defined
for the Mainstream flow.
This step generates the following output files:
 Netlist Verilog of the design
 Reports
 Empty module definition
 NDM
Core: 20_dc
The DFT-inserted core-level RTL is synthesized using the Design Compiler
tool if the environment variable $syn is set to dc. The compile_ultra
command is invoked to obtain better quality of results (QoR) when you
compile designs that have significantly tight timing constraints. The command
performs a bottom-up compilation.
The design is synthesized from RTL to mapped logic and optimized using the
linked technology library. The scan chains are routed and connected to the
existing codec inserted by the 01_testmax step.
 Random resistant test point insertion to improve the codec coverage and
reduce ATPG test patterns
 Dedicated scan wrapper or shared scan wrapper insertion
 Insert power clock gating to save power
The Tcl script used by the dc_shell is scripts/dc_dftmax_mm_wrap.tcl.

 Reports
 NDM
 SPEF
Core: 21_formal
Run the Formality tool to verify the RTL (original) against the netlist after the
synthesis in the 20_dc or 20_fc step.
This task uses the run_fm.csh shell script. The Tcl script used by the
fm_shell is scripts/fm.tcl.
This task generates reports per each check step:
Core: 30_pt
This task uses the PrimeTime tool to generate reports in all test modes.
This task uses the run_pt.csh shell script. The Tcl script used by the
pt_shell is scripts/pt_xlbist_mm_wrap.tcl.
Note:
If you are using the PrimeTime tool for enabling the PrimePower flow,
contact Synopsys customer support.
Core: 40_tmax_atpg
Core-level pattern generation for the manufacturing test uses the TestMAX
ATPG and TestMAX Diagnosis tools.
The following wrapper and OCC modes are used to generate the patterns for
the stuck-at fault model:
 Compression wrp_if mode (OCC active and in bypass mode)
 Scan wrp_if mode (OCC active and in bypass mode)
 Scan wrp_of mode (OCC active and in bypass mode)
 Scan mode bypass wrapper chain (OCC active and in bypass mode)
The following wrapper, and OCC modes are used to generate the patterns for
the transition fault model:
 Compression wrp_if mode (OCC active and inactive mode)
 Scan wrp_if mode (OCC active and inactive mode)
 Scan wrp_of mode (OCC active and inactive mode)
 Scan mode bypass wrapper chain (OCC active and inactive mode)

All patterns are simulated using the run_sim command in the TestMAX
ATPG tool. The switching activity for average and peak power is also reported
using the report_power command.
The generated patterns are simulated by the VCS tool in the following
configurations:
 Serial 0-delay simulation
 Parallel 0-delay simulation
 Serial with timing simulation (run if $sim is defined as sdf)
 Parallel with timing simulation (run if $sim is defined as sdf)
This task generates ATPG and VCS simulation reports.
Core: 42_tmax_atpg_advanced_fault_model
This task generates an advanced fault model for use at the core level in
TestMAX ATPG compression mode. Low-power ATPG is also enabled. The
test sequence is:
1. Run the (pat-core-A) pattern for the slack-based transition fault model
(Fault-core-A)
2. Run the (pat-core-B) pattern incrementally for the stuck-at fault model
(Fault-core-B)
3. Fault-simulate the pat-core-A pattern against the dynamic bridge fault list
(Fault-core-C)
4. Fault-simulate pat-core-A and pat-core-B patterns against the bridge fault
list (Fault-core-D)
5. Fault-simulate the pat-core-A and pat-core-B patterns against the cell-
aware fault list (Fault- core-E)
6. Run the dynamic bridge pattern (pat-core-C) incrementally for the Fault-C
fault model (Fault-core-Ci)
7. Run the bridge pattern (pat-core-D) incrementally for the Fault-D fault
model (Fault-core-Di)
8. Run the cell-aware pattern (pat-core-E) incrementally for the Fault-E fault
model (Fault-core-Ei)
All patterns written out in each step are simulated in the TestMAX ATPG
(run_sim) and VCS tools in the following configurations:
This task generates ATPG and VCS simulation reports. The slack data for the
slack-based transition fault is generated in the 30_pt directory. The CTM
model generation flow for cell-aware fault is in the ctm_generation_flow
directory.

To regenerate the CTM model used in the mainstream flow, you can check in
the CTM model, update the file named “cell” and run the run.sh file.
Core: 50_vcs_sms
This step simulates the core-level gate-level pattern generation using the VCS
tool for SMS IP validation. Links are created to the patterns in the
00_testmax_ring directory.
The following modes are validated:
 bist_all_fail_tb: Runs BIST for all SMS processors expecting no failures in
SMS memories except the TBOX_SEL instruction, which performs the
write/read operation (W(D), R(~D)).
 signature_reg_check_tb: Read the processor ID register to verify the SMS
network connection.
 sms_status_tb: Read the SMS status register default value.
 bist_all_tb: Verifies all the MBIST Ips using the default algorithm and
checks the SMS result by reading out the SMS status register.
 repair_verif_tb: Verifies the memory repair feature with error injection in
the testbench and checks the SMS result by reading out the SMS status
register.
The generated patterns are simulated using and the gate level netlist in the
VCS tool.
This task generates VCS simulation reports.
Core: 61_tmax_diagnosis
In this task, a virtual failure log is created using gate level simulation with fault
injection in DFTMAX/DFTMAX Ultra mode, to mimic a real ATE failure log.
The TestMAX Diagnosis tool is used to identify the candidate defect.
The following test modes with the stuck-at fault models are used to inject
faults:
 Logic diagnosis: Forces the D pins of the sequential cell to a specific state
and runs VCS simulation to output the .diag (failure log) file.
 Chain diagnosis: Force the SI pins of the scan cell to a specific state and
runs VCS simulation to output the .chain.diag (failure log) file.
After the failure logs are generated, run diagnosis on each failure log, and
generate reports that locate the candidate defects with the matching
percentage score.
Core: Summary
The flow described is executed for core0 and core1.

To sign off the core level execution, ensure that all simulations are successful
and the fault coverage is acceptable according to the required metrics.
You can perform a visual inspection of the placed design at the end of the
implementation. The following figure shows the generated placement of the
core. The colors show the scan chain segments stitched based on the
placement.
Figure 11: Placement and Scan Chains View (Fusion Compiler)

Subsystem Level Tasks
At the subsystem level, integrate the pre-implemented cores, which are
treated as hard cores, and add the required DFT features to test the
remaining logic and memories that exist in the subsystem hierarchy. The DFT
ports of the existing cores must be properly connected and managed during
integration.
For the manufacturing test, the core-level ATPG patterns are reused and
ported from core to subsystem level without requiring additional re-generation.
The ported patterns are simulated and validated using the VCS tool.
Most of the steps described below are the same for two subsystems:
Subsystem0 and Subsystem1. However, there is major difference in
00_testmax because subsystem0 uses the shadow-server while subsystem1
is subserver controlled. The difference is listed in the following table.
Subsystem0 Subsystem1
00_testmax Insert SMS IP and Insert SMS IP and

shadow server subserver
Subsystem: 00_testmax
This task reads the source RTL design of the subsystem and links to the DFT
views (CTL, ICT, WKS) required for the integration of the cores.
This task generates, inserts, and connects the TestMAX SMS components
required to test the memories that are instantiated in the current subsystem-
level design. This task also integrates and connects the core-level SMS and
IEEE 1500 rings implemented in the cores of the design.
Subsystem0 implements a ring-only shadow server configuration.
Subsystem1 implements a subserver.
The following figure shows the Subsystem0 design before the execution of
this task.

Figure 12: Subsystem0 Before SMS and Access IP Insertion
The task is executed as follows:

1. plan_dft: Memories are identified in the design based on clock tracing by
the TestMAX Advisor and a memory report is generated. The STAR
Planner tool defines the memory grouping based on the requirements
specification and generates the grouping .CSV file.
The ISH file is generated based on the setting for the SMS components
and shadow-server(subsystem0) or subserver(subsystem1) ring for the
SMS IP. This setting is used by the next step.
2. generate_dft: TestMAX SMS MBIST components such as SMS Wrappers,
SMS Processors, and the SMART BIST interface are created. The
subsystem1 subserver or subsystem0 shadow server are generated. UDS
and CPF files for the validate_dft command and the connection file for
the connect_dft command are also generated.
3. connect_dft: The TestMAX SMS MBIST components created by the
generate_dft command are instantiated in the design and connected. In
Subsystem0, the SMS rings are connected directly to the subsystem0
IEEE 1500 interface (see Figure 13). In Subsystem1, the cores SMS ring
is connected to the subsystem1 SMS subserver.
4. validate_dft: The implementation is verified statically (connectivity checks)
and dynamically (integrity check and simulation) to validate the
components, connections, and entire SMS subsystem level system. The
dynamic validation is performed using four predefined basic SMS test
patterns.
Additional patterns are created to demonstrate the pattern generation
capabilities of the TestMAX tools, targeting the SMS Ips in the cores from
the subsystem level.
This task uses the run_testmax.csh shell script.
The Tcl script used by dft_shell: scripts/testmax.tcl

This step produces the following output files:
 ICT and WKS (Workspace) for integration at higher levels
 Constraints files, such as UDS and CPF, for user-defined pattern
generation
The following figure shows Subsystem0 after SMS and Access IP insertion.
Figure 13: Subsystem0 After SMS and Access IP Insertion
The following figure shows Subsystem0 (with Subserver) after SMS and
Access IP insertion.

Figure 14: Subsystem0 (With Subserver) After SMS and Access IP Insertion
Subsystem: 01_testmax
Reads the modified RTL design from the previous step and generate, insert,
and connect the TestMAX DFT components (wrapper, compression, and
OCC) to the design.
This task also connects the core-level DFT compression logic and implements
the DFTMAX/DFTMAX Ultra fabric to target the test modes of the cores and
combine them with the defined test modes of the subsystem. Subsystem0 has
the SIDO feature enabled for the two identical core0 compress modes.
This task is executed as follows:
issues by applying the DFT-related checks and pointing to the potential
DFT violations that should be fixed. You can run this task in GUI mode for
interactive debugging.
2. generate_dft: TestMAX DFT components such as wrapper,
DFTMAX/DFTMAX Ultra codec, Pipeline Scan data, and OCC controller
are created.
3. connect_dft: The DFT components created by the generate_dft command
are instantiated in the design and connected.
This task uses the run_testmax.csh shell script.
The Tcl script used by the dft_shell is scripts/testmax.tcl.

 Modified RTL Verilog design
file (<file>.synth_fc.tcl or <file>.dft_fc.tcl) is generated by the TestMAX
Manager tool
 STIL Protocol files (one for each implemented mode), CTL
DFTMAX/DFTMAX Ultra codec, ensuring the correctness of the behavior and
connectivity of the modified RTL.
The following figure shows Subsytem0 after DFT and DFTMAX/DFTMAX
Ultra fabric insertion.
Figure 15: Subsystem0 (Shadow Server) After DFT and Fabric Insertion
The following figure shows Subsytem1 after DFT and DFTMAX/DFTMAX

Ultra fabric insertion.

Figure 16: Subsystem1 (Subserver) After DFT and Fabric Insertion
Subsystem: 10_ formal

Run the Formality tool to perform the following verification:
 RTL (original) against the SMS-inserted RTL
This task uses the run_fm.csh shell script.
The Tcl script used by the fm_shell is scripts/fm.tcl.
This task generates the reports/*fmv_unmatched_points.rpt report, which
contains the list of unmatched points between the compared designs.
Subsystem: 20_fc
The DFT-inserted subsystem-level RTL is synthesized using the Fusion
Compiler tool if the environment variable $syn is set to fc.
The cores are read as NDM and treated as hard macros, therefore
untouched.
existing codecs inserted by the 01_testmax task.
The script includes commands of that the following implemented features:
 Enhanced in-compile flow in the Fusion Compiler tool

violations.
The resulting netlist can be verified later and simulated using back annotation.
This script reproduces the RM flow:
cp -rf ../../../FC-RM_ S-2021.06/* ./
The default design_setup.tcl file from the RM is replaced with the one defined
for the TestMAX mainstream flow.
 Reports
 NDM
 SPEF
Subsystem: 20_dc
The DFT-inserted subsystem-level RTL is synthesized using the Design
Compiler tool if the environment variable $syn is set to dc. The
compile_ultra command is invoked to obtain better quality of results
(QoR) when you compile designs that have tight timing constraints. The
command performs a bottom-up compilation.
The cores are read in as NDM and treated as hard macros, therefore
untouched.
linked technology library. The scan chains are stitched and connected to the
existing codecs inserted by the 01_testmax step. In addition, the Design
Compiler tool inserts clock gates to save power.
You can run an optional incremental compile on the design to fix hold
violations.
The resulting netlist can be verified later and simulated using back annotation.

This task uses the run_dc.csh shell script. The Tcl script used by the dc_shell
is scripts/dc_dftmax_mm_wrap.tcl.
 Reports
 NDM
Subsystem: 21_formal
Run the Formality tool to verify the RTL (original) against the netlist after
synthesis 20_dc/20_fc.
This task uses the run_fm.csh shell script. The TCL script used by the
fm_shell is scripts/fm.tcl.
This task generates the reports/*fmv_unmatched_points.rpt report, which
contains the list of unmatched points between the compared designs.
Subsystem: 40_tmax_atpg
Subsystem-level pattern generation for the manufacturing test uses the
TestMAX ATPG tool.
The following wrapper modes, OCC modes, and fault models are used to
generate patterns and port the core-level patterns to the subsystem level:
 Subsystem in compression wrp_if mode and cores in wrp_of mode (OCC
active for the transition fault model and OCC in bypass mode for the stuck-
at fault model)
 Subsystem in scan wrp_if mode and cores in wrp_of mode (OCC active for
the transition fault model and OCC in bypass mode for the stuck-at fault
model)
The following figure shows subsystem-level ATPG patterns in wrp_if mode.
Figure 17: Subsystem-Level ATPG Patterns in wrp_if Mode
The following figure shows subsystem-level ATPG patterns in wrp_of mode.

Figure 18: Subsystem-Level ATPG Patterns in wrp_of Mode

 Subsystem in scan wrp_of mode (OCC active for the transition fault model
and OCC in bypass mode for the stuck-at fault model). This model is used
for validation only.
Figure 19: Core-level ATPG pattern Generation From Subsystem
The following modes are exercised only for validation using ported patterns:
 Core-level compression mode (OCC active for the transition fault model
and OCC in bypass mode for the stuck-at fault model)
 Core-level scan wrp_if mode (OCC active for the transition fault model and
OCC in bypass mode for the stuck-at fault model)
All patterns are simulated using the TestMAX ATPG tool (run_sim).
The switching activity for average and peak power is reported
(report_power).
The generated patterns are simulated using the VCS tool in the following
configurations:
The shell netlist generated at the core level is used to speed up the ATPG
and simulation processes.
Subsystem: 42_tmax_atpg_advanced_fault_model
This task generates an advanced fault model for use at the subsystem level in
TestMAX ATPG compression mode. Low-power ATPG is also enabled. The
test sequence is:
1. Run the (pat-sub-A) pattern for the slack-based transition fault model
(Fault-core-A)
2. Run the (pat-sub-B) pattern incrementally for the stuck-at fault model
(Fault-core-B)
3. Fault-simulate the pat-core-A pattern against the dynamic bridge fault list
(Fault-core-C)
4. Fault-simulate the pat-core-A and pat-core-B patterns against the bridge
fault list (Fault-core-D)

5. Fault-simulate the pat-core-A and pat-core-B patterns against the cell-
aware fault list (fault-core-E)
6. Run the dynamic bridge pattern (pat-core-C) incrementally for the Fault-C
fault model (Fault-core-Ci)
7. Run the bridge pattern(pat-core-D) incrementally for the Fault-D fault
model (Fault-core-Di)
8. Run the cell-aware pattern (pat-core-E) incrementally for the Fault-E
(Fault-core-Ei)
All patterns written out in each step are simulated using the TestMAX ATPG
(run_sim) and VCS tools in the following configurations:
This task generates ATPG and VCS simulation reports. Slack data for the
slack-based transition fault is generated in the 30_pt step.
Subsystem: 50_vcs_sms
This task performs the subsystem-level gate-level simulation of pattern
generation for SMS validation. The patterns are linked from 00_testmax.
write/read operation (W(D), R(~D))
 signature_reg_check_tb: Verifies SMS network connection by reading out
the processor ID register
 sms_status_tb: Reads out the SMS status register default value
 bist_all_tb: Verifies all MBIST IPs using the default algorithm and checks
the SMS result by reading out the SMS status register
the testbench, and checks the SMS result by reading out the SMS status
register
The generated patterns are simulated using the VCS tool and the mapped
netlist.
This task generates VCS simulation reports.
Subsystem: 51_vcs_atpg
The ATPG patterns generated at the core level are ported to the subsystem
level for validation and simulation using the VCS tool.
The following figure shows the validation of ATPG pattern porting from the
core to the subsystem level.

Figure 20: Validation of ATPG Pattern Porting From the Core to the Subsystem
The ported core wrapper modes, OCC modes, and fault models are used to
generate patterns at the subsystem level.
Figure 21: Pattern Porting from Core to Subsystem
The following are the ccore0 and core1 patterns ported at subsystem0 and
subsystem1 level for the stuck-at fault model:
 Compression wrp_if mode (OCC bypass)
 Scan wrp_if mode (OCC bypass)
 Scan mode bypass wrp chain (OCC bypass)
The following are the core0 and core1 patterns ported at Subsystem0 and
Subsystem1 level for the transition fault model:
 Compression wrp_if mode (OCC active)
 Scan wrp_if mode (OCC active)
 Scan mode bypass wrp chain (OCC active)
The ported patterns are simulated using the VCS tool in the following
configurations:
 Parallel 0-delay Simulation
This task generates VCS simulation reports and ported patterns.

Subsystem: 61_tmax_diagnosis
In this task, create a virtual failure log of patterns ported from core0, using the
gate-level simulation with fault injection on DFTMAX/DFTMAX Ultra mode.
Run the map_fail_log command to convert the failure log of the
subsystem level to core level. Then use the TestMAX Diagnosis tool to
identify the candidate defects.
The following logic diagnosis test mode with the stuck-at fault model is used
to inject faults. This forces the D pins of the sequential cells to a specific state
and run the simulation to output a .diag (failure log) file.
After the failure log is generated, run the map_fail_log command with the
ale_shell (TestMAX ALE). Then, run the diagnosis on each failure log and
generate reports that locate the candidate defects with a matching percentage
score.
Subsystem: Summary
To sign-off the subsystem level execution, ensure that the simulations are
successful and the fault coverage is acceptable according to the required
metrics.

SoC Level Tasks
At the SoC-level, integrate the pre-implemented cores and subsystems, which
are treated as hard-cores, and add the required DFT features to test the
remaining logic and memories that exist in the SoC hierarchy. The DFT ports
of the existing cores and subsystem, must be properly connected and
managed during integration.
At the SoC-level, the TAP IEEE 1149.1 standard is implemented to control the
internal IEEE 1500 network and resources. The same TAP is used to control
the boundary scan of the SoC which includes the existing BSD segment and
embedded pads.
The internal test mode signals are driven by a tool-inserted test data register
(TDR), which is connected and accessed through the IEEE 1149.1 TAP. The
TDRs contain the test mode definition, which is decoded and written into SPF
files.
For the manufacturing test, the ATPG patterns at the core, and subsystem
levels are reused and ported to the SoC level without requiring additional re-
generation. The ported patterns are simulated and validated using the VCS
tool.
SoC: 00_testmax
This task reads the source RTL design and generates, inserts, and connects
the TestMAX SMS components in the design. It also integrates and connects
the core and subsystem level pre-inserted SMS rings implemented in the
subsystem and core of the design.
This task also inserts and validates boundary scan cells for the existing pads
and then connects the inserted boundary scan cells to the pre-existing
boundary-scan segments to form a boundary scan chain. The following figure
shows the SoC design before the execution of this task.

Figure 22: SoC Before TestMAX SMS and BSD Insertion
This task is executed as follows:

1. plan_dft: Memories are identified in the design based on clock tracing
using the TestMAX Advisor tool and a memory report is generated. The
STAR Planner tool defines the memory grouping based on the user
requirements and generates the grouping CSV file.
The ISH file is generated based on the setting of SMS components and
the top server ring. This setting is used by generate_dft command. The
boundary scan pin map info is also read.
2. generate_dft: TestMAX SMS memory BIST components: such as SMS
wrappers, SMS processors, and the SMART BIST interface are created.
TAP, TDR, boundary scan, and Top server component with E-Fuse
interface are also generated.
3. UDS and CPF files for the validate_dft command and the connection
file for the connect_dft command are generated. The BSDL file for
boundary scan pattern generation and validation is also generated.
4. connect_dft: TestMAX SMS MBIST components created by the
generate_dft command are instantiated in the design and connected.
The SoC-level SMS is connected with Subsystem0 SMS ring to the top-
Server. The top-server also drives the Subsystem1 subserver.
5. validate_dft: The implementation is verified statically (connectivity checks)
and dynamically (integrity check and simulation) to validate the
components, connections, and entire SMS SoC core-level system.
The dynamic validation is performed using five pre-defined basic SMS test
patterns. With custom patterns targeting lower SMS processors, the usage

of the write_pattern command for dumping out vectors in tester-ready
formats is also demonstrated.
6. Validation of BSD: The boundary scan test bench is generated, and the
boundary scan chain and BSR are validated. This BSD pattern is also
validated with the netlist in 53_vcs_bsd task.
This task uses the run_testmax.csh shell script. The Tcl script used by the
 Constraints file
 UDS and CPF files for user-defined pattern generation
 A BSDL file containing pads and boundary scan information
SoC: 01_testmax
Read the modified RTL design from the previous task and generate, insert,
and connect the TestMAX DFT components (compression, OCC, and
boundary scan) in the design. This task handles the TDR test mode by
assigning a test mode value according to the definition and porting the value
into an SPF file for later ATPG usage.
This task also reuses the functional pads for scan input and output
assignments. The core-level DFT compression logic is integrated and
connected in this task. A fabric logic is generated in this task to handle test
modes of the cores and combine them with the defined SoC-level test modes.
The following figure shows the SoC design after the execution of this task.
Figure 23: SoC After TestMAX SMS and BSD Insertion

The task is executed as follows:
issues applying the DFT checks and the potential DFT violations are
pointed out for a fix. It is possible to run this task in GUI (Graphical User
Interface) mode for interactive debugging.
2. generate_dft: The TestMAX DFT components are created:
DFTMAX/DFTMAX Ultra codec, Pipeline Scan Reg, OCC Controller, and
boundary scan.
3. connect_dft: The DFT components created by the generate_dft step
are now instantiated in the design and connected.
This task uses the run_testmax.csh shell script. The Tcl script used by the
 Modified RTL Verilog design
file(<file>.synth_fc.tcl or <file>.dft_fc.tcl) is generated by the TestMAX
Manager tool
 STIL protocol files (one for each implemented mode)
 BSDL file
DFTMAX/DFTMAX Ultra codec, ensuring the correctness of the produced
RTL behavior and connectivity of the modified RTL.

Figure 24: SoC After TestMAX DFT Insertion
SoC: 10_formal
Run the Formality tool to perform the following verification:
 RTL (original) compared with the SMS- inserted RTL
This task uses the run_fm.csh shell script. The Tcl script used by the fm_shell
is scripts/fm.tcl.
This task generates reports for each check step:
SoC: 20_fc
The DFT-inserted SoC-level RTL is synthesized using the Fusion Compiler
tool if the environment variable $syn is set to fc.
The cores are read as NDM and treated as Hard-Macros, and untouched.
existing codecs inserted by the 01_testmax task. In addition, the Design
Compiler tool inserts clock gating to save power.
 Flow enhancement to support the in-compile flow of the Fusion Compiler
tool

violations. The resulting netlist can be later verified and simulated using back
annotation.
This script reproduces the RM flow:
cp -rf ../../../FC-RM_ S-2021.06/* ./
The default design_setup.tcl file, from the RM is replaced with the one defined
for the TestMAX mainstream flow.
 Netlist verilog of the design
 Reports
 NDM
 SPEF
SoC: 20_dc
The DFT-inserted SoC-level RTL is synthesized using the Design Compiler
tool if the environment variable $syn is set to dc. The compile_ultra
command is invoked to obtain better (QoR) when you compile designs that
have significantly tight timing constraints. The command performs a bottom-
up compilation.
existing codecs inserted by the 01_testmax task. In addition, the Design
Compiler tool inserts clock gates to save power.
You can run an optional incremental compile on the design to fix hold
violations.
The resulting netlist can be verified and simulated using back annotation.

SoC: 21_formal
Run the formality tool to verify the RTL (original) against the netlist after
synthesis in the 20_dc or 20_fc task.
This task uses the run_fm.csh shell script. The Tcl script used by the fm_shell
is scripts/fm.tcl.
This task generates reports:
SoC: 40_tmax_atpg
SoC-level pattern generation for the manufacturing test uses the TestMAX
ATPG tool.
The following wrapper, and OCC modes, are used to generate patterns for the
stuck-at fault model:
 SOC top in compression mode and cores and subsystem in wrp_of mode
(SoC OCC active and in bypass mode)
 SOC top in scan mode and cores and subsystem in wrp_of mode (SoC
OCC active and in and in bypass mode)
 SOC core in compression mode and cores and subsystem in wrp_of mode
(SoC OCC active and in bypass mode). This model is used for validation
only.
 SOC core in scan wrp_if mode and cores and subsystem in wrp_of mode
(SoC OCC active and in bypass mode). This model is used for validation
only.
 SOC core in scan mode bypass wrp chain and cores and subsystem in
wrp_of mode (SoC OCC active and in bypass mode). This model is used
for validation only.
 Subsystem in compression wrp_if mode and cores in wrp_of mode
(subsystem OCC active and in bypass mode). This model is used for
validation only.
 Subsystem in scan wrp_if mode and cores in wrp_of mode (subsystem
OCC active and in bypass mode). This model is used for validation only.
o Subsystem in scan mode bypass wrapper chain (subsystem OCC
active and in bypass mode). This model is used for validation only.
o Core level in compression mode (core OCC active and in bypass
mode). This model is used for validation only.
o Core level in scan mode bypass wrp chain (core OCC active and in
bypass mode). This model is used for validation only.
o Core level in scan wrp_if mode (core OCC active and in bypass mode).
This model is used for validation only.

The following wrapper and OCC modes are used to generate patterns for the
transition fault model:
 SOC top in compression mode and cores and subsystem in wrp_of mode
(SoC OCC active and inactive mode)
 SOC top in scan mode and cores and subsystem in wrp_of mode (SoC
OCC active and inactive mode)
 SOC core in compression mode and cores and subsystem in wrp_of mode
(SoC OCC active and inactive mode)
 SOC core in scan wrp_if mode and cores and subsystem in wrp_of mode
(SoC OCC active and inactive mode). This model is used for validation
only.
 SOC core in scan mode bypass wrp chain and cores and subsystem in
wrp_of mode (SoC OCC active and inactive mode). This model is used for
validation only.
 Subsystem in compression wrp_if mode and cores in wrp_of mode
(subsystem OCC active and in the active mode). This model is used for
validation only.
 Subsystem in scan wrp_if mode with cores in wrp_of mode (subsystem
OCC active and inactive mode). This model is used for validation only.
 Subsystem in scan mode bypass wrapper chain (Subsystem OCC active
and inactive mode). This model is used for validation only.
 Core level in compression mode (core OCC active and inactive mode).
This model is used for validation only.
 Core level in scan mode bypass wrp chain (core OCC active and inactive
mode). This model is used for validation only.
 Core level in scan wrp_if mode (core OCC active and inactive mode). This
model is used for validation only.
All patterns are be simulated using the TestMAX ATPG tool (run_sim).
The switching activity for average and peak power is reported
(report_power).
The generated patterns are simulated using the VCS tool in the following
configurations:
SoC: 50_vcs_sms
This task performs the SoC-level gate-level simulation of pattern generation
for SMS validation. The patterns are linked from 00_testmax.

write/read operation (W(D), R(~D)).
 signature_reg_check_tb: Verifies the SMS network connection by reading
out the processor ID register
 sms_status_tb: Reads out the default value of the SMS status register
 bist_all_tb: Verifies all MBIST IPs using the default algorithm and checks
the SMS result by reading out the SMS status register
the testbench and checks the SMS result by reading out the SMS status
register
 shared_eFUSE_verification_tb: Verifies the eFUSE program and
downloads sequences for top server and subserver.
The generated patterns are simulated using the VCS tool and the gate-level
netlist. This task generates VCS simulation reports.
SoC: 51_vcs_atpg
The ATPG patterns generated at the core and subsystem levels are ported to
the SoC level for validation and simulation using the VCS tool.
core in the subsystem to the SoC.

Figure 25: Validation of ATPG Pattern Porting from the Core in the Subsystem to the SoC
core to the SoC.
Figure 26: Validation of ATPG Pattern Porting from the Core to the SoC
The ported core and subsystem wrapper modes, OCC modes, and the fault
models are used to generate patterns at SoC. The following figure shows
pattern porting from core0 (in Subsystem0) to SoC.

Figure 27: Pattern Porting from core0 (in Subsystem0) to SoC
The following are the wrapper and OCC modes of the core0 (in Subsystem0)
patterns ported to SoC for the stuck-at fault model:
 core0Compression wrp_if mode (OCC bypass)
 Scan mode with bypass wrp chain (OCC bypass)
The following are the wrapper and OCC modes of the core0 (in Subsystem0)
patterns ported to SoC for the transition fault model:
 Scan mode with bypass wrp chain (OCC active)
The following figure shows the pattern porting from core0 or core1core1 (in
Subsystem1) to SoC.
Figure 28: Pattern Porting from core0/core1 (in Subsystem1) to SoC
The following are the wrapper and OCC modes of the core0 or core1 (in
Subsystem1) patterns ported to SoC for the stuck-at fault model:

The following are the wrapper and OCC modes of the core0 or core1 (in
Subsystem1) patterns ported to SoC for the transition fault model:
Figure 29: Pattern Porting from core0 (in SoC) to SoC
The following are the wrapper and OCC modes of the core0 (in SoC) patterns
ported to SoC for the stuck-at fault model:
The following are the wrapper and OCC modes of the core0 (in SoC) patterns
ported to SoC for the transition fault model:
Figure 30: Pattern Porting from Subsystem0 or Subsystem1 to SoC
The following are the wrapper and OCC modes of the Subsystem0 or
Subsystem1 patterns ported to SoC for the stuck-at fault model:
 Compression wrp_if mode (OCC bypass)

The following are the wrapper and OCC modes of the Subsystem0 or
Subsystem1 patterns ported to SoC for the transition fault model:
The ported patterns are simulated using the VCS tool in the following
configurations:
SoC: 53_vcs_bsd
The boundary scan pattern generated in the 00_testmax task is imported to
the SoC:53_vcs_bsd task to be verified for gate-level simulation using the
VCS tool in. It uses the common library and netlist generated in the 20_dc or
20_fc task.
SoC: 61_tmax_diagnosis
In this task, create a virtual failure log of patterns ported from core0 (in
Subsystem0) to SoC using gate-level simulation with fault injection in
DFTMAX Ultra mode. Run the map_fail_log command to convert the
failure log of the core level to the SoC level (two levels). Then, use the
TestMAX Diagnosis tool to identify the candidate defects.
The logic diagnosis test mode with the stuck-at fault model is used to inject
faults. This forces the D pins of the sequential cells to a specific state and run
the simulation to output a .diag (failure log) file.
After the failure log is generated, run the map_fail_log command with the
ale_shell (TestMAX ALE). Then, run a diagnosis on each failure log, and
generate the reports that locate the candidate defects with a matching
percentage score.
SoC: 70_vtran
The TestMAX Vtran tool reads the state and time information from logic
simulations and tester programs contained in the original vector file (OVF),
performs some optional processing on this data, and then formats it for a
selected target simulator in the target vector file (TVF).
Logic simulators and ATPG programs create large volumes of test vectors
(VCD/FSDB/STIL/WGL) that need to be translated into test programs for
specific ATEs. The TestMAX Vtran tool translates the test vectors into the
ATE formats.

For more information, see the TestMAX Vtran User Guide. The following
figure shows the functional patterns in a simulation flow.
Figure 31: Functional Patterns in Simulation Flow
The following figure shows the scan patterns in an ATPG flow.

Figure 32: Scan Patterns in an ATPG Flow
The TestMAX ATPG generates STIL patterns, which are translated to the
FLEX format. These are translated to a Verilog testbench, which is validated
by playback simulations.
The following figure shows the translation flow.
Figure 33: Translation Flow
TestMAX Vtran Blocks

The following figure shows the flow of the blocks of the Vtran tool.

Figure 34: Flow of TestMAX Vtran Blocks
 OVF_BLOCK: This block contains commands describing the format of

data in the OVF. These commands specify things such as the name of the
OVF, the pin names and order in the file, various start and terminate
options, and the format of the actual entries in the file.
 PROC_BLOCK: This block is used to specify further processing to be
done on the data prior to output formatting. This includes commands to
scale or offset the timeline, collapse (cyclize) print-on-change data in the
OVF to cycle data by strobing pin states at specified times, adding or
modifying timing on pins, masking pins, performing state translations, and
separating input from output data on bidirectional pins.
 TVF_BLOCK: This block contains commands that tell the TestMAX Vtran
tool how to format the vectors for the TVF.
Requirements
To execute this task, the following are the requirements:
Input: STIL patterns generated by the TestMAX ATPG tool
TestMAX Vtran tool version: S-2021.06-SP5
Implementation Details
The run_vtran.csh file passes the STIL patterns through the following steps to
generate and validate the tester format files:
 stil2ate.cmd: Translates the ported SoC-level STIL patterns generated at
the ATPG step to the .flex Teradyne tester format
 ate2vtb: Translates the generated .flex tester format file to Verilog format
 playback_sims: Validates the translated testbench using VCS simulations
This task generates translated STIL patterns as follows:
 SoC-level patterns stored at: <your ilane install
path>/soc/40_tmax_atpg/outputs/*stil
 Ported patterns stored at: <your ilane install
path>/soc/51_vcs_atpg/outputs/*stil

For demonstrating the translation capability, consider this example where only
four STIL files are translated by setting the vtran_limit variable in the
common_setup.csh file.
There are two values for this variable:
 limited: Four random STIL files are chosen for translation.
 all: All available STIL files are translated. The default value is all.
1. Step1: stil2ate.cmd
ovf_block
begin
ORIG_FILE = "$STIL_PATH";
TABULAR_FORMAT STIL
-CYCLE
-SCAN
;
EXPLICIT_BIDIR_INACTIVE_MODE = Off;
end;
Note:
In the above script, “$STIL_PATH" is the path for STIL patterns given
as input argument to the Vtran command while running stil2ate.cmd.
proc_block
begin
{
#Data Modifications #
}
DONT_CARE = "X";
DISABLE_VECTOR_FILTER;
STATE_TRANS pure_inputs 'U'->'1', 'B'->'1', 'D'->'0', 'A'->'0', 'N'-
>'0', '?'- >'0', 'Z'->'0', 'F'->'0';
STATE_TRANS bidir_inputs 'U'->'1', 'B'->'1', 'D'->'0', 'A'->'0', 'N'-
>'X', '?'->'X', 'Z'->'X', 'F'->'X';
STATE_TRANS pure_outputs 'h'->'H', 'G'->'H', 'B'->'H', 'l'->'L', 'R'-
>'L', 'A'->'L', 'x'->'X', '?'->'X', 'T'->'M', 't'->'M', 'Q'->'M';
STATE_TRANS bidir_outputs 'h'->'H', 'G'->'H', 'B'->'H', 'l'->'L',
'R'->'L', 'A'->'L', 'x'->'X', '?'->'X', 'T'->'M', 't'->'M', 'Q'->'M’;
{
# Output Timing #
}
{

# More... #
}
end;
Note:
In the above script, the STATE_TRANS command is used to specify
state translations from the OVF to the TVF. This is required when
translating data from one simulator to another simulator for states such
as unknown, hi-impedance, and resistive drive.
tvf_block
begin
TARGET_FILE = "./stil2ate.flex";
TESTER_FORMAT Teradyne
-FLEX
WR_TIMESET_FILE = "./stil2ate_timing.flex"
MAX_LINE_LENGTH = "1023"
TIME_STAMPS = "On"
TERMINATE = "HALT"
MAX_REPEAT_COUNT = "65536"
PATTERN_NAME = "pattern_start"
DIGITAL_INST = ""
OPCODE_MODE = ""
SCAN_TYPE = "scan";
MERGE_BIDIRECTS 10HLMXZ;
RESOLUTION = 1.0;
end;
Note:
In the above script, stil2ate.flex and stil2ate_timing.flex are the output
files generated.
2. Step2: ate2vtb.cmd
ovf_block
begin
ORIG_FILE = "../stil2ate/stil2ate.flex“;
TABULAR_FORMAT ultraFLEX
;
AUX_FILE = "../stil2ate/stil2ate_timing.flex_tsets.txt";
COMMENTS = On;
end;

Note:
In the above script, stil2ate.flex and stil2ate_timing.flex files generated
in step1 are given as input.
proc_block
begin
{
#====================#
# Data Modifications #
#====================#
}
DONT_CARE = "X";
STATE_TRANS pure_outputs 'H'->'1', 'L'->'0', 'M'->'Z';
STATE_TRANS bidir_outputs 'H'->'1', 'L'->'0', 'M'->'Z';
{
#=========#
# More... #
#=========#
}
end;
tvf_block
begin
TARGET_FILE = "./ate2vtb_new.v";
SIMULATOR VERILOG_TB
-VERBOSE
TESTBENCH_MODULE = "design_module"
COMPONENT_MODULE = "soc"
INSTANCE_NAME = "u_dut"
TIMESCALE = "1ns / 1ns"
TERMINATE_RUN = "$stop"
;
end;
Note:
In the above script, the ate2vtb_new.v testbench file is generated.
Example Outputs
The following figure shows an example output of a successful stil2ate
translation.

The following figure shows an example output of a successful ate2vtb
translation.
SoC: Summary
To sign-off the SoC-level execution, ensure that the simulations are
successful and the fault coverage is acceptable according to the required
metrics.
You can perform a visual inspection of the design at the end of the
implementation.

ILane Mainstream Flow Application Note

Uploaded by

Document Information

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

ILane Mainstream Flow Application Note

Uploaded by

Copyright:

Available Formats

Synopsys® TestMAX™

Mainstream Flow Application

Synopsys TestMAX Mainstream Flow 2

Synopsys TestMAX Mainstream Flow 3

Synopsys TestMAX Mainstream Flow 4

Synopsys TestMAX Mainstream Flow 5

Synopsys TestMAX Mainstream Flow 6

Synopsys TestMAX Mainstream Flow 7

Product and License Requirements

TestMAX Products and Licenses

Additional Products and Licenses

Synopsys TestMAX Mainstream Flow 8

Libraries to Execute the Test Cases

Synopsys TestMAX Mainstream Flow 9

Installing the Testcase

Synopsys TestMAX Mainstream Flow 10

Synopsys TestMAX Mainstream Flow 11

Synopsys TestMAX Mainstream Flow 12

DFT Features in Mainstream Flow

Synopsys TestMAX Mainstream Flow 13

Block Diagram of the Design

Synopsys TestMAX Mainstream Flow 14

Synopsys TestMAX Mainstream Flow 15

Synopsys TestMAX Mainstream Flow 16

SMS Hierarchical Network

Synopsys TestMAX Mainstream Flow 17

DFTMAX/DFTMAX Ultra Fabric Network

Each core is wrapped with a wrapper cell.

Synopsys TestMAX Mainstream Flow 18

In addition to the core modes, each subsystem implements wrp_if (non-

IEEE 1149.1 TAP Controller and Boundary Scan

Synopsys TestMAX Mainstream Flow 19

Synopsys TestMAX Mainstream Flow 20

Synopsys TestMAX Mainstream Flow 21

Synopsys TestMAX Mainstream Flow 22

The write_dft_constraints command writes out the constraints to

Synopsys TestMAX Mainstream Flow 23

For more information about applying the TestMAX Diagnosis tool to

Synopsys TestMAX Mainstream Flow 24

Synopsys TestMAX Mainstream Flow 25

Fusion Compiler Reference Methodology

Synopsys TestMAX Mainstream Flow 26

Reference Methodology Retrieval System (RMgen)

The Fusion Compiler RM scripts are available at the following location:

Synopsys TestMAX Mainstream Flow 27

Core: 00_0_RTL_to_Gate_compile (Optional)

Synopsys TestMAX Mainstream Flow 28

The dynamic validation is performed using four pre-defined basic sets of

Synopsys TestMAX Mainstream Flow 29

In this task, the following steps are executed:

Synopsys TestMAX Mainstream Flow 30

Synopsys TestMAX Mainstream Flow 31

Synopsys TestMAX Mainstream Flow 32

Synopsys TestMAX Mainstream Flow 33

Synopsys TestMAX Mainstream Flow 34

Synopsys TestMAX Mainstream Flow 35

Figure 11: Placement and Scan Chains View (Fusion Compiler)

Synopsys TestMAX Mainstream Flow 36

00_testmax Insert SMS IP and Insert SMS IP and

Synopsys TestMAX Mainstream Flow 37

The task is executed as follows:

Synopsys TestMAX Mainstream Flow 38

Synopsys TestMAX Mainstream Flow 39

Synopsys TestMAX Mainstream Flow 40