文章目錄

• 引言
• Performing Scan Extraction
• Hierarchical Scan Synthesis
• Introduction to Test Models
• Reading In and Using CTL Models at the TOP Level
• Checking Connectivity to Cores at the Top Level
• Linking Test Models to Library Cells
• 本節需要記住的腳本

引言

本篇博客是對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 blockread_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的部分，總結全部結束。

總結

以上是生活随笔為你收集整理的DFTug - Getting Started（下篇）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。