2.tessent命令学习笔记

1.write_design：以verilog netlist的格式将当前设计写入指定文件中。

• -output_directory，指定输出目录。

不能使用write_design命令覆盖使用read_verilog命令读入的包含RTL模块的文件。

如果使用read_flat_model命令读取flat模型，则禁用write_design。

用法1——该用例只写出指定模块的接口定义。端口和参数定义被保存，但是模块中的其他的内容被删除。这对在memory中的模块定义没有影响，只影响被写出的文件的内容，如果不能指定- modules选项，当前设计的接口被写出。

用法2——这个用例写出在rtl context下创建的模块。创建的模块是使用create_module命令创建的。这些模块没有和它们相关的源文件，因此必须使用-output_file option为它们指定一个源文件，可以使用-created option将所有创建模块写入到单个文件中。但是如果使用不同的语言创建模块（VHDL或者Verilog），则必须写入到不同的文件中（创建模块会生成相应模块的RTL代码，然后可将RTL综合成网表，在-rtl和-no_rtl context下都会生成RTL代码）。

如果不能指定-modules或者-created options，工具做如下判断：“-modules [get_current_design] -hierarchical”。在这种情况下，如果当前设计是一个创建模块并且没有指定-output_file switch，工具将会产生一个错误。当指定-modules选项时，只能指定创建模块，否则，会生成错误。

用法3——这个用例在rtl context中写出读入模块（在rtl context下，创建模块的rtl代码要和其他的rtl代码一起编译，因为编译的影响，所以要写入到相同的目录下），因为RTL可以包含许多影响以后如何编译的指定，所以该工具在将RTL文件写入时保留它们的内容和顺序，因此，只能使用-output_directory或-original_location switch写出读入模块，rtl context中的读入模块不允许使用-output_file选项。

用法4——这个用例在no_rtl下写出read-in或者创建模块。在no_rtl context下，设计模块在删除所有编译器指定的情况下被写出，因此删除了对文件顺序的依赖，允许将任何模块连接到公共文件中，可以将读入模块和创建模块合并到同一个文件中。

用法5——这个用例写出了当前设计的graybox view到单个文件中，只有这些instances和nets的preserve_in_graybox属性为true被保存在这个文件中。所有其他的nets和instances被删除。可以使用set_attribute_value命令设置该属性，但是通常使用analyze_graybox命令添加该属性。

如果在patterns -scan context下发出”analyze_graybox -scan"命令时，“write_design -graybox"生成一个scan graybox，如果发出”analyze_graybox -ijtag”命令在patterns -ijtag context下，“write_design -graybox”生成IJTAG graybox（scan和IJTAG graybox有什么区别？）

用法6——这个用例创建一个dft_inserted_designs目录，其中包含使用自定义脚本创建的修改后的设计，如果elaborate ICL，则将其写入新的dft_inserted_designs目录，并更新tessetn_design_id属性以匹配用set_context命令定义的新design_idl。还复制了连接的PDL文件，并创建了.tcd文件和.tsdb_info文件。当想要自定义编辑脚本时使用该case。使用“write_design -tsdb”保存到TSDB中，可以使用read_design命令读回。当指定“-create_ijtag_graybox on"switch时，IJTAG graybox view也被创建。

用法7——这个用例在dft_inserted_designs目录中写出graybox view。当使用-graybox switch时，如果analyze_graybox命令被优先调用，则会产生error。graybox view可以被保存在先前使用"write_design -tsdb"或者”insert_test_logic -write_in_tsdb on"命令创建的dft_inserted_designs目录中。如果当前“set_context -design_identifier”值不能酦醅现存dft_inserted_designs目录，将会创建一个新的目录，保存相关文件：ICL、PDL、TCD和TSDB文件。

用法8—— -softlink_netlist用法只能在-no_rtl context下使用，在setup模式设计完成后即可使用，它为读入网表创建了一个dft_inserted_designs目录，这样就可以很容易地使用read_design或run_testbench_simulations命令加载该目录。当扫描插入没有在Tessent Shell中完成时，此选项通常用于为后综合网表创建
tsdb目录。当稻苗插入在tessent Shell中完成时，后综合TSDB view又“insert_test_logic-write_in_tsdb on“创建。还用于为post layout网表创建一个TSDB entry，例如read_design命令可以被使用在ATPG中载入该网表，当在wrapped core时创建graybox view，在run_testbench_simulations中自动载入设计。当指定”-create_ijtag_graybox on“switch时，自动创建IJTAG graybox view。

2.set_dft_specification_requirements：指定DRC检查的要求，包括DFT规格；

• -memory_test
  指定是否要检查和实施memory test；

• -memory_bisr_chains
  指定当前level是否要插入或连接MBIST chains。

• -memory_bisr_controller
  指定当前level是否要插入MBIST控制器。

• logic_test on|off
  指定logic test是否被设计规则检查并实施。

3.add_dft_signals：静态或动态DFT信号，被用来控制DFT logic的各种方面。有几个pre-registered（已经定义过的，有特殊的含义，可以使用add_dft_signal命令来添加，而不需要自定义）在多test modes期间可以用来控制电路。

使用report_dft_signal_names命令报道已经registered的DFT信号，使用register_static_dft_signal_names命令来register额外的信号。

静态DFT信号被分为以下几组：

• global_dft_control——包含用来控制全局resources的信号，例如，clocking和电源管理电路。
• logic_test_control——定义用来配置逻辑测试模式期间电路的各种方面的信号。
• scan_mode——定义在逻辑测试模式期间用来配置scan chains到各种扫描配置的信号，当使用scan_mode（edt_mode, multi_mode等）信号时，一次只能激活一个mode。

logic_test_control信号包括ltest_en，ltest_en是用来使电路进入逻辑测试模式，当执行任意逻辑测试时，该信号被系统的设置为1。int_ltest_en和ext_ltest_en被用来使电路进入internal或externa模式。一个scan mode包含wrapper和core的internal 扫描链可以在internal mode下操作，通过保持int_ltest_en为1。相同的扫描链配置可以通过使int_ltest_en为0来转换为unwrapped mode。

memory_bypass_en信号是logic_test_control信号的另一个例子。当设置为1时，工具在memory bypass逻辑使能的扫描模式下执行ATPG。这个配置被用来覆盖大多数的故障。当设置为0时，工具在scan test期间保持memory有效以使用multi-load patterns覆盖memory port的故障。

默认情况下，静态DFT信号使用特殊的IJTAG TDR来实现的，当指定一个静态DFT信号时，工具自动在TDR上创建信号，如果DFT信号已经在前面的过程中被添加，则会被自动的reused。

4.add_clocks：为了扫描操作添加扫描或非扫描时钟；-period， 定义了异步时钟；-reference，定义了generated clock；-branch，定义是时钟分支。

5.report_memory_instances：报道所有具有可编辑instances的memory。

6.creat_dft_specification；根据指定的DFT要求创建默认的DFT规范；可以使用report_config_data来报告创建的DFT规范。

• sti_sib_list
  指定一系列ID，被用来在ijtagNetwork wrapper中创建sib(id) wrapper。如果sib(sti)不存在，则会被创建，如果已经存在，则在它的下级插入Sibs。想要在network添加自己的instrument，这个instrument在测试期间作为正常的功能逻辑来测试。

7.create_pattern_specification：创建默认的向量规范，是一个配置文件，process_patterns_specification命令将根据向量规范来创建测试，可以编辑或配置默认的向量规范，以生成所需的向量规范。

• replace
  使用该options，当使用相同的design_name和design_id创建patternsSpecification，pattern_id已经在memory中存在时，生成的error通常被忽略。

8.process_pattern_specification：处理向量规范，在这一步会根据向量规范生成相应的测试向量。

9.create_instance：在当前设计中的设计模块内例化一个模块的mod_spec的instance。

10.create_connections：连接pin，net，或者port。

11.get_attribute_value_list：检索指定design对象的属性值；-name，指定属性名，例如direction（input/output/inout）。

12.add_primary_inputs：将PI（虚拟的输入port）添加到指定的pins或者nets。

13.add_input_constrains：约束PI为指定值；-C，给所选择的input pin固定为常数14.report_clocks：报告用户定义或SDC定义的时钟列表。

15.set_drc_handling：指定如何处理design的设计规则违例；-auto_fix；自动修复，目前只有DFT_C9有该feature。

16.check_design_rules：工具从setup模式转换为analysis模式。

17.set_logfile_handling：指定工具将誊写信息定向到文件中，用于输出log文件。

18.add_core_instances：通过使用设计中指定core instances在memory中的当前core描述来对设计添加core instance。（就是在告诉工具先前的dft过程中已经插入的core instance的信息）。

19.set_module_matching_options：定义将ICL模块与ICL提取中的设计模块匹配时要使用的可接受前缀和后缀或规律的表达式；做ICL提取，需要把ICL模块和design模块匹配起来，而定义这些前缀、后缀或规律的表达式就是为了方便将二者匹配起来。

20.dofile：run指定文件中的命令；顺序执行文件中包含的一系列命令，而不是i分开run每一条命令。

21.add_dft_control_points：指示工具假设在pre-DFT DRC期间（未实际插入控制逻辑）DFT 控制信号存在，真正的控制逻辑在process_dft_specification期间插入。

对于“static_dft_control”类型的DFT 控制点，当指定对象是一个port或一个output pin时，以及当指定对象是一个input或一个具有功能来源的net时，会被用MUX的输入intercepted（应该是连接到MUX的0输入端），1 input被连接到静态DFT信号源位置。

22.read_config_data：读取配置数据文件的内容或一个字符串到Tessent Shell环境中。

-from_string string

指定一个要解析的字符串。

23.foreach_in_collection：迭代集合中的每个元素。

不能使用Tcl提供的foreach命令来迭代集合，因为foreach是在Tcl列表上操作，集合不是Tcl列表，而是C++端执行数据数组的指针。可以使用get_name_list命令将对象的集合转换为对象名字的Tcl列表，但是如果集合非常大或者如果对象名字不唯一，应该避免这样做，例如一个端口对象在一个自定模块上是一个指定端口名，仅指定端口的名称并不标识它属于那个模块（功能与foreach相同）。

24.get_config_elements：返回configuration elements（配置如何进行测试的元素）的集合或者当使用-count option时返回configuration elements的count。

如果没有指定name_patterns，则返回所有元素，除非指定了-in_wrappers option，在这种情况下，只返回指定wrapper以下的元素，当使用一个或多个name_pattern时，只返回名称与至少一个名称匹配的元素。

25.get_config_value：基于指定的选项返回与configuration element有关的值。

• config_object

一个必须的值，指定configuration element的名称或者包括一个configuration element的集合。当config_object是一个集合，不能使用-in_wrapper和-partition options，因为对象包括了configuration elements的所有信息。为了使用-in_wrapper option，config_object值必须是一个名称，并且名称必须与指定的wrapper element有关。

• id position | id_name | all

可选，指定请求的数据是wrapper的id或可重复属性的id。使用-id all时，该命令将返回一个格式良好的Tcl列表，除非configuration element有metadata，并且只有一个不可重复的id，在这种情况下，value作为一个Tcl字符串被返回。

• in_wrapper wrapper_object_spec

可选，被用来指定configuration element所在的parent wrapper，wrapper_object_spec是wrapper或包含一个wrapper element的集合的名字，config_object中的名称与指定的parent wrapper有关。

26.report_scan_cells：显示位于指定扫描链中的scan cells的报告。

report_scan_cells命令提供指定扫描链的scan cells的报告，为每个scan cell提供以下信息：

• Chain cell索引（cell ID），0是最接近scan-out pin的scan cell。
• scan cell所在的scan chain。
• scan cell所在的scan group。
• 时序元素的类型，初始类型，在移位期间的latch触发类型。latch触发类型可以是LE、TE、AH、AL（？）。
• 每个时序元素的反转数据（INV）。
• 每个时序的门索引。
• 每个时序元素的时钟输入处的shift clock名称和反转状态。
• 每个时序元素的top-level库模型cell名称。
• 每个时序元素的instance名称。
• 库instance名称。
• Cell输入和输入pins。

27.get_name_list：返回指定对象的名字，或者带有简化转义标识符的名称列表的名称。

28.analyze_graybox：通过自动将instances和nets的in_graybox属性设置为true来标识要包含在graybox列表中的instances和nets，随后，“write_design -graybox”命令为标记的instances和nets写出graybox网表。

scan graybox analysis只在-no_rtl context下被支持。当external scan mode成功完成DRC时在analysis模式下执行。

在生成的graybox网表中，除了top-level模块，所有的模块名通过添加前缀来唯一化，使用使用set_scan_insertion_options命令的-edited_module_prefix option来改变默认的前缀。

具有exclude_from_concatenated_netlist属性为true的模块不会被包括在graybox网表中，并且它们的模块名不会被改变。这样仍然可以在scan graybox view的仿真期间结合hard macros的真实的仿真模型，例如memories或者PLL模型。Child physical region模块被唯一化，并精简进parent block的scan graybox中，如果它们具有scan mode的部分。当is_physical_module属性被设置为true时，Child physical region将被识别。

scan graybox分析通过从所有的PO pins、wrapper chain时序单元输入pins、以及指定的preserve_instance（需要保留在graybox中的instance）输入pins，追溯执行识别。通常，scan graybox分析所使用的反向追溯基于状态稳定值考虑路径敏化。这些值是通过仿真为外部模式提供的引脚约束和测试设置程序来获得的，然后当从preserve_instance输入引脚向后追溯时，使用了纯结构追溯方法。

在scan graybox中包含额外的门，以最小化故障列表中使用graybox网表和使用完整网表时故障覆盖率的差异。如果一个门在完整网表中有多个扇出，那么它在graybox网表中也必须至少有两个扇出，该工具在graybox网表中包含了额外的门，以便在反馈分析最初确定的每个门保持至少两个扇出，这样时为了避免两个网表之间的等效故障计算不正确。

从反向追溯中排除scan-out引脚以防止标记scan graybox的internal（core）logic，为此，使用set_attribute_value命令来设置scan-out引脚的ignore_for_graybox属性为true。

在scan graybox view下，使用-preserve_instances option来包括任意instances（模块的例化或者库模型的例化），工具会bypass指定的preserve module instances的graybox分析，自动包括这些instances的所欲instance和nets（对这些instance会保留在graybox中），这可以刻骨基于回溯的敏化路径带来的限制，例如不允许复杂的test_setup过程在时钟路径中初始化non-scan cells，并限制时序深度。

一个典型的-preserve_instances option用法是当设计包含user-defined时钟控制模块时，如果不能被scan graybox analysis识别则可能只当整个模块为preserve_instance。

当前，Tessent only支持Mux-DFF scan architecture，使用graybox功能。

29.set_atpg_limits

指定ATPG process的限制，使工具终止ATPG process。

set_atpg_limits命令决定ATPG process操作的限制，调用工具时，所有的命令限制为off，如果设置任意限制，在ATPG期间，执行工具到达其中一个限制，工具终止ATPG process。可以使用三个参数的任意组合，当指定一个或多个限制类型时，当到达指定的限制条件时工具终止ATPG process。

使用report_environment命令查看当前set_atpg_limits命令的当前设置。

• OFf

关闭所有的限制。

• Cpu_seconds OFf | integer

指定工具终止process之前，ATPG process小号的最大数量的CPU seconds。

• Pattern_count [OFf | integer]

指定工具终止process之前，ATPG process能够生成的test patterns的最大数量。

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

指定工具终止process之前，ATPG process需要达到的test coveage的最大百分比。