Test_max_manager_user_guide
Test_max_manager_user_guide
Guide
Version U-2022.12-SP3, April 2023
Copyright and Proprietary Information Notice
© 2023 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
Contents
New in This Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Related Products, Publications, and Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3
Feedback
Contents
Isolating Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Specifying a Location for the DFT Logic Insertion . . . . . . . . . . . . . . . . . . . . . . . 34
Passing Options to TestMAX Advisor Using Template-based Flow . . . . . . . . . . . . . 35
Overview of RTL Test Point Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Running RTL Test Point Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Comparison of the set_testability_configuration Command Options . . . . . . . . . 38
Checking the Design for Scan Readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Creating the Test Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4
Feedback
Contents
5
Feedback
Contents
6
Feedback
Contents
A. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
Flow From TestMAX Manager to Synthesis, Generating Patterns, and Simulating
Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
TestMAX ATPG for DRC and ATPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Formal Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Supported GenSys Commands and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7
Feedback
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
Courier bold Indicates user input—text you type verbatim—in examples, such
as
prompt> write_file top
Edit > Copy Indicates a path to a menu command, such as opening the Edit
menu and choosing Copy.
Customer Support
Customer support is available through SolvNetPlus.
Accessing SolvNetPlus
The SolvNetPlus site includes a knowledge base of technical articles and answers to
frequently asked questions about Synopsys tools. The SolvNetPlus site also gives you
access to a wide range of Synopsys online services including software downloads,
documentation, and technical support.
To access the SolvNetPlus site, go to the following address:
https://solvnetplus.synopsys.com
If prompted, enter your user name and password. If you do not have a Synopsys user
name and password, follow the instructions to sign up for an account.
If you need help using the SolvNetPlus site, click REGISTRATION HELP in the top-right
menu bar.
1
Understanding Synopsys TestMAX™ Manager
The TestMAX Manager tool provides a common interface for DFT implementation
capabilities. Inserting DFT features at the RTL stage accelerates the validation of DFT with
the design and it provides faster turnaround time before the physical design stage.
The tool generates the RTL for compression technologies such as DFTMAX and DFTMAX
Ultra compression, and self-test logic such as XLBIST and MBIST. The tool also supports
on-chip clocking (OCC), shift power control (SPC), and core wrapping logic. The tool then
connects the generated RTL to the functional RTL.
It provides lint checks, connectivity checks, and rule checks in addition to those performed
by the TestMAX Advisor and TestMAX ATPG tools. You can perform verification at the
RTL level because the tool can generate testbenches that can be simulated. The tool also
generates constraints for downstream processes.
This chapter includes the following topics:
• TestMAX Manager Design Flow
• Licensing
• check_dft - Checks the RTL design for lint and scan readiness.
• plan_dft - Generates the memory grouping information. For more information about
using the plan_dftcommand, refer to the TestMAX SMS User Guide.
• modify_rtl - (Optional) Modifies the RTL design.
• generate_dft - Generates the DFT IP based on the constraints and the specified
configuration.
• connect_dft - Connects the DFT IP to the RTL.
• validate_dft - Performs lint and rule checking on the IP and the connections of
the IP to the RTL. It performs structural and connectivity verification of memory BIST
components and infrastructure. It also performs simulation-based checks to validate
the complete memory BIST system.
The following figure shows the overall TestMAX Manager design flow:
The following are the steps for the TestMAX Manager design flow:
1. Set up the libraries.
2. Read the design and handle black boxes.
Licensing
You need the Test-Platform-RTL license to invoke the tool. A copy of the Test-
Platform-RTL license is checked out upon invocation and cannot be released until you
exit the tool.
Additionally, the following product licenses are required to use the TestMAX Manager tool:
• TestMAX Advisor – Licenses from this product are checked out when you execute the
plan_dft, check_dft, or validate_dft commands.
• TestMAX SMS – Licenses from this product are checked out and required when you
enable the Memory BIST flow.
• TestMAX XLBIST – Licenses from this product are checked out and required when you
enable the XLBIST flow.
• TestMAX Access – Licenses from this product are checked out and required when you
enable the hierarchical flow when using SMS or XLBIST.
• TestMAX DFT – Licenses from this product are checked out when you enable
DFTMAX, DFTMAX Ultra, or core wrapping.
• TestMAX ATPG – Licenses from this product are checked out during RTL validation
and pattern porting.
• VCS and VCS MX – Enables BIST simulation.
Note:
The TestMAX Manager tool supports a single thread only. Multicore is not
enabled in the TestMAX Manager tool. Therefore, the tool checks out one
Test-Platform-RTL license.
Set the following license variables during the invocation of the tool:
• setenv SNPSLMD_LICENSE_FILE - Specifies the license server hosting the Test-
Platform-RTL license.
• setenv SNPS_MAX_WAITTIME - Specifies the maximum wait time for the first key
license that you require.
• setenv SNPS_MAX_QUEUETIME - Specifies the maximum wait time for checking out
subsequent licenses in the same shell.
2
Working With the TestMAX Manager Tool
You can access the TestMAX Manager tool using a command-line interface called
dft_shell.
Using Tcl, you can extend the dft_shell command set by writing reusable procedures and
scripts. For more information, see the Using Tcl With Synopsys Tools manual.
• To start the command-line interface, see Using the User Interface (UI).
• To exit the tool, use the exit or quit command.
This chapter includes the following topics:
• Configuring the TestMAX Manager Tool
• Using the User Interface (UI)
Before you start the TestMAX Manager tool, ensure that the path to the bin directory is
included in the $PATH environment variable.
To start the TestMAX Manager tool, enter the tool invocation command at the Linux shell.
% dft_shell
If you specify the command with the -file filename option, it executes the specified
script file.
At startup, the dft_shell command performs the following tasks:
• Displays the program header and the dft_shell tool prompt.
• Executes any script files or commands specified by the -file options.
Running the TestMAX Manager 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
3
Preparing the Design
The TestMAX Manager tool uses a design library to store the design and its associated
library information. This chapter describes how to create a design library and how to
prepare and save the design.
This chapter includes the following topics:
• Defining the Search Path
• Setting Up Libraries
• Reading the RTL Design
• Prerequisite to Modifying a RTL
• Modifying the RTL
• Validating the Modified Connections
• Preventing the Creation of Intermediate Hierarchy Objects in the RTL
• Example: Preparing the Design
• Overview of Basic DFT Configuration
• Passing Options to TestMAX Advisor Using Template-based Flow
• Overview of RTL Test Point Analysis
• Checking the Design for Scan Readiness
• Creating the Test Protocol
• lappend - Use the lappend command to add your directories to the default search
path, which is the directory from which you invoked the tool. For example,
dft_shell> lappend search_path <library path>
Setting Up Libraries
A cell library (or lib_cell library) contains basic leaf-level blocks such as standard
logic cells and I/O pads. This type of library is used only as a reference library for design
libraries. It does not have design-specific data, a reference library list, or lower-level
libraries.
Use the create_lib command to create a design library, which enables the tool to read a
netlist, a mixed design, or to read the design memories.
You can optionally specify reference libraries. The reference libraries contain the leaf-
level blocks such as standard cells and hard macros (memories, I/O pads, and so on). To
specify the reference library list when you create the design library, use the -ref_libs
option. For more information, see Specifying a Design Library’s Reference Libraries.
The following script shows a typical library setup:
dft_shell> # Specify a list of technology files
dft_shell> set TECH_FILE
dft_shell> # Specify a list of reference libraries, excluding the
temporary files
dft_shell> set REFERENCE_LIBRARIES NDM_reference_files
dft_shell> # Specify the design library
dft_shell> set DESIGN_LIBRARY "DESIGN_LIB"
The TestMAX Manager tool must read the design libraries as reference libraries that
are built using the create_lib command, when the netlist information or memories are
present.
Note:
The TestMAX Manager tool does not allow any modifications to the files with the
VHDL format.
Use the analyze and elaborate commands followed by the set_top_module command
to read the RTL design.
The analyze command automatically creates HDL template libraries on disk based on
the name of the library provided by the -hdl_library option. The elaborate command
builds the module specified without linking the rest of the design. This allows multiple
elaborate commands to be run before performing the single linking of the entire design.
The top-level module must be one of the modules that is elaborated.
In the TestMAX Manager tool, the RTL files are read in, using the following command:
analyze -format sverilog | verilog rtl_file_path
Note:
The TestMAX Manager tool does not support input RTL styles that have
multiple statements in one line. These input RTL styles causes the
connect_dft command to fail.
Linking the design and setting the top-level module is done using the set_top_module
command. The top-level module must be a module that was previously elaborated with the
elaborate command. The set_top_module command sets the specified module to be
the top-level design, links the entire design, and creates a single block to be used for the
remainder of the design flow.
Set the top module of each of these files using the set_top_module <top_module_name>
command after using the elaborate <module_name> command as shown in the following
example:
dft_shell> set_top_module CGC
dft_shell> analyze -format sverilog ./third_party_occ.v
dft_shell> elaborate third_party_occ
dft_shell> set_top_module third_party_occ
dft_shell> analyze -format verilog ./CGC.v
dft_shell> elaborate CGC
The following example is an output of the analyze command to read RTL files:
analyze -format verilog [list \
SRC/des_a.v \
SRC/des_b.v ]
Running PRESTO HDLC
To populate the read design and elaborate options from the internal data structure, enable
the -adv_design_read_options in the following command:
dft_shell> set_testmax_configuration -adv_design_read_optionson | off
To read SystemVerilog files with a specified file extension and Verilog files in a single
analyze command, use the -vcs "+systemverilogext+ext" option. The files must not
contain any Verilog 2001 styles.
For example, the following command analyzes SystemVerilog files with the .sv file
extension and Verilog files:
dft_shell> analyze -format verilog -vcs "-f F +systemverilogext+.sv"
dft_shell> elaborate ${DESIGN_NAME}
dft_shell> set_top_module ${DESIGN_NAME}
command allows the tool to recognize any new ports or nets created by the create_port
or connect_net commands in the tool. The new ports or nets are added to the generated
RTL when the connect_dft or modify_rtl command is used.
Note:
Ensure that ports are available before you define the scan signals. If the ports
do not exist in the design, use the setup_rtl_flow command and then create
ports using the create_port or the create_port_bus command.
The following example shows how to create ports and buses:
dft_shell> setup_rtl_flow
1
dft_shell> create_port WrapperClock -dir in 1
dft_shell> create_port_bus \SI[5:0] -create_port
1
See Also
• Modifying the RTL
The modify_rtl command also supports post insertion modification. It changes the
RTL only and does not change other files such as the TestMAX Advisor tool connectivity
constraints files. To make changes to any other files apart from the RTL, you should
manually update the files.
You can use the following RTL editing commands directly in the dft shell or in the RTL
editing script file that is specified in the modify_rtl -file option:
• load_rtl — Reads the new RTL required for the RTL edit.
To use the RTL editing commands directly in the dft shell, enable the following app option:
dft_shell> set_app_options -name dft.shell_rtl_edit <true|false>
It is recommended to use the output directory option when writing out modified RTLs:
modify_rtl -validate_conns on -output_directory <out_dir>
Syntax:
dft_shell> modify_rtl \
-file rtl_modification_tcl_file
{
add_connection -instance inst1 \
-pin p1 [-lsb driver_lsb] [-msb driver_msb]
add_connection -port p1 \
-tieoff {1'b0}
[-name netname] [-auto_uniquify]
delete_connection -instance inst1 \
-pin p1 -instance inst2 -pin p2
add_port -name port_name -direction <IN|OUT|INOUT> \
-lsb <lsb_val> -msb <msb_val>
add_instance -name instance name/hiername \
-master master name [-auto_uniquify]
set_parameter -instance <instance name> \
-name <param-name> -value <param-value>
uniquify_instance -name <instance name/hiername> \
-master <new master name>
select_design <design name>
load_rtl <rtl_file_name/path>
load_rtl -enableSV <rtl_file_name/path>
copy_connection -current_driver_inst <inst name> \
-current_driver_pin <pin/port name> \
-new_driver_inst <driver_name> \
-new_driver_pin <pin name> \
[-new_sink_inst <inst name> \
-new_sink_pin<pin/port name>]
set_default_port_name \
-hierarchical_port_name
Expr(#si,#sp,#di,#dp,#sd,#dd,#netname,#xyz)
new_design <designname>
}
[-load_gui on | off ]\
[-output_directory rtl_out_dir]\
[-allow_post_dft_modifications]\
[-update_design_db on | off]\
[-stop_untouched_hierarchy on | off]
where
• -load_gui on|off— Invokes RTL modifier GUI mode. Default is off.
• If the file specified with the load_rtl command has an include file, you must pass the
directory containing the include file as follows:
load_rtl +incdir./testmax/SRC ./des_unit.DFTTOPIP_0.v
• The GenSys default hierarchy separator is double colon (::) . However, the hierarchy
separator used in the TestMAX Manager tool is back slash (/). To change the hierarchy
separator from :: to /, use the set_hierarchy_seperator / command.
Note:
All the options and arguments of a GenSys command might not be applicable
to the TestMAX family of tools. For more information about the commands and
options that are supported in the TestMAX tools, see TestMAX Manager Tool
Commands.
Where the connections.tcl is a Tcl file that contains the list of connections that are added
or deleted.
When the connections are modified, the constraints required for the modified connections
are automatically generated and saved in the modify_rtl_validate_conns_constraints.sgdc
file. These are validated against the modified RTL.
In this example, the top-level port P1 is added and the hierarchical port P2 is ignored.
The existing DFT view is descriptive and describes an existing signal network. For
example, an existing functional clock signal that is also used as a scan clock in test
mode.
• -view spec
The specification view is prescriptive and describes action that must be taken during
DFT insertion. It indicates that the signal network or connection does not yet exist, and
the insert_dft command must create it. For example, a scan-enable signal network
that must be routed to all scannable flip-flops during the insertion of DFT.
Note:
The second specification shows the scan clock as an internal pin. The pin
inherits the waveform of the port signal specified with it.
Use the -map_to option of the set_dft_signal command for clocks (including
TCK, WRCK, and WRSTN signals) but not for the test mode signals, or other
pins and ports.
3. The report generated includes the clock matrix that can be used to define the weighted
clock grouping for XLBIST in the TestMAX Manager tool.
4. Define clock weights by using the clock matrix advice.
For more information about how to configure weighted clock groups, refer to Example:
Configuring Weighted Clocks.
Clocks are defined and grouped as suggested in the table. The only exception is the
vl_sms_WRCK, which is reported as groupable in the report but defined separately
in the clock weights specification. The reason is that the vl_sms_WRCK clock is used
for dedicated wrapper cells and the relationship of vl_sms_WRCK with other clocks is
available when core wrapping is executed, after the synthesis step. Therefore, you must
maintain the clock that is used to drive the dedicated wrapper cells in a separate group
when defining the clock weights.
Isolating Ports
You can isolate specific ports by adding a safe mux before or after the ports in the RTL to
control the propogation of unknown or X values by configuring the port isolation.
Use the following example to use the test_mode port for safe control:
dft_shell> set_dft_signal -type IsolationControl \
-port test_mode \
-view spec \
-active_state 1 \
-test_mode all_dft
Use the following example to isolate the vl_sms_dm0 and vl_sms_dm1 ports and define
the test_mode control signal for default isolation.
dft_shell> set_dft_port_isolation \
-safe_value_1_ports {vl_sms_dm0 \ vl_sms_dm1} \
-iso_control test_mode
where dft_hier_name must be a hierarchical instance that already exists and is not a
library cell, black box, or CTL model. If the specified instance does not exist, the command
is ignored.
By default, all DFT logic is placed within the specified instance. If you want certain
test logic to be within the instance, you must use the -include option of the
set_dft_location command.
• SERVER - This type includes the server logic that controls the TestMAX SMS and
TestMAX Access components when the set_dft_configuration -dft_access
enable command is used.
The options file can include the following TestMAX Advisor commands:
• read_file
• set_option
• set_goal_option
• set_parameter
Note:
To enable the DesignWare flow in the TestMAX Manager tool, use the
set_option dw yes option.
The user_option_file_name file contains the test point analysis rules. These rules are
used by the TestMAX Advisor commands such as check_dft and validate_dft -check
connectivity
The report containing the list of test points is written to the following directory: spg_config/
design_name/dft_shell_goal/spyglass_reports/dft_dsm.
The file name is random_pattern_dc_testpoints.rpt, regardless of the rule run.
You can also prevent a test point by setting the following option:
no_test_point -name module_name | instance_list [-fanin_logic]
[-fanout_logic]
-test_points_per_scan_cell R set_parameter
dft_dc_tp_register_sharing_ratio R
To check the design for scan readiness use the following command syntax:
check_dft [-check lint|dft|all] [-load_gui on|off|run].
all - Default value. Checks RTL for scan readiness and lint
-load_gui on|off|run - Specify the on option to launch the TestMAX Advisor GUI
to help debug issues. Otherwise, TestMAX Advisor runs in batch mode and generates
reports. The on setting launches the GUI to analyze results from a previous run.
The run option loads the TestMAX Advisor GUI and runs the check to analyze.
By default, the TestMAX Advisor tool assumes the designs are read as SystemVerilog.
If you have non-SystemVerilog files that use SystemVerilog constructs, you might see
STX_VE_481 violations. To resolve these violations, use the following configuration file:
set_testmax_configuration -user_opt_file my.txt
For example,
dft_shell> create_test_protocol
Information: Starting test protocol creation. (DFT-3219)
...reading user specified clock signals...
Information: Identified system/test clock port "clk_st" ( 45.0, 55.0).
(DFT-3265)
...reading user specified asynchronous signals...
1
4
The TestMAX Manager DFT Insertion Flow
This chapter describes the complete process behind the TestMAX Manager DFT insertion
flow, which includes the generation of the DFT IP, management of the DFT IP, RTL, and
netlist, the integration of core and SoC levels, and the writing of the test protocol, test
model, and constraint files.
• XLBIST
• On-chip clocking
• IEEE 1500
• SPC
• Core wrapping
• Pipeline scan data
Additionally, the generate_dft command generates files required for the instantiation
and connection of the DFT IP at the required level of design hierarchy in the RTL. It also
generates files required for validation.
During the execution of this command, you can preview the result of the DFT constraint
set.
After running, the command displays information messages that show the following:
• Configuration of the generated IP architectures
• DFT signals used
• Location of the DFT IP generated files and their file names
The generate_dft command creates the IP. For DFTMAX, the following files are
generated:
• <design_name>_DFTTopIP_0.v — Verilog file for the DFT IP
• rtl_modifier_sources.f — File for the connect_dft command to modify the RTL to add
MUXs and so on
• rtl_modifier_connection_commands.t — List of source files for the connect_dft
command
• rtl_modifier_gate_design.tlib — Primitive format library file
• spg_validate_dft_constraints.sgdc — Connectivity and rule check instructions for the
validate_dft command. This file is modified by the connect_dft command as it is
used in the validate_dft step.
The command also prints the implemented connections, as shown in the following
example:
generate_dft
Client Status
--------- ---------
Scan Enable
Wrapper Disable
Logicbist Disable
Mbist Disable
Dft Access Disable
Scan_compression Enable
Testability Disable
Pipe_line_scan_data Disable
Clock_controller Disable
ieee_1500 Disable
- Partition: 'default_partition'
Information: Architecting DFT Scan IP with '4' scan chains in mode 'scan'
Information: Architecting Streaming DFT Compressor IP with '4' inputs /
'4' outputs / '80' internal chains in mode 'scan_comp'
ScanDataIn:
Mode: scan
"si0" -> U_DFT_TOP_IP_0/si[0]
"si1" -> U_DFT_TOP_IP_0/si[1]
"si2" -> U_DFT_TOP_IP_0/si[2]
"si3" -> U_DFT_TOP_IP_0/si[3]
Mode: scan_comp
"si0" -> U_DFT_TOP_IP_0/si[0
"si1" -> U_DFT_TOP_IP_0/si[1]
"si2" -> U_DFT_TOP_IP_0/si[2]
"si3" -> U_DFT_TOP_IP_0/si[3]
ScanDataOut:
Mode: scan
"so0" -> U_DFT_TOP_IP_0/so[0]
"so1" -> U_DFT_TOP_IP_0/so[1]
"so2" -> U_DFT_TOP_IP_0/so[2]
"so3" -> U_DFT_TOP_IP_0/so[3]TestMode:
"TM" -> U_DFT_TOP_IP_0/TM[0]ScanEnable:
"SE" -> U_DFT_TOP_IP_0/test_se Codec clocks:
"clk_st" -> U_DFT_TOP_IP_0/decompClk
"clk_st" -> U_DFT_TOP_IP_0/comprClk
Test Mode Controller Ports
--------------------------
test_mode: "TM"
Test Mode Controller Index (MSB --> LSB)
----------------------------------------
"TM"
Control signal value - Test Mode
--------------------------------
0 scan - InternalTest
1 scan_comp - InternalTest
Note:
For DFTMAX SEQ, use the dft.separate_codec_ip_files application
option to generate separate files for compressor, decompressor, and self-test
controller for each codec. The following files are created when you use the set
app_option -dft.separate_codec_ip_files command:
• des_unit_DFTTopIP_*_compressor.v
• des_unit_DFTTopIP_*_decompressor.v
• des_unit_DFTTopIP_*_selftestcontroller.v
See Also
• Fusion Compiler In-Compile Flow
• Connecting DFT IP to RTL
• Connecting DFT IP to the Netlist
• Validating the Connections Made Within the IP to the RTL
• Identifying Existing Ports When Integrating the Core-Level to the SoC-Level
• Writing Out the Test Protocol and Test Model
• Writing the Constraints File
The in-compile flow provides the flexibility to use the preview_dft command at the gate
level. In addition, you can perform a second set of test DRC checks after the insert_dft
command. During the final compile step (compile_fusion -from initial_place),
the tool accounts for scan reordering during placement if the SCANDEF information is
available.
The constraints generated by the write_dft_constraints command are split into the
following scripts:
• A script to be read before the initial synthesis with the compile_fusion command, to
define the settings that must be applied after elaboration.
• A script to be read after the logic_opto stage of the compile_fusion command,
where the remaining constraints must be applied.
Currently, the file must be split manually.
DFTspecifications
create_test_protocol
dft_drc -test_mode all_dft
run_test_point_analysis
preview_dft
insert_dft
dft_drc -test_mode test_mode
compile_fusion \
-from initial_place \
-to initial_opto
The in-compile flow helps to align the output from the TestMAX Manager tool with the
latest Fusion Compiler reference methodology flow.
The support for the in-compile DFT flow helps to align the output from the TestMAX
Manager tool with the latest Fusion Compiler reference flow, where the following variables
to point to the constraint files from the TestMAX Manager tool:
• $TCL_DFT_PRE_IN_COMPILE_SETUP_FILE - The settings before compile are set.
See Also
• Generating the DFT IP
• Connecting DFT IP to RTL
• Connecting DFT IP to the Netlist
• Validating the Connections Made Within the IP to the RTL
• Identifying Existing Ports When Integrating the Core-Level to the SoC-Level
• Writing Out the Test Protocol and Test Model
• Writing the Constraints File
• When the change_file_names argument is set to on, the tool renames the modified
files with prefix from the add_module_prefix option, except the file containing the top-
module.
See Also
• Checking Unsupported Constructs in the Input RTL
• Defining the Format of the TestMAX Advisor Tool Design Constraints
• Generating the DFT IP
• Fusion Compiler In-Compile Flow
• Connecting DFT IP to the Netlist
• Validating the Connections Made Within the IP to the RTL
• Identifying Existing Ports When Integrating the Core-Level to the SoC-Level
• Writing Out the Test Protocol and Test Model
• Writing the Constraints File
After you generate an audit report, run the connect_dft command to instantiate the
generated DFT IP RTL into your design RTL, connect the DFT IP, and generate the
combined RTL that includes RTL and DFT RTL.
See Also
• Connecting DFT IP to RTL
• Defining the Format of the TestMAX Advisor Tool Design Constraints
2. Set the application option to true in the following command to define the format of the
SGDC constraints:
dft_shell> set_app_options -name \
dft.testmax_scan_enable_shift_only_constraint <true/false>
Note:
The default is false.
◦ When the application option is false, the SGDC constraints are written in the
-invertInCapture mode.
◦ When the application option is true, the SGDC constraints are written in following
formats:
▪ If the scan enable signal type is defined as -view spec, the SGDC constraints
are written in -invertInCapture mode.
▪ If the scan enable signal type is defined as -view existing_dft, the SGDC
constraints are written in the -scanshift mode.
▪ If the scan enable signal type has both the views, the SGDC constraints are
written in the -scanshift mode.
See Also
• Connecting DFT IP to RTL
• Checking Unsupported Constructs in the Input RTL
The reference libraries that use the NDM format are treated as black boxes during the
check_dft command. To prevent this, you can generate the design file and the design
library file by setting the application options in the TestMAX Manager tool.
However, the tool does not generate a top-level edited netlist with instantiated DFT IP
by using this flow. The netlist can be written out using the write_verilog -hier all
command.
See Also
• Connecting DFT IP to Netlist Using TestMAX Manager With DFTMAX Compression
• Generating the DFT IP
• Fusion Compiler In-Compile Flow
• Connecting DFT IP to RTL
• Validating the Connections Made Within the IP to the RTL
• Identifying Existing Ports When Integrating the Core-Level to the SoC-Level
• Writing Out the Test Protocol and Test Model
• Writing the Constraints File
See Also
• Connecting DFT IP to the Netlist
• -load_gui on|off|run
Specify on to launch the TestMAX Advisor tool GUI to help debug issues, otherwise it
runs in batch mode and generates reports.
• -verbose
Specify this option to generate verbose output during the connectivity check.
For example, here is the output for validate_dft -check lint -load_gui
The -check connectivity option of the validate_dft command runs the TestMAX Advisor
tool with the spg_validate_dft_config.prj project and the dft/dft_test_connection
goal.
The -check lint option of the validate_dft command runs the TestMAX Advisor tool
with the spg_validate_dft_config.prj project and the lint/lint_rtl goal.
See Also
• Generating the DFT IP
• Fusion Compiler In-Compile Flow
• Connecting DFT IP to RTL
• Connecting DFT IP to the Netlist
• Identifying Existing Ports When Integrating the Core-Level to the SoC-Level
• Writing Out the Test Protocol and Test Model
• Writing the Constraints File
See Also
• Generating the DFT IP
• Fusion Compiler In-Compile Flow
• Connecting DFT IP to RTL
The write_test_protocol command writes out the STIL Protocol File (SPF) for the test
mode specified. This file is used by the TestMAX ATPG tool during its run_drc command.
Write out the test protocol file after the generate_dft command.
You can use the following command for writing the protocol file from the TestMAX Manager
tool:
dft_shell> write_test_protocol -o output_protocol_file_name \
-test_mode test_mode_name
The following example writes out the SPF file in internal-scan mode called INTERNAL:
dft_shell> write_test_protocol -o des_unit.is.spf \
-test_mode INTERNAL
The following example writes out the SPF in compression mode called CODEC:
dft_shell> write_test_protocol -o des_unit.sc.spf \
-test_mode CODEC
See Also
• Generating the DFT IP
• Fusion Compiler In-Compile Flow
• Connecting DFT IP to RTL
• Connecting DFT IP to the Netlist
• Validating the Connections Made Within the IP to the RTL
• Identifying Existing Ports When Integrating the Core-Level to the SoC-Level
• Writing the Constraints File
The write_dft_constraints command writes out the constraints that you source in
Design Compiler or Fusion Compiler for synthesis. It also writes the constraints for formal
verification to constrain the scan portion to be inactive and the SDC file for timing analysis.
dft_shell> write_dft_constraints -output constr_for_dc.tcl
See Also
• Synthesis of DFT IP and Scan Insertion
• Generating SDC Constraints
• Generating the DFT IP
• Fusion Compiler In-Compile Flow
• Connecting DFT IP to RTL
• Connecting DFT IP to the Netlist
• Validating the Connections Made Within the IP to the RTL
The netlist generated after synthesis and scan insertion can be used for TestMAX ATPG
DRC and ATPG runs.
Note:
If you use the compile_ultra command for synthesis, use the
-no_autoungroup option.
See Also
• Writing the Constraints File
• Generating SDC Constraints
Option Description
-OCC { any|bypass|active} Use only when the capture mode is set. This argument
allows to choose if we want to constraint the timing
analysis with case analysis for pll_bypass signal. The
default value is any, where the two case analysis on
pll_bypass signal appear by default, but are commented
out. When you choose the bypass or activ OCC options
the corresponding case analysis become uncommented.
The active_state of the pll_bypass signal corresponding
to OCC bypass appears as commented out above the
set_case_analysis commands.
Option Description
All of these options control the generation of SDC in shift mode or capture mode with or
without OCC.
See Also
• Writing the Constraints File
• Synthesis of DFT IP and Scan Insertion
5
Hierarchical Flows
The hierarchical flows in the TestMAX Manager tool enable the hierarchical adaptive scan
flows for DFTMAX or DFTMAX Ultra and provide hierarchical support when there are
cores and SMS cores. This chapter explains how to run the hierarchical adaptive scan
flows when there are DFTMAX and DFTMAX Ultra cores.
For more information about the hierarchical support for cores with SMS-inserted
components, see the TestMAX SMS User Guide. See the TestMAX Access User Guide for
information about XLBIST-inserted cores.
This chapter includes of the following topics:
• Hierarchical Adaptive Scan Synthesis (HASS) flow
• Integrating the HASS Flows of Compressed Scan Cores
• Integrating the Hybrid Flow at the Top Level
• Performing Top Level Hybrid Integration With Partitions
• Using Multiple Test Modes in Hierarchical Flows
• Connecting the Shift Power Control Disable Signal to the Core Block
• Limitations of the Integration of Hierarchical Flows With the TestMAX Manager Tool
The hybrid flow is an extension of the HASS flow that provides additional support for
compressed scan insertion for user-defined logic.
Note:
The TestMAX Manager tool cannot perform core level insertion of scan or other
IP without codec. Therefore, you must insert compression in the flows.
After you enable the hybrid flow, configure the hybrid flow integration by using the
following commands:
• Specify the total top-level scan chain count.
set_scan_configuration -chain_count
• Specify the number of compressed scan chains for the new top-level codec.
set_scan_compression_configuration -chain_count
or
• Specify the maximum compressed scan chain length.
set_scan_compression_configuration -max_length
The -target option specifies a list of core and test-mode pairs to use for the top-level test
mode being defined. Each pair consists of a core instance name and a core test-mode
name separated by a colon (:). In compressed scan flows, the list can also contain the
name of the current design to specify that the top-level logic should be active and tested.
6
On-Chip Clocking (OCC)
On-Chip Clocking (OCC) support is common to basic-scan and fast-sequential scan
ATPG and compressed scan environments. OCC flows use the DFT-inserted OCC clock
controller.
The TestMAX Manager tool also supports enhanced OCC functions which are enabled
with the following configuration commands:
dft_shell> set_dft_configuration -clock_controller enable
dft_shell> set_occ_controller_configuration ...
To report the enhanced OCC configurations you can use either the
report_occ_controller_configuration command or the report_dft
-occ_controller_configuration command.
For more information about enhanced OCC functions, see the Enhanced OCC Datasheet.
The enhanced OCC functions are as follows:
• Specifying the occ_reset signal is not required. See Configuring OCC Initialization.
• Stuck-at mode - ATE_CLK (slow_clock) is used in capture, but the pulses are chopped
by the OCC clock chain bits. In this mode, the occ_bypass signal is used as the stuck-
at mode enable signal.
• For backward compatibility, you can generate either OCC_BYPASS mode or OCC
stuck-at mode. The OCC clock-off, OCC at_speed, and functional modes are always
supported in both RTL (OCC_BYPASS and OCC stuck-at modes). To define which
mode is used, see Configuring OCC Stuck-At and occ_bypass Modes.
• You can specify the number of fast clock metastability registers based on your design.
See Configuring the Metastability Registers.
• A cntrl_enable port is implemented to turn off the OCC clocks to save power when a
core is disabled. See Configuring the OCC Controller.
• You can specify the clock-gating cell tech name and port if the ICG Tech cell is
available when OCC is generated (this is not exclusive to the enhanced OCC
functions). See Configuring the Clock Gating Cell.
• The OCC clock chain is clocked by the ate_clk gated by the scan_enable signal. See
Configuring the Clock-Chain Clock Connection.
This chapter includes of the following topics:
• Clock Type Definitions
• OCC Controller Structure and Operation
• Specifying the DFT-Inserted OCC Controller
• On-Chip Clock Flow
Note:
The TestMAX Manager tool does not support the insertion of OCC at the top
level in hierarchical-integration (HASS) flow.
Note:
When you use the ATE_CLOCK definition in the absence of an OCC and try
to use that clock for ULTRA CODEC, it does not connect. Therefore, in the
absence of an OCC, use the Scan_Clock definition.
• Internal clock - The OCC controller-generated Clock is generated from the PLL clock
during capture, and from the ATE clock during shift. The switching between the PLL
and ATE clocks is driven by a synchronized Scan Enable.
• External clock - A primary clock input of a design that directly clocks flip-flops.
The ATE, PLL, and reference clocks' specifications should be defined only when OCC
insertion is enabled. When OCC insertion is not enabled, only the Scan_Clock declaration
should be specified for an external clock.
The following image describes the OCC flow:
capture phase to produce the launch and capture pulses of internal scannable elements
when enabled by the OCC clock chain.
The ATE clock shifts the scan chain. It is also the source clock of the capture clock. The
same ATE_CLK can be used by one or more OCC, or each OCC can have its own ATE
clock.
The OCC controller serves as an interface between the on-chip PLL clock generator
and internal scan chains. This logic typically contains clock multiplexing logic that allows
internal clocks to switch from a slow ATE clock during shift to a fast PLL clock during
capture.
Internal clocks are outputs of the OCC control logic driving the scan cells. Each internal
clock is controlled or enabled by the clock chain and is connected to the sequential
elements in the design.
The OCC bypass signal allows the ATE clock signal to connect directly to the internal clock
signals, thus bypassing the PLL clocks. In this case the ATPG assumes that all the clocks
generated by the OCC receiving the same ATE_CLOCK are balanced in capture. Any
skew requires timing exceptions to be defined.
When stuck-at mode is enabled (with enhanced OCC functions), the OCC_bypass
signal is used as the OCC stuck_at mode enable. In this mode the capture clock is the
ATE_CLOCK, but the pulses are controlled by the OCC clock chain.
The ScanEnable signal enables switching between the ATE shift clock and the PLL clock
signals. ScanEnable must be inactive during every capture procedure.
The OCC TestMode signal must be asserted in order for the clock controller to operate.
When enhanced OCC is enabled, there is not occ_reset interface. However, there is
an ate_clk pulse sequence in the test setup to initialize enhanced OCC functions (see
Configuring OCC Initialization), otherwise, the OCC reset signal is asserted during test
setup to reset the OCC controller flip-flops to their initial states.
To retain the previous delay information, add the -add_delay option during the
configuration of the input and output delays. The following example shows how to retain
the delay information:
The -add_delay option uses the largest delay for maximum constraint and the smallest
delay for minimum constraint.
If you do not add the -add_delay option, the new delay information overwrites the old
delay information.
Defining Clocks
You need to define the reference, PLL, and ATE clocks by using the set_dft_signal
command.
Reference Clocks
Reference clock signals must be defined as -type RefClock in the existing DFT view.
The generate_dft command does not connect them because they are functional signals
rather than test signals. The only effect of defining them is that they are defined in the
test protocol for use by the TestMAX ATPG tool DRC check. For some cases, a reference
clock signal is not needed.
ATE Clocks
The following example shows how to define the signal behavior of the ATE-provided clock
required for shifting scan elements:
dft_shell> set_dft_signal -view existing_dft \
-type ATEClock \
-port ATEclk \
-timing [list 45 55]
By default, the TestMAX Manager tool makes the ATE clock connection at the source port
specified by the -view existing_dft signal definition. To specify a hookup pin to be
used for the clock connection, use the -hookup_pin option in a subsequent -view spec
scan clock signal definition.
For example,
dft_shell> set_dft_signal -view spec \
-type ATEClock \
-port ATEclk \
-hookup_pin PAD_ateclk/Z
You can use the same clock port as both the ATE clock and PLL reference clock.
Note:
You must not use the ATE clocks to drive the clock of scanned flip-flops. The
ATE clock is pulsed after the ScanEnable signal is de-asserted, which is
required to synchronize the ScanEnable signal.
PLL-Generated Clocks
For the TestMAX Manager tool to correctly insert the OCC, you must define the PLL-
generated clocks as well as the point at which they are generated. The following examples
show how to define a set of launch and capture clocks for internal scannable elements
controlled by the OCC controller:
dft_shell> set_dft_signal -view existing_dft \
-type PLLClock -hookup_pin PLL/pllclk1
dft_shell> set_dft_signal -view existing_dft \
-type PLLClock -hookup_pin PLL/pllclk2
dft_shell> set_dft_signal -view existing_dft \
-type PLLClock -hookup_pin PLL/pllclk3
dft_shell> set_dft_signal -view existing_dft \
-type PLLClock -port upper_level_pllclk
The PLL clocks are free running. The OCC controller is placed between the PLL clock and
the scan flip-flops.
Note:
The -P (period) and -timing options can be optionally specified.
Internal Clocks
To provide the correct clock period of internal clocks that are generated from OCC, insert
the period in the set_dft_signal -type PLLClock command.
The following example shows how to configure the clock period of internal clocks, thus
overriding the default :
dft_shell> set_dft_signal -type PLLClock \
-hookup_pin u_pll_gen/pll_clk_2 \
-view spec -period 8 -timing [list 4 5] \
-test_mode all_dft -usage occ
Note:
The preceding command can be used only if enhanced OCC functions are not
enabled.
dft_shell> set_dft_signal -view spec -type pll_bypass -port occ_bypass
dft_shell> set_dft_signal -view spec -type ScanEnable -port SE
dft_shell> set_dft_signal -view spec -type TestMode -usage occ \
-port TM_OCC
The test mode signal must be a dedicated signal for the OCC controller. It must be active
in all test modes and inactive in mission mode. It cannot be shared with the test mode
signals that are used for other purposes, such as test mode selection. In the internal pins
flow, you can specify internal hookup pins for these OCC control signals by using the
-hookup_pin option of the set_dft_signal command. However, you cannot specify
internal hookup pins for ATE clocks or reference clocks.
Note:
The set_occ_controller_configuration command is necessary for
enhanced OCC functions.
Option Description
Option Description
The following example shows the insertion of an OCC controller that controls three clocks:
set_dft_clock_controller -cell_name occ_int\
-ateclock {ATEclk} \
-test_mode_port {occ_test_mode} \
-enable_signal {OCC_en} \
-pllclocks {pll/pllclk1 pll/pllclk2 pll/pllclk3} \
-cycles_per_clock 2
Note:
To insert multiple OCC controllers, use multiple set_dft_clock_controller
commands.
OCC has two alternate modes - stuck-at mode and occ_bypass mode. To generate OCC
stuck-at mode, use the following command:
dft_shell> set_occ_controller_configuration -stuckat_mode true
To initialize OCC, maintain "occ test_mode = 1" and "ScanEnable stable" for N slow_clk
cycles. During this time both fast_clk and slow_clk should be pulsed to flush the internal
registers.
Note:
N = OCC metastability_stages + cycles_per_clock + 4
The OCC initialization sequence (ScanEnable = 0) is generated in the SPF test_setup by
the TestMAX Manager tool. N is calculated on the condition that fast_clk is not slower than
slow_clk.
If fast_clk is slower than slow_clk, you must manually increase the slow_clk pulse cycles
in the test setup. The minimal slow_clk cycles should be:
(metastability stages + cycles_per_clock + 4 ) * fast_clk period / ate_clk_period
To make your own test_setup, keep this initialization sequence before you use OCC. This
sequence can be merged with another shifting sequence, that is, you can run one serial
pattern before any parallel pattern simulation.
If OCC is not initialized correctly, the parallel pattern simulation gets mismatches in the first
several patterns.
Ensure that the following conditions are met to produce synchronized output clock pulses:
• Clocks produced by a single OCC controller can be synchronized to each other. One
OCC controller cannot produce clock pulses synchronized to those from any other
OCC controller, even if the input clocks to each of them are synchronized.
• The rising edges of the synchronized clocks must be simultaneous and clock tree
balancing must be precise enough to allow flip-flops clocked by them to transfer data in
both directions without hold time violations. This requirement applies to the clock trees
at the outputs of the OCC controller. At the inputs of the OCC controller, the clock trees
do not have to be this precisely balanced, because data transfer between different
clocks uses a posedge-to-negedge or a negedge-to-posedge path.
• The clocks must have fixed frequency ratios. The slowest clock for each OCC
controller is called the 1X clock. The other synchronized clocks may be 1X, 2X (twice
the frequency, one-half the period of the 1X clock) or 4X (four times the frequency,
one-quarter the period of the 1X clock). At the 1X clock’s rising edge, all clocks
synchronized to it must also have rising edges.
The default timing that is written into the STIL Protocol Format (SPF) or (CTL) file by
write_test_protocol or by write_test_model are as follows:
To configure the internal clock periods with a user-defined value, use the
test_sync_occ_1x_period application option. The following example describes how to
define application options:
dft_shell> set_app_options -as_user_default \
-name dft.test_sync_occ_1x_period -value 40.0
In set_scan_path specifications, the OCC controller cell name references all clock chains
for that OCC controller. To reference individual clock chains, append an index number
using the colon (:) character:
dft_shell> set_dft_clock_controller -cell_name BIG_OCC -chain_count 2 \
-pll_clocks {(many clocks)} ...
dft_shell> set_scan_path OCC_CHAIN1 -class occ \
-include_elements {BIG_OCC:0} \
-scan_data_in SI_OCC1 -scan_data_out SO_OCC1
dft_shell> set_scan_path OCC_CHAIN2 -class occ \
-include_elements {BIG_OCC:1} \
-scan_data_in SI_OCC2 -scan_data_out SO_OCC2
By default, the clock-chain clock connection shares the first functional clock output of the
OCC controller. This places the clock chain in both the PLL and ATE clock paths.
To use a dedicated clock-chain clock connection from the OCC controller design, set the
following application option:
dft_shell> set_app_options \
-name dft.test_dedicated_clock_chain_clock \
-value true
This creates a dedicated OCC controller clock output for the clock chain that places it in
the ATE clock path only, which prevents it from affecting the high-speed PLL clock path.
The following image shows the shared clock-chain connection and dedicated clock-chain
connection. In both cases, you should consider how the clock-chain clock connection
interacts with clock tree synthesis (CTS).
This creates four metastability stages for each OCC controller (this can be seen after
scan_enable is de-asserted in the fast_clk capture path).
Note:
The ‘value’ must match an available cell in the target libraries, and this cell must
be an ICG cell.
If there is a missing specification in the dft.test_icg_p_ref_for_dft application option,
the ICG is implemented by the TestMAX Manager tool as an RTL module.
If you want to instantiate the ICG library cell in OCC before the ICG library cell is ready,
you must specify the ICG tech-cell name and port using the following command:
dft_shell> set_app_options -as_user_default -name
dft.test_icg_p_ref_for_dft \
-value "my_icg_libray_name:clock:CLK:enable:EN:out:GCLK:test:SE"
Note:
Apart from OCC, the -name dft.test_icg_n_ref_for_dft application option
is used to enable the DFTMAX SEQ and the XLBIST clock-gating cell to use
the negative-level ICG instead of latched gates and AND gates.
Note:
The pll_reset signal is not required If enhanced OCC functions are enabled.
To connect the top-level OCC signals to the core block, use the -connect_to option for
HASS and hybrid flows.
Note:
Basic OCC and enhanced OCC cannot be mixed in one design. If you enable
enhanced OCC in the core level, the set_occ_controller_configration
command must be set in each core and top-level even if there is no OCC
insertion at top-level like in a HASS flow.
Note:
Use the following command only if enhanced OCC functions are not enabled:
dft_shell> set_dft_signal -type pll_reset -port pll_reset
If enhanced OCC functions are not enabled, use the following commands:
dft_shell> set_app_options \
-as_user_default -list \
{dft.test_dedicated_clock_chain_clock true}
dft_shell> set_dft_clock_controller \
-cell_name occ_ctrl \
-ateclock ate_clk \
-pllclocks { pll/pllclk1 pll/pllclk2 pll/pllclk3 } \
-test_mode_port occ_test_mode \
-cycles_per_clock 2 \
-chain_count 1
Creating test_protocol
dft_shell> create_test_protocol
7
TestMAX Manager-Based DFTMAX/DFTMAX
Ultra Compression Insertion
DFTMAX and DFTMAX Ultra scan compression provide scan data compression
technology to lower the cost of testing larger designs. The scan compression technology
reduces manufacturing test costs by delivering a significant test data and test time
reduction with very low silicon area overhead. DFTMAX and DFTMAX Ultra enable scan
compression in the TestMAX Manager tool, which can then be synthesized and taken to
TestMAX ATPG for test pattern generation.
For details about the DFTMAX and DFTMAX Ultra compression architecture and
decompressor and compressor operation, see the TestMAX DFT User Guide.
This chapter includes of the following topics:
• Configuring DFTMAX Compression
• Configuring DFTMAX Ultra Compression
• Sharing Codec Scan I/O Pins
• Verifying the DFT IP at RTL Level
The -inputs and -outputs options are required. There must be enough scan-in and
scan-out signals defined to satisfy the specification.
If you are using user-defined test modes, specify the mode that you must configure
with the -test_mode option. You must define the test mode previously using the
define_test_mode <mode_name> -usage scan_compression command.
The -chain_count and the -max_length options are mutually exclusive. These options
apply to the compression architecture as follows:
If you are also implementing a standard scan mode, these compressed chains might be
used as the base chains to create other modes.
If the number of pins is insufficient, the tool displays the following error message:
Error: Architecting of Load/Unload compressor failed with the given set
of parameters
Information: Skipping dft rtl generation.
Error: 0
To define the external clock chain, use the set_scan_path command. This command
allows you to specify the scan-in and the scan-out of the OCC clock chain.
For example,
dft_shell> set_dft_configuration -clock_controller enable
dft_shell> set_dft_signal -view spec -type ScanDataIn -port occ_si
dft_shell> set_dft_signal -view spec -type ScanDataOut -port occ_so
dft_shell> set_dft_clock_controller -cell_name occ_ctrl
dft_shell> set_scan_path occ1 -class occ \
-include_elements {occ_ctrl} \
-scan_data_in occ_si \
-scan_data_out occ_so \
-test_mode all
The -class occ option indicates that the scan path specification defines a clock chain.
Use the -include_elements option to allow the tool, to change the order of elements or
use the -ordered_elements option to use only the specified order. The -test_mode all
option is required. You can also define multiple external clock chain.
The shift power control chain (SPC) chain is an external (uncompressed) chain outside
the DFTMAX codec. When scan-in completes, the SPC registers contain the group mask
values for the next pattern.
You either concatenate or separate SPC and OCC chains to reduce power or optimize
chain length in your flow.
For more information about using separate and concatenated SPC and OCC chains, refer
the TestMAX DFT User Guide.
Note:
Compressor pipeline is not supported.
The -inputs and -outputs options are required. There must be enough scan-in and
scan-out signals defined to satisfy the specification.
The -chain_count and -max_length options are mutually exclusive; only one is required.
The -clock option specifies which clock to use for the streaming codec. If you do
not specify the -clock option, the following error appears during the generate_dft
command:
Error: Missing codec clock specifications
DFTMAX Ultra compression architecture has additional lock-up latches stage at the output
of compressor.
DFTMAX Ultra compression automatically computes the input and output shift register
lengths that are optimal for the number of scan inputs and outputs and the number of
compressed scan chains.
The advantage of configuring multiple I/Os in a single DFTMAX Ultra IP is that the area
overhead is less as the same codec can be configured with multiple I/Os. Thus providing
a single codec solution. For big designs, you can configure a maximum of 3000 internal
scan chains.
The following figure describes the configuration of DFTMAX Ultra Codec with two scan in/
two scan out and one scan in / one scan out respectively.
Note:
Only the DFTMAX Ultra flow without partitions is supported.
See Also
• Scan Compression and On-Chip Clocking Controllers
Note:
During the configuration. the codec is assumed to be symmetrical and has a
balanced configuration of I/Os.
The mode number argument defines the mode to run, one mode at a time.
The syntax for the multiple I/O configuration is:
dft_shell> set_atpg -streaming_multi_config_mode
Note:
The write_patterns command will write only the patterns generated only for
the last ATPG run. Write patterns for each mode and save the fault list (to be
read back while retaining their code).
For details about defining external clock chains, see Configuring the Clock Chain on
page 80.
The following image displays the dedicated and shared codec I/O connections:
.The following examples describes how to define the I/O sharing configuration:
dft_shell> set_scan_compression_configuration \
-shared_inputs M \
-shared_outputs N \
-integration_only true
The value M specifies the size of the set of shared scan-in pins used for all codec input
connections. The value N specifies the size of the set of shared scan-out pins used for all
codec output connections.
-integration_only true \
-shared_input 6 -shared_output 18
DFTMAX Ultra also supports sharing codec inputs with dedicated codec outputs with
identical cores. The following example shows the core-level and higher-level scripts:
dft_shell> #Level 0 scan compression configuration \
#core_0 scan compression configuration
dft_shell> set_scan_compression_configuration \
-chain_count 80 -input 7 output 7 \
-test_mode [list sccomp]
#core_1 scan compression configuration
dft_shell> set_scan_compression_configuration \
-chain_count 80 -input 7 output 7 \
-test_mode [list sccomp] \
####################################################################
Level 1 scan compression configuration
dft_shell> define_test_mode core_sccomp -usage streaming_compression \
-target [list core_0 sccomp core_1 sccomp] \
-encoding [list TM1 0 TM2 0 TM3 0 \
core_TM1 0 core_TM2 0 core_TM3 1 ]
dft_shell> set_scan_compression_configuration \
-shared_inputs 7-shared_outputs 14 \
-streaming true
-test_mode {core_sccomp}
Conditions
A partition flow is used. The default partition is used for level 1 codec generation, and
partition 1 is used for level 0 core_0/core_1 integration, as shown in the following script:
dft_shell> define_dft_partition P1 -include {core_0 core_1}
dft_shell> current_dft_partition P1
Note:
See Limitations of the TestMAX Manager Tool for the features that are not
supported for RTL testbench.
"si7" = \r8 0 ;
}
Call "jtag_reseed_setup" {
}
Call "reseed_load" {
"si0" = N01 \r16 0 N01 \r16 0 N01 \r16 0 ;
"si1" = \r57 0 ;
"si2" = \r57 0 ;
"si3" = \r21 0 1 \r18 0 1 \r9 0 1000010;
"si4" = 1 \r18 0 1 \r37 0 ;
"si5" = \r12 0 1 \r44 0 ;
"si6" = \r32 0 1 \r7 0 1 \r16 0 ;
"si7" = 001 \r18 0 1 \r17 0 11 \r16 0 ;
}
Call "reseed_load" {
"si0" = N \r5 0 1 \r12 0 N \r5 0 1 \r12 0 N100001 \r12 0 ;
"si1" = \r38 0 111 \r16 0 ;
"si2" = \r57 0 ;
"si3" = \r21 0 1 \r18 0 1 \r16 0 ;
"si4" = 1 \r18 0 1 \r37 0 ;
"si5" = \r57 0 ;
"si6" = \r40 0 1 \r16 0 ;
"si7" = 001 \r18 0 1 \r17 0 11 \r16 0 ;
}
Call "load_unload" {
"cnt_xlbist" := 140;
}
Call "misr_unload" {
"so0" = HLLLHH \r5 L HLHHL;
"so1" = HLLLHLLHLHHHLLLH;
"so2" = HH \r6 L HHLHHLHL;
"so3" = HLLHHLHHLHLHHLHH;
"so4" = HLLHLHLLLL \r6 H ;
"so5" = LHHHH \r8 L HHL;
}
<tb_ name> is a mandatory argument that defines the base name of the Verilog testbench.
Two files are generated: <tb_ name>.v and <tb_ name>.dat.
The -verbose is an optional. The argument enables the verbose mode that displays the
STIL file name and the MaxTestBench run that generates the Verilog testbench.
8
Pipelined Scan Data
You can use the pipelined scan data feature to resolve delay problems associated with
long routes in compressed scan logic. Pipelined scan data is not limited to compressed
scan chain logic, it can be applied to internal_scan or uncompressed modes as well.
The following image displays the pipeline scan architecture:
To use pipelines in hierarchical flows you must have the same number of stages from
the scan into the decompressor inputs. For example, if you have one core with one pipe
and another core with two pipes you must add a balancing pipe stage to the first core. If
the requirement is to add five pipes at the top, then add three shared pipes in addition to
the five pipes. Therefore, after balancing all the pipelines of cores, you can use a shared
pipeline to meet the pipeline requirement of the top.
The pipeline stages for DFTMAX Ultra are as folllows:
• StreamingPipelineStages
• ExternalCyclesPerShift
• SerializerInputPipelineStages
• SerializerOutputPipelineStages
To view the pipeline specification report, use the report_dft -pipeline command:
dft_shell> report_dft -pipeline
Report : Pipeline Specification
Design : des_unit
Version: R-2020.09-SP6-DEV
Date : Mon May 31 16:24:41 2021
****************************************
The polarity of lockup latches can change based on pipeline register clock.
Clock polarity of pipeline flops can be controlled using the following application option :
set_app_options \
-as_user_default \
-list {dft.put_negedge_head_pipeline_flops true|false}
The test protocol file for Internal scan mode does not have any information related to the
pipeline register because it is not needed for this mode.
In the test protocol file, the compressor structures for compressed scan modes has the
following entry in the SPF for pipeline registers:
LoadPipelineStages - Indicates the number of head pipeline stages
UnloadPipelineStages - Indicates the number of tail pipeline stages
For example,
CompressorStructures {
Compressor "U_decompressor_ScanCompression_mode" {
LoadPipelineStages 3;
ModeGroup mode_group;
LoadGroup load_group;
…
Compressor "U_compressor_ScanCompression_mode" {
UnloadPipelineStages 1;
ModeGroup mode_group;
UnloadGroup unload_group;
UnloadModeGroup unload_mode_group0 unload_mode_group1;
By default, the tool adds an optimal number of shared pipeline registers as possible to
minimize cell count, and it uses dedicated pipeline registers only to balance cores of
differing depths. Figure 7 represents the shared pipeline registers when fabric MUX is
used.
In some cases, such as to adjust layout characteristics, you might want to change
the allocation of shared and dedicated pipeline registers. To do this, you can use the
-head_shared_pipeline_stages and -tail_shared_pipeline_stages options of the
set_pipeline_scan_data_configuration command:
set_pipeline_scan_data_configuration \
-head_pipeline_stages total_depth \
-tail_pipeline_stages total_depth \
-head_shared_pipeline_stages shared_depth \
-tail_shared_pipeline_stages shared_depth
The tool uses the specified number of shared pipeline registers along the shared scan
path, then it uses dedicated pipeline registers as needed for the remaining stages to meet
the total pipeline depth target. Figure 8 shows the previous example with a single shared
head and tail pipeline stage.
You can locate the codec from anywhere in the full chip. When you perform high speed
scan shifting, long routing lines are created depending on the location of the codec.
Therefore, pipeline stages are needed either before or after the fabric accordingly.
You can add the pipeline before and after MUX from the top-level. Use the
-head_shared_pipeline_stages and -tail_shared_pipeline_stages command
options for sharing pipelines before and after the fabric MUX.
Use the following example to configure the pipelines accordingly:
dft_shell> set_pipeline_scan_data_configuration \
-head_pipeline_stages 3 \
-head_pipeline_clock clk_st \
-tail_pipeline_stages 3 \
-tail_pipeline_clock clk_st \
-head_shared_pipeline_stages 1 \
-tail_shared_pipeline_stages 1 \
-head_scan_flop true \
-tail_scan_flop true
9
Advanced DFT Architecture Methodology
This chapter describes the advanced DFT architecture, related methodology, and
processes in the following topics:
• Multiple Test Modes
• Defining Test Modes
• Defining the Usage of a Test Mode
• Defining the Encoding of a Test Mode
• Internal Pins Flow
• Core Wrapping
• Dedicated Core Wrapping
• Shared Core Wrapping
• Compressing Wrapper Chains
• IEEE 1500
You can either configure the default mode and define additional modes or you can create a
new set of named modes without using the default test mode.
If the internal pins flow is not enabled an error occurs when using this flow.
The option -hookup_pin can be used to hookup internal pins using the set_dft_signal
command.
When defining DFT signals, define each internal pins signal by using the -hookup_pin
option without -port option.
dft_shell> set_dft_signal -view spec -type TestMode \
-hookup_pin U_TEST_CTRL/TM_OUT[1]
dft_shell> set_dft_signal -view spec -type TestMode \
-hookup_pin U_TEST_CTRL/TM_OUT[0]
Core Wrapping
A core should always be wrapped to test core logic separately from top-level logic. A
wrapped core has a wrapper chain that allows the core to be isolated from the surrounding
logic. A wrapper chain is composed of wrapper cells inserted between the I/O ports and
the core logic of the design.
The TestMAX Manager tool supports the following core wrapping flows:
• Dedicated core wrapping
• Shared core wrapping
Core wrapping is primarily intended to wrap core data ports. The following ports are
excluded from wrapping:
• Functional and test clock ports
• Asynchronous set or reset signal ports
• Scan-input, scan-output, scan-enable, and other global test signal ports
• Wrapper signal ports
• Any port with a constant test signal value defined
The wrapper chain operates in one of four modes - inactive, inward-facing, outward-facing,
or safe.
When core wrapping is enabled, the following core wrapping test modes are created by
default:
• wrp_if
• wrp_of
The following table lists the supported and unsupported options for the
set_wrapper_configuration command:
reuse_threshold hier_wrapping
chain_count mix_with_scan_cell
test_mode use_system_clock_for_dedicated_wrp_cells
mix_cells gate_cells
depth_threshold add_wrapper_cells_to_power_domain
input_wrapper_cells partition
output_wrapper_cells ded_hier_path
scan_cells ded_hier_wrap_clock
safe_state feedthrough_chains
hold_mux_for_shared_wrapper_cells
To avoid a wrapper cell from being inserted on a port, you can use the
set_boundary_cell -type none -port command. To configure port-specific wrapper
settings, use the following command:
dft_shell> set_boundary_cell -class wrapper \
-ports [list port1 port 2] \
-type none
The following table lists the supported and unsupported options for set_boundary_cell:
class pins
type
port
location
instance
shift_clk
reuse_threshold
exclude
add_shared_wrapper_cell_only
For more information about the command and options used for core wrapping, refer to
Synthesis Manpages.
When the wrapper insertion client in enabled, you must specify the wrp_shift signal type,
for the TestMAX Manager tool. If you need to reuse a single port for both signal types
(scan_enable and wrp_shift), you must specify the signal types as below:
dft_shell> set_dft_configuration -wrapper enable
dft_shell> set_dft_signal -type ScanEnable -port scan_enable -view spec
-active_state 1
dft_shell> set_dft_signal -type wrp_shift -port scan_enable -view spec
-active_state 1
Note:
The TestMAX Manager tool does not infer the wrp_shift attribute for a signal
defined only with the scan_enable signal.
The value of the -reuse_threshold option to enable dedicated core wrapping is -1.
If you need to have a different wrapper shift signal for the input and output cells, you must
use the commands:
dft_shell> set_dft_signal -type input_wrp_shift \
-port input_wrapper_shift_signal \
-view specset_dft_signal -type output_wrp_shift \
-port output_wrapper_shift_signal \
-view spec
To specify the number of wrapper chains that the codec must support in the scan
compression mode, use the following command:
dft_shell>set_wrapper_configuration \
-chain_count <N>\
-test_mode Scan_compression_mode
M is the number of wrapper short chains that the codec should support in the scan
compression mode.
The tool specifies N/2 input and N/2 output wrapper chains automatically. For most
designs, the input wrapper chain count is not equal to the output wrapper chain count.
To specify the input and the output wrapper chain counts separately, use the following
command.
dft_shell> set_wrapper_configuration -input_chain_count <N1>
-output_chain_count <N2> -test_mode sccomp
N1 is the number of input wrapper chains and N2 is the number of output wrapper chains.
To specify the number of wrapper chains to insert when implementing a XLBIST codec,
use the following configuration:
dft_shell> set_wrapper_configuration \
-chain_count <X>\
-test_mode {wrp_of_extest_mode_name}
dft_shell> set_wrapper_configuration \
-chain_count <Y> \
-test_mode {XLBIST_test_mode_name}
X is the number of wrapper chains to insert in the extest mode (wrp_of). Y is the number of
wrapper short chains to insert in the codec in the XLBIST mode, and Y>=X>0.
Note:
In a scenario where XLBIST and scan compression modes exist the wrapper
chain count for scan compression mode is considered.
The following set_wrapper_configuration options are not supported for the XLBIST-
only shared wrapper configuration:
• mix_cells
• mix_with_scan_cells
• safe_state
• max_length
To enable the EXTEST codec in the Fusion Compiler tool, use the following application
option:
dft_shell> set_app_options -as_user_default\
-name dft.scan.enable_general_multimode_support
-value true
The following example shows how to define the EXTEST codec to the
compressed_wrp_of test mode.
dft_shell> define_test_mode compressed_wrp_of \
-usage {wrp_of scan_compression} \
-encoding [list TM1 1 TM2 0 TM3 1]
The following example describes the EXTEST codec wrapper configuration for the
compressed_wrp_of test mode.
dft_shell> set_wrapper_configuration -reuse_threshold -1
dft_shell> set_wrapper_configuration -chain_count $ext_sc \
-test_mode [list compressed_wrp_of]
dft_shell> set_wrapper_configuration -chain_count $wrp_channel_count \
-test_mode [list wrp_of]
You can further include the compression_wrp_of test mode in the OCC chain and define
inputs and outputs for the compressed_wrp_of test mode by using the following example:
dft_shell> set_scan_path my_occ_chain \
-include_elements [list core_occ_ctrl_upper \
core_occ_ctrl_local rst_ctrl] \
-test_mode [list sccomp scan wrp_if compressed_wrp_of]
Note:
Use the following command write_test_protocol -test_mode my_wrp_of
-out ../outputs/des_unit.my_wrp_of.spf to write out the protocol file for
the EXTEST test mode.
The following output displays when you run the generate_dft.log command for the
EXTEST codec configuration:
Information: Architecting DFT Extest Wrapper IP with '2' wrapper chains
in mode 'wrp_of'
Information: Architecting Streaming DFT Compressor IP with '7' inputs /
'7' outputs / '80' internal chains in mode 'sccomp'
Information: Architecting '2' Input Wrapper Chains / '2' Output Wrapper
Chains / '76' Scan Chains
Information: Architecting DFT Compressor IP with '2' inputs / '2'
outputs / '4' internal chains in mode 'my_wrp_of'
Information: Compressor will have 100% x-tolerance
Information: shift power control length is '10'
Information: Architecting DFT XLBist Compressor IP with '80' internal
chains in mode 'xlbist'
Information: Architecting '2' Input Wrapper Chains / '2' Output Wrapper
Chains / '76' Scan Chains
IEEE 1500
Using IEEE 1500 test-mode control logic provides a standard interface for test mode
control. You can use the IEEE 1500 insertion feature to add this IEEE 1500 test mode
control logic.
To use a DFT-inserted IEEE 1500 controller for test-mode control at the core level, first
enable 1500 insertion with the set_dft_configuration command and then define the
DFT signals:
dft_shell> set_dft_configuration -ieee_1500 enable
dft_shell> set_dft_signal -view spec -type WSI -port port
dft_shell> set_dft_signal -view spec -type WRSTN -port port -active_state
0
dft_shell> set_dft_signal -view spec -type WRCK -port port
dft_shell> set_dft_signal -view spec -type CaptureWR -port port
dft_shell> set_dft_signal -view spec -type ShiftWR -port port
dft_shell> set_dft_signal -view spec -type UpdateWR -port port
dft_shell> set_dft_signal -view spec -type SelectWIR -port port
dft_shell> set_dft_signal -view spec -type WSO -port port
The width of the instruction register can be defined using the following command:
dft_shell> set_ieee_1500_configuration -wir_width 4
When you define your DFT signals, do not define the following test-mode signals, that are
driven by the test-mode core data register (TMCDR) bits instead:
• Test-mode signals for multiple test-mode selection
• On-chip clocking (OCC) controller test-mode signals and PLL bypass signals
10
Modifying the SPF
The TestMAX Manager tool generates the SPF protocols automatically, based on the test
modes defined by the user, where each test protocol can define multiple PatternExec
when OCC is enabled.
However, with the adoption of hierarchical ATPG flows, where the top-level constraints
may be different from the default settings, the SPF needs to be modified to satisfy different
constraint settings at the top level such as cascaded OCC, SPC implementation, and so
on.
To do this, you can modify the SPF at each hierarchical level through the UI.
This chapter includes of the following topics:
• User Interface
• Setting the SPF Constraints
• Reporting the SPF Constraints
• Removing the SPF Constraints
• Writing a Protocol With SPF Constraints and Single PatternExec
Note:
Depending on the current test mode, you can modify existing constraints,
add constraints in the test protocol file, or edit test protocol file for a particular
PatternExec as required.
User Interface
This section shows the following tasks:
• Adding/modifying SPF constraints
• Writing a protocol with SPF constraints
• Removing test protocol constraints
• se_delay - Defines the last clock shift for ScanEnable de-assertion timing margin for
XLBIST.
The defined constraints are applied to the current test mode (defined with
current_test_mode) and is written in the protocol which is written after the
specification. The options -name and -alias are mutually exclusive. The usage of -type
DataRegister assumes that the TDR/UDR registers have been inserted or recognized,
while the usage of -alias <se_delay|capture_window|fastclock_margin> assumes
XLBIST is inserted.
The following example shows the usage of the set_spf_constraint command to edit the
procedure for all sections:
The following example shows the creating of an arbitrary PatternExec based on existing
PatternExec, using the -pattern_exec option of the write_test_protocol command for
constraints defined with the set_spf_constraint command:
Example 15 Writing a protocol file with a particular PatternExec and SPF Constraints
dft_shell> write_test_protocol -out ../outputs/${design}.subsys_scan.spf
-pattern_exec subsys_scan -program
Info: Applied SPF constraints defined for the test mode subsys_scan
Information: Writing Protocol for test mode subsys_scan
in /
remote/testcases/TC100/112020/3450469/xa_dft/iLane/iLane_Mainstream_Desig
n_DC_0.3_validation/subsystem0/01_testmax/outputs/subsystem0.subsys_scan.
spf
1
dft_shell>
Note:
Specified constraints are applied whether the command is called with the
-test_mode or -pattern_exec options. The -test_mode and -pattern_exec
options are mutually exclusive, and would be considered if they are not defined
by the current test mode.
11
Limitations of the TestMAX Manager Tool
This chapter provides the list of limitations of the TestMAX Manager tool.
The TestMAX Manager tool does not consist of a GUI interface.
The following features are not supported:
• Retiming registers
• Pipeline scan enable
• Compressor pipeline
• Insertion of OCC at the top-level in hierarchical adaptive scan synthesis (HASS) flow
• DFT/MBIST IP insertion inside the VHDL modules
• Hierarchical core wrapping
Dedicated wrapper insertion is supported at any level that does not have a generate
block as a part of the hierarchical path. It is not supported below any generate
hierarchy in the RTL.
Limitations of the internal hookup pin in the set_dft_signal command:
• Instance pins inside generate hierarchy are not supported as hook-up pins.
• Complex ports such as multi-dimensional ports, interface ports, array of interface, or
structure ports are not supported, for the set_dft_signal command or for hook-up
pins in the following scenarios:
◦ Generate block
◦ Nested parameterized interface
◦ Task and functions inside parametrized interface
◦ Structure within interfaces
◦ Nested array of interfaces
• Escaped instance or port names are not supported as set_dft_signal or hook-up
pins.
The following features are not supported for generating Verilog testbench:
• Shift power controller supported with SPC disabled
• DFTMAX ULTRA XTOL patterns
• Scan fabric
Limitations while modifying the SPF:
• Standalone Patternexec edits.
• 1149.1 and 1687 Register Programming.
• Multiple set_spf_constraint commands must be used for the ports to be added or
updated in the SPF, as different data inputs with the same value cannot be specified
with the -name option.
• Multiple set_spf_constraint commands must be used with the -procedure option to
update constraints in specific procedure sections.
Limitations of OCC
• Synchronized OCC is not supported.
• SDC and SGDC automation is not supported.
• Asynchronous (Reset) controller is not supported for none-XLBIST/SEQ mode.
`undef P
`define P 7 // change in macro value
module mod2
input P1 [`M1:0] // macro value 7
…
endmodule
• Name clash between block level parameter and module level parameter
The following SystemVerilog constructs are not supported:
• Array of interface
• Complex ports such as multi-dimensional ports, interface, array of interface, or
structure ports are not supported in the test path for wrapper or OCC insertion. The
complex ports are also not supported in the test path for internal hook-up pin or the
set_dft_signal port.
• Parameterized Interface
Flow might not work if there are multiple instantiations of same interface with different
parameter values.
• Partially connected structure port and signal
The following example describes a partially connected structure port in a RTL
construct:
// struct declaration
typedef struct packed {
logic [OCP3_DATA_MSB:0] sdata;
logic [1:0] sresp;
} ocp3_sdata_t;
module test ( …)
// struct ports
output ocp3_sdata_t ocp3_sdata;
output ocp3_sdata_t ocp3_sdata1;
…..
u0 mid (
.data (SData),
.resp (SResp),
.sdata (ocp3_sdata1)
……
endmodule
module bot1(.*);
assign out1 = in1 & in2;
endmodule
module bot2(.*);
assign out1 = in1 * in2;
endmodule
endmodule
endmodule
• Nested module
The following example describes a nested module in a RTL construct:
module instan2 #(parameter p1 = 6, parameter p2 = 15)
(input signed [p1-1 : 0] in1,
input signed [p1-1 : 0] in2,
module nested_mod1;
nested_mod2 #(p1, p2) I1(in1, in2, w1);
nested_mod2 #(p1, p2) I2(w1, w1, out1);
always @*
for(count = 0; count < DATA; count++)
buffer[count] = data[count];
initial
sum = '0;
endinterface
int count;
intf #(WIDTH2,WIDTH1)inst(data);
• Type parameters
module bot1(.*);
input [5:0] a, b;
output [9:0] c;
assign c = a + b;
endmodule
module bot2(.*);
assign c = a * b;
endmodule
The following example represents a task and functions inside a SystemVerilog in a RTL
construct:
interface intf_AB (input bit clk);
logic ack;
logic ready;
logic send;
logic [31:0] data;
A
Appendix
This appendix includes of the following topics:
• Flow From TestMAX Manager to Synthesis, Generating Patterns, and Simulating
Patterns
• TestMAX ATPG for DRC and ATPG
• Simulation
• Formal Verification
• Supported GenSys Commands and Options
Simulation
VCS simulation can be done using the scan vectors and Verilog testbench written out from
the TestMAX ATPG tool.
The following are the VCS commands to run serial and parallel simulations in zero-delay
mode (no timing):
## Serial Simulation
vcs -R -full64 -v ./for_tmax.v \
serial_testbench_name vcs_simulation_libraries \
-o simv_serial_stuck_stil_zd -Mdir=csrc_serial_stuck_stil_zd \
override_timescale=1ns/100ps \
+delay_mode_zero +tetramax +define+tetramax_serial \
-Marchive=512 +libext+.v\
-l serial_simulation_logfile_name
## Parallel Simulation
vcs -R -full64 -v ./for_tmax.v \
parallel_testbench_name vcs_simualtion_libraries \
-o simv_parallel_stuck_stil_zd -Mdir=csrc_parallel_stuck_stil_zd \
override_timescale=1ns/100ps \
+delay_mode_zero +tetramax +define+tetramax_parallel \
-Marchive=512 +libext+.v \
-l parallel_simulation_logfile_name
Formal Verification
To check the functional equivalence between your RTL with the DFT-inserted and
the instantiated RTL, use the formal verification constraint files generated by the
write_dft_constraints command with your formal verification tool. This formal
verification constraints file contains the constraints to put your design in Functional mode.
You still need to define the do not verify constraints if you have test-specific scan out ports
and so on to ensure your design is functionally equivalent.
The following example shows the supported command and options to add connections to
ports and instances by using theadd_connection command:
add_connection -instance <inst/hierinst> -pin <p1> [-lsb <lsb>]
[-msb <msb>]\
-instance <inst/hierinst> -pin <p2> [-lsb <lsb>] [-msb <msb>]
[-name <netname>][-auto_uniquify]
add_connection -instance <inst/hierinst> -pin <p1> [-lsb <lsb>]
[-msb <msb>]\
-port <p2> [-lsb <lsb>] [-msb <msb>] [-name <netname>]
[-auto_uniquify]
add_connection -port <p1> [-lsb <lsb>] [-msb <msb>]\
-port <p2> [-lsb <lsb>] [-msb <msb>] [-name <netname>]
[-auto_uniquify]
add_connection -instance <inst/hierinst> -pin <p1> -tieoff {1'b0}
[-name <netname>] [-auto_uniquify]
add_connection -port <p1> -tieoff {1'b0} [-name <netname>]
The following example shows the supported commands and options to delete ports and
instances using the delete_connection command:
delete_connection -instance <inst1> -pin <p1> -instance <inst2> -pin <p2>
delete_connection -instance <inst1> -pin <p1> -port <p2>
delete_connection -port <p1> -port <p2>
For more information about the commands, options and arguments, see GenSys Tcl
Commands Reference Guide.