Tessent Command Study Notes.

1. write_design: Write the current design into the specified file in the Verilog
netlist format.

-output_directory, specify the output directory.

You cannot use the write_design command to overwrite a file containing RTL
modules that was read using the read_verilog command .

If you read a flat model using the read_flat_model command , then write_design is
disabled.

Usage 1 - This use case writes out only the interface definition of the specified
module. Port and parameter definitions are saved, but the rest of the module
content is deleted. This has no effect on the module definition in memory, only the
content of the file being written out. If the -modules option is not specified, the
interface of the current design is written out.

Usage 2 - This use case writes out the modules created in the rtl context. The
created modules are created using the create_module command. These modules do
not have source files associated with them, so a source file must be specified for
them using the -output_file option. All created modules can be written to a single file
using the -created option. However, if the modules are created in different
languages (VHDL or Verilog), they must be written to different files (creating a
module generates the RTL code for the corresponding module, which can then be
synthesized into a netlist. RTL code is generated in both -rtl and -no_rtl contexts).

If you do not specify the -modules or -created options, the tool does the following: "-
modules [get_current_design] -hierarchical". In this case, if the current design is a
created module and the -output_file switch is not specified, the tool will generate an
error. When specifying the -modules option, only create modules can be specified,
otherwise, an error will be generated.

Usage 3 - This use case writes out a read module in an rtl context (in an rtl context,
the rtl code that creates the module is compiled together with other rtl code and
written to the same directory because of the compilation). Because RTL can contain
many specifications that affect how it is compiled later, the tool preserves the
contents and order of the RTL files when writing them out. Therefore, read modules
can only be written out using the -output_directory or -original_location switch. The
-output_file option is not allowed for read modules in an rtl context.

Usage 4 - This use case writes out read-in or create modules in no_rtl context. In
no_rtl context, design modules are written out with all compiler specifics removed,
thus removing dependencies on file order, allowing any modules to be linked into a
common file, and merging read-in modules and create modules into the same file.

1 Ashwani DFT
Usage 5 - This use case writes out the graybox view of the current design to a single
file, and only those instances and nets that have the preserve_in_graybox attribute
set to true are saved in this file. All other nets and instances are deleted. This
attribute can be set using the set_attribute_value command, but is usually added
using the analyze_graybox command.

If the "analyze_graybox -scan" command is issued in the patterns -scan context,

"write_design -graybox" generates a scan graybox, and if the "analyze_graybox -
ijtag" command is issued in the patterns -ijtag context, "write_design -graybox"
generates an IJTAG graybox (What is the difference between scan and IJTAG
graybox?)

Usage 6 - This use case creates a dft_inserted_designs directory containing the

modified design created with the custom script, writes it to the new
dft_inserted_designs directory if elaborate ICL is used, and updates the
tessetn_design_id attribute to match the new design_idl defined with the
set_context command. The attached PDL files are also copied, and a .tcd file and
a .tsdb_info file are created. Use this case when you want to customize the edit
script. Save to TSDB using "write_design -tsdb" and can be read back using the
read_design command. An IJTAG graybox view is also created when the "-
create_ijtag_graybox on" switch is specified.

Usage 7 - This use case writes out the graybox view in the dft_inserted_designs
directory. When using the -graybox switch, an error will be generated if the
analyze_graybox command is called first. The graybox view can be saved in a
dft_inserted_designs directory previously created using the "write_design -tsdb" or
"insert_test_logic -write_in_tsdb on" commands. If the current "set_context -
design_identifier" value does not match the existing dft_inserted_designs directory,
a new directory will be created to hold the associated files: ICL, PDL, TCD and TSDB
files.

Usage 8 - The -softlink_netlist usage can only be used in the -no_rtl context and can
be used after the setup mode design is completed. It creates a dft_inserted_designs
directory for the read-in netlist, so that it can be easily loaded using the read_design
or run_testbench_simulations commands. This option is typically used to create
a tsdb directory for the post-synthesis netlist when scan insertion is not done in the
Tessent Shell. When seedling insertion is done in the Tessent Shell, the post-
synthesis TSDB view is created by "insert_test_logic-write_in_tsdb on". It is also used
to create a TSDB entry for the post layout netlist, for example, the read_design
command can be used to load the netlist in ATPG, create a graybox view when in a
wrapped core, and automatically load the design in run_testbench_simulations.
When the "-create_ijtag_graybox on" switch is specified, an IJTAG graybox view is
automatically created.

2. set_dft_specification_requirements: specifies the requirements for DRC

checking, including DFT specifications;

2 Ashwani DFT
-memory_test
specifies whether to check and implement memory test;

-memory_bisr_chains
specifies whether the current level should insert or connect MBIST chains.

-memory_bisr_controller
specifies whether the current level should be inserted into the MBIST controller.

logic_test on|off
specifies whether logic test is checked and implemented by design rules.

3. add_dft_signals: Static or dynamic DFT signals, used to control various aspects

of the DFT logic. There are several pre-registered (already defined, with special
meanings, can be added using the add_dft_signal command without
customization) that can be used to control the circuit during multiple test modes.

Use the report_dft_signal_names command to report the registered DFT signals, and
use the register_static_dft_signal_names command to register additional signals.

Static DFT signals are divided into the following groups:

global_dft_control – contains signals used to control global resources, for example,

clocking and power management circuits.
logic_test_control – defines the signals used to configure various aspects of the
circuit during logic test mode.
scan_mode - defines the signals used to configure scan chains to various scan
configurations during logic test mode. When using the scan_mode (edt_mode,
multi_mode, etc.) signal, only one mode can be active at a time.
The logic_test_control signals include ltest_en, which is used to put the circuit into
logic test mode. This signal is systematically set to 1 when performing any logic test.
int_ltest_en and ext_ltest_en are used to put the circuit into internal or external
mode. An internal scan chain containing a wrapper and core in scan mode can be
operated in internal mode by keeping int_ltest_en 1. The same scan chain
configuration can be converted to unwrapped mode by setting int_ltest_en to 0.

The memory_bypass_en signal is another example of a logic_test_control signal.

When set to 1, the tool performs ATPG in scan mode with the memory bypass logic
enabled. This configuration is used to cover most faults. When set to 0, the tool
keeps the memory enabled during scan test to cover faults on the memory port
using multi-load patterns.

By default, static DFT signals are implemented using a special IJTAG TDR. When a
static DFT signal is specified, the tool automatically creates the signal on the TDR. If
the DFT signal has been added in the previous process, it will be automatically
reused.

3 Ashwani DFT
4. add_clocks: adds scan or non-scan clocks for scan operation; -period, defines
asynchronous clock; -reference, defines generated clock; -branch, defines clock
branch.

5. report_memory_instances: Reports all memories with editable instances.

6. create_dft_specification: creates a default DFT specification based on the

specified DFT requirements; the created DFT specification can be reported using
report_config_data.

sti_sib_list
specifies a list of IDs that are used to create the sib(id) wrapper in the ijtagNetwork
wrapper. If sib(sti) does not exist, it will be created, if it already exists, Sibs will be
inserted under it. If you want to add your own instrument to the network, this
instrument will be tested as normal functional logic during testing.

7. create_pattern_specification: Creates a default vector specification, which is a

configuration file. The process_patterns_specification command will create tests
based on the vector specification. The default vector specification can be edited
or configured to generate the required vector specification.

 replace
With this option, when creating a patternsSpecification with the same design_name
and design_id, and pattern_id already exists in memory, the error generated is
usually ignored.

8. process_pattern_specification: Process the vector specification. In this step, the

corresponding test vector will be generated according to the vector specification.

9. create_instance: instantiates an instance of a module's mod_spec within the

design module in the current design.

10. create_connections: connect pin, net, or port.

11. get_attribute_value_list: retrieve the attribute value of the specified design

object; -name, specify the attribute name, such as direction
(input/output/inout).

12. add_primary_inputs: Add PI (virtual input port) to the specified pins or nets.

13. add_input_constrains: constrain PI to the specified value; -C, fix the selected
input pin to a constant.

14. report_clocks: Report a list of user-defined or SDC-defined clocks.

4 Ashwani DFT
15. set_drc_handling: specifies how to handle design rule violations in the design; -
auto_fix; automatic repair. Currently only DFT_C9 has this feature.

16. check_design_rules: The tool switches from setup mode to analysis mode.

17. set_logfile_handling: Specifies that the tool will direct the transcription
information to a file for outputting the log file.

18. add_core_instances: Adds core instances to the design by using the current core
description in memory of the specified core instances in the design. (This is to
tell the tool about the core instances that have been inserted in the previous
DFT process).

19. set_module_matching_options: defines the acceptable prefixes and suffixes or

regular expressions to be used when matching the ICL module with the design
module in the ICL extraction; to do ICL extraction, it is necessary to match the
ICL module with the design module, and defining these prefixes, suffixes or
regular expressions is to facilitate matching the two.

20. dofile: run the commands in the specified file; execute a series of commands
contained in the file sequentially, rather than running each command separately.

21. add_dft_control_points: Instructs the tool to assume that the DFT control
signals exist during pre-DFT DRC (without actually inserting the control logic),
and the real control logic is inserted during process_dft_specification.

For a DFT control point of type "static_dft_control", when the specified object is a
port or an output pin, and when the specified object is an input or a net with a
functional source, it will be intercepted with the input of the MUX (which should be
connected to the 0 input of the MUX), and the 1 input will be connected to the static
DFT signal source position.

22. read_config_data: Reads the contents of a configuration data file or a string into
the Tessent Shell environment.

-from_string string

Specifies a string to parse.

23. foreach_in_collection: Iterates over each element in a collection.

You cannot use the foreach command provided by Tcl to iterate over a collection,
because foreach operates on a Tcl list, and a collection is not a Tcl list, but a pointer
to an array of C++-side execution data. You can use the get_name_list command to
convert a collection of objects into a Tcl list of object names, but this should be
avoided if the collection is very large or if the object names are not unique, for
example, a port object is a specified port name on a custom module, and specifying

5 Ashwani DFT
the port name alone does not identify which module it belongs to (the function is
the same as foreach).

24. get_config_elements: Returns a collection of configuration elements (elements

that configure how to test) or returns the count of configuration elements when
the -count option is used.

If no name_patterns are specified, all elements are returned, unless the -

in_wrappers option is specified, in which case only elements below the specified
wrapper are returned. When one or more name_patterns are used, only elements
whose names match at least one of the names are returned.

25. get_config_value: Returns the value associated with a configuration element

based on the specified options .

 config_object
A required value that specifies the name of a configuration element or a collection
containing a configuration element. When config_object is a collection, the -
in_wrapper and -partition options cannot be used because the object contains all the
information about the configuration elements. To use the -in_wrapper option, the
config_object value must be a name, and the name must be associated with the
specified wrapper element.

 id position | id_name | all

Optionally, specifies whether the requested data is the id of a wrapper or the id of a
repeatable attribute. With -id all, the command returns a well-formed Tcl list, unless
the configuration element has metadata and only has a single, non-repeatable id, in
which case the value is returned as a Tcl string.

 in_wrapper wrapper_object_spec
Optional, used to specify the parent wrapper where the configuration element is
located. wrapper_object_spec is the name of a wrapper or a collection containing a
wrapper element. The name in config_object is related to the specified parent
wrapper.

26. report_scan_cells: Displays a report of the scan cells located in the specified
scan chain.

The report_scan_cells command provides a report of the scan cells for the specified
scan chain, providing the following information for each scan cell:

 Chain cell index (cell ID), 0 is the scan cell closest to the scan-out pin.
 The scan chain where the scan cell is located.
 The scan group to which the scan cell belongs.
 The type of timing element, initial type, and latch trigger type during shift. The
latch trigger type can be LE, TE, AH, AL (?).
 Inverted data (INV) for each sequential element.

6 Ashwani DFT
 Gate index for each timing sequence.
 The shift clock name and inversion state at the clock input of each timing
element.
 The top-level library model cell name for each time series element.
 The instance name of each time series element.
 The library instance name.
 Cell input and output pins.

27. get_name_list: Returns the name of the specified object, or the name of a list of
names with simplified escaped identifiers.

28. analyze_graybox: identifies instances and nets to be included in the graybox list
by automatically setting their in_graybox property to true. Subsequently, the
"write_design -graybox" command writes out the graybox netlist for the marked
instances and nets.

Scan graybox analysis is only supported in -no_rtl context. It is executed in analysis

mode when external scan mode successfully completes DRC.

In the generated graybox netlist, all module names except the top-level modules are
made unique by adding a prefix. Use the -edited_module_prefix option of the
set_scan_insertion_options command to change the default prefix.

Modules with exclude_from_concatenated_netlist property true are not included in

the graybox netlist and their module names are not changed. This allows to still
combine real simulation models of hard macros, such as memories or PLL models,
during simulation in the scan graybox view. Child physical region modules are
uniqued and condensed into the scan graybox of the parent block if they have scan
mode parts. Child physical regions are recognized when the is_physical_module
property is set to true.

Scan graybox analysis performs identification by tracing back from all PO pins,
wrapper chain sequential cell input pins, and the specified preserve_instance
(instance that needs to be preserved in the graybox) input pins. Typically, the
backward tracing used by scan graybox analysis considers path sensitization based
on state stability values. These values ​ ​ are obtained by simulating the pin
constraints and test setup procedures provided for the external mode, and then a
pure structural tracing method is used when tracing back from the
preserve_instance input pins.

Additional gates are included in the scan graybox to minimize the difference in fault
coverage when using the graybox netlist and the full netlist in the fault list. If a gate
has multiple fanouts in the full netlist, it must also have at least two fanouts in the
graybox netlist. The tool includes additional gates in the graybox netlist to maintain
at least two fanouts for each gate initially identified by the feedback analysis to avoid
incorrect equivalent fault calculations between the two netlists.

7 Ashwani DFT
Exclude the scan-out pins from back-tracing to prevent the internal (core) logic of
the scan graybox from being flagged. To do this, use the set_attribute_value
command to set the scan-out pin's ignore_for_graybox attribute to true.

In scan graybox view, use the -preserve_instances option to include arbitrary

instances (instances of modules or library models). The tool will bypass graybox
analysis of the specified preserve module instances and automatically include all
required instances and nets of these instances (which will be preserved in the
graybox). This can overcome the limitations of traceback-based sensitization paths,
such as not allowing complex test_setup procedures to initialize non-scan cells in
clock paths and limiting timing depth.

A typical use of the -preserve_instances option is when the design contains a user-
defined clock control module, if it cannot be identified by scan graybox analysis then
the entire module may be treated as preserve_instance.

Currently, Tessent only supports Mux-DFF scan architecture, using the graybox
feature.

29. set_atpg_limits

Specify the limits of the ATPG process to cause the tool to terminate the ATPG
process.

The set_atpg_limits command determines the limits of the ATPG process operation.
When the tool is called, all command limits are off. If any limits are set, the tool
terminates the ATPG process when it reaches one of the limits during ATPG
execution. Any combination of the three parameters can be used. When one or
more limit types are specified, the tool terminates the ATPG process when the
specified limit conditions are reached.

Use the report_environment command to view the current settings of the

set_atpg_limits command.

 OFf
Turn off all restrictions.

 Cpu_seconds OFf | integer

Specifies the maximum number of CPU seconds that the ATPG process can run
before the tool terminates the process.

 Pattern_count [OFf | integer]

Specifies the maximum number of test patterns that the ATPG process can generate
before the tool terminates the process.

 Test_coverage [OFf | real | {real integer} …]

8 Ashwani DFT
Specifies the maximum percentage of test coveage that the ATPG process must
reach before the tool terminates the process.

9 Ashwani DFT