DFTug - Getting Started（下篇）

引言

本篇博客是对DFTug的第六章Getting started进行介绍。是对DFTug的一个总结，并加上了一个自己的理解，并希望对一些重要的的脚本进行背住，而不是记住一个大概，因为只有背住，完全写出来，才能给人感觉是非常专业的, 所以，今年目标是希望能塑造自己的专业性。

Performing Scan Extraction

Scan extraction 仅仅支持标准的scan design,并不支持extract scan structures for compressed scan designs。

步骤：
1、read_verilog my_design_dft.v
2、current_design my_design_dft

 set_scan_state scan_existing

3、定义基本的basic signal

dc_shell> set_dft_signal -view existing_dft -type ScanDataIn -port {TEST_SI1 TEST_SI2}
dc_shell> set_dft_signal -view existing_dft -type ScanDataOut -port {TEST_SO1 TEST_SO2}
dc_shell> set_scan_path chain1 -view existing_dft -scan_data_in TEST_SI1 -scan_data_out TEST_SO1
dc_shell> set_scan_path chain2 -view existing_dft -scan_data_in TEST_SI2 -scan_data_out TEST_SO2
dc_shell> create_test_protocol
dc_shell> dft_drc
dc_shell> report_scan_path -view existing_dft -chain all
dc_shell> report_scan_path -view existing_dft -cell all

值得注意的是，在执行scan extraction的时候，定义你的test structure必须要以DFT existing的认知（view）来定义。因为他们已经存在于设计中了，所有的连线已经connect好了。
那么现在再来说上述，做的这些工作有什么作用，也就是说为什么要设置这些，才能够实现extraction，不是已经都connect好了吗，工具为什么不能自动识别出来？
Scan extraction is the process of reading in an ASICII netlist that lacks test attributes。
如官方所说，Scanextraction是一个缺乏测试属性的netlist，因此我们需要去知道tool来识别到netlist中的scan chain structure，虽然，我们不会对这个netlist进行改动。只要能够正确的识别到了scan structure，你就可以write out test model and test protocol。
对于给定你的设计，你如果指定不同的scan chain会导致不同的测试协议。
所以，tool没法自动去识别到你的scan structure，你必须要去指导tool，如果你指导不正确，也会导致错误的测试协议，从而在某一时间，会输入不正确的测试数据，导致测试失败。

Hierarchical Scan Synthesis

Bottom-Up Hierarchical Scan Synthesis, 简称为HSS Flow, 与之对应的是Top down Flow，如下图是 Top-down 方法，这种方法，一旦有一点改动，将会导致整个chip层全部重新insertion。下图分别是TOP-down和Bottom-UP的示意图。


以下情况，官方建议使用HSS Flow
1、你的设计非常大
2、你想要重新定义一个block的DFT结构。
3、你想要创建的DFT-inserted block是可以在将来复用的。
此外注意以下，官方特别提醒的术语：DFT-inserted block称之为core，当前的level称之为core level。与之对应的是top level。（即使当top-level，放到更上一层又变为core level） 。在DFT的文献中，术语“block” 值得是层次化的设计模块，而术语“core"特指的是有CTL 模型信息的DFT-inserted blocks。

Introduction to Test Models

如下图所示
CTL - Core Test Language
我们说的test models通常就是指的CTL model。CTL models可以被下面三种格式读写：
ddc :包含了所有的信息，最全。
ctl ASCII格式的ctl语言，这个可以打开，不含网表约束物理scandef信息
ctlddc二进制的ctl，不含网表约束物理scandef信息
这里我打开过ctl的文件，其实和spf的文件写法类似。你可以看到一条chain上面连了具体的哪些cell，但是这些cell是没有顺序的。

下图是CTL的文件部分内容：

官方的建议是，希望用户在完成一个block之后，就写出所有格式的文件，以备后续使用。下面write_out出来的文件，有如下部分：

# write out core-level design information
write_test_model -formate ddc -output [format "%s%s" ./out/$design _scan.ctlddc]
write_test_model -formate ctl -output [format "%s%s" ./out/$design _scan.ctl]
write_scan_def -output [formate "%s%s" ./out/$design _scan.def]
write -hierarchy -formate ddc -output [formate "%s%s" ./out/$design _scan.ddc]
write -formate verilog -hierarchy -output [formate "%s%s" ./out/$design _scan.v]

Reading In and Using CTL Models at the TOP Level

在顶层，你需要读入CTL模型，然后读入他的netlist，工具会自动整合core-level的scan-structure 到top-level scan structure。

list_test_models
列出在内存中，具有CTL test models的design。

DFTug给出了一个简单的top-level的脚本，一个是ddc格式，一个是ctl格式。后续，我会再查一下lab中的脚本。
a Simple top-level scripts:

set link_library {* my_lib.db}
set target_library {my_lib.db}
read_ddc DDC/core.ddc ;#contains netlist and CTL model info
read_verilog GATES/IPBLK.vg ;#Verilog netlist for IP block

read_verilog RTL/top.v
current_design top
link
compile -scan
set_dft_signal -view existing_dft -type ScanClock -port clk -timing [list 45 55]
create_test_protocol
dft_drc
set_scan_configuration -chain_count 2
preview_dft
insert_dft
write -formate ddc -hierarchy -output DDC/top.ddc
write -formate verilog -hierarchy -output GATES/top.vg
write_test_protocol -output SPF/top.spf

Checking Connectivity to Cores at the Top Level

在core integration flow的时候，你必须要确保进入block的TestMode 和 Constant 信号能够match到block上用于shift chain所需要的信号，如果条件不满足，会被堵塞到。所以，个人感觉精髓在于本小节的标题，checking connectivity to cores at the top level.
你可以在DFT insertion之前，使用DRC来确认这些条件是否符合，在运行DRC之前，你需要设置以下的变量：
如下的该选项是默认关闭的。一旦开启后，DFT—DRC会自己运行内部仿真一个初始值，然后有一个期望值，看初始值与期望值是否匹配，从而验证connectivity是否正确。

dc_shell> set_app_var test_validate_test_model_connectivity true

一旦connectivity的mimatch被检测到了，scan segment就不会被stitch onto the scan chains。（可以再次结合之前的bottom-up的示意图进行理解）

Linking Test Models to Library Cells

有一些Cell是自己内建立（build-in）scan chains, 也就是说在top-level的时候需要连接到这些cell的CTL model 。
这时候也可以去link到，这里不介绍，暂时没遇到过这种情况。
如果你要
check library cells for CTL Model Information
使用
report_lib
如下，会发现这个cell具有ctl属性。

此外，Getting Start部分还简单介绍了DC Explorer，这里不再另外介绍。

本节需要记住的脚本

 set_scan_state scan_existing

# write out core-level design information
write_test_model -formate ddc -output [format "%s%s" ./out/$design _scan.ctlddc]
write_test_model -formate ctl -output [format "%s%s" ./out/$design _scan.ctl]
write_scan_def -output [formate "%s%s" ./out/$design _scan.def]
write -hierarchy -formate ddc -output [formate "%s%s" ./out/$design _scan.ddc]
write -formate verilog -hierarchy -output [formate "%s%s" ./out/$design _scan.v]

list_test_models

dc_shell> set_app_var test_validate_test_model_connectivity true

至此，DFTug 第六章Getting start的部分，总结全部结束。