DFT設計中的不同階段介紹

在DFT（Design for Test，可測試性設計）軟件開發中，針對設計檢測的完整流程通常包含Setup（設置）、Analysis（分析）、Insertion（插入）和Verification（驗證）四個核心階段。以下是各階段的詳細說明：

1. Setup（設置階段）

核心任務：為后續分析、插入和驗證搭建基礎環境，包括設計加載、庫文件讀取、約束條件定義等。
具體操作：

設計加載：讀取RTL代碼或門級網表（如Verilog文件），指定頂層設計（Top Design）。
庫文件讀取：導入標準單元庫、Tessent庫或Mentor ATPG庫，確保工具能識別設計中的元件。
約束條件定義：
- 設置時鐘頻率、掃描鏈配置（如掃描使能信號scan_en）。
- 定義電源域（Power Domain）和UPF（Unified Power Format）文件，管理多電壓域設計。
- 添加輸入約束（如固定掃描模式信號scan_mode為0或1）。
環境配置：設置設計層級（Chip/Sub-sys）、內存測試開關（-mem_bist on/off）等。

示例命令：

tcl

read_verilog top.v # 讀取頂層設計

set_current_design top # 指定當前設計

read_cell_library std_cell.lib # 讀取標準單元庫

add_clock CLK -period 10ns # 定義時鐘

add_input_constraints scan_en -C0 # 固定掃描使能信號為0

2. Analysis（分析階段）

核心任務：檢查設計是否符合DFT規則，識別潛在問題，并生成測試模式生成所需的模型。
具體操作：

設計規則檢查（DRC）：
- 驗證掃描鏈連接性、時鐘樹結構、復位信號分布等。
- 檢查不可控/不可觀測點（如組合邏輯環、鎖存器未掃描化）。
故障模型映射：將物理缺陷（如短路、斷路）映射為邏輯故障模型（如固定故障、轉換故障）。
測試點插入分析：確定需額外插入的測試點（Test Points）以提升故障覆蓋率。
生成TCD（Tessent Core Description）：為內存測試（MBIST）生成描述文件。

示例命令：

tcl

check_design_rules # 運行DRC檢查

report_drc_violations # 報告違規項

analyze_drc_violation -fix # 嘗試自動修復DRC問題

3. Insertion（插入階段）

核心任務：在設計中插入DFT邏輯（如掃描鏈、MBIST控制器），實現可測試性增強。
具體操作：

掃描鏈插入：將普通寄存器替換為掃描觸發器（Scan Flip-Flop），并連接成移位寄存器鏈。
MBIST控制器插入：為內存（RAM/ROM）添加自測試邏輯，生成測試模式并比較結果。
邊界掃描（JTAG）插入：在芯片引腳附近插入邊界掃描單元，支持板級測試。
時鐘/復位網絡優化：確保測試模式下時鐘樹穩定，復位信號可控。

示例命令：

tcl

insert_scan -chain_count 4 # 插入4條掃描鏈

insert_mbist -memory all # 為所有內存插入MBIST控制器

elaborate_design # 展開設計，應用DFT插入

4. Verification（驗證階段）

核心任務：驗證插入的DFT邏輯是否正確，確保測試模式能覆蓋目標故障，且不影響功能模式。
具體操作：

功能仿真驗證：
- 在測試模式（scan_mode=1）下運行仿真，檢查掃描鏈移位、MBIST操作是否正確。
- 在功能模式（scan_mode=0）下驗證設計功能未被破壞。
ATPG（Automatic Test Pattern Generation）：
- 生成測試向量（Patterns），目標故障覆蓋率通常需>95%。
- 優化向量以減少測試時間和成本（如合并相似向量）。
形式驗證（Formal Verification）：
- 對比插入DFT前后的網表，確保邏輯等價性。
時序收斂檢查：
- 與后端團隊協作，確保測試模式下時序滿足要求（如Shift/Capture時序）。

示例命令：

tcl

run_atpg -coverage 95 # 生成覆蓋率95%的測試向量

simulate -mode test # 運行測試模式仿真

verify_equivalence -golden original.v -revised dft_inserted.v # 形式驗證

階段間的關聯與迭代

Setup → Analysis：若DRC檢查失敗（如掃描鏈未連接），需返回Setup階段調整約束。
Insertion → Verification：若仿真發現MBIST控制器錯誤，需返回Insertion階段修復邏輯。
全流程迭代：復雜設計可能需多次循環各階段，直至滿足覆蓋率、時序和功能要求。

補充：量產支持階段（Post-Silicon）

雖非設計階段，但DFT工程師需參與：

ATE調試：將測試向量適配至自動測試設備（ATE），優化測試程序。
良率分析：通過測試結果定位制造缺陷（如金屬短路），反饋至工藝優化。
測試成本優化：減少冗余測試項（如CP階段僅保留高價值測試），降低量產成本。

通過以上階段，DFT軟件工程師能系統化地提升芯片可測試性，確保高質量芯片交付。

討論：Analysis階段的DRC檢測里面會有仿真檢查操作嗎

在DFT（Design for Test）軟件的Analysis階段中，DRC（Design Rule Check，設計規則檢查）的核心目的是靜態驗證設計是否符合DFT規則，通常不直接包含動態仿真檢查。但某些高級DRC工具或特定場景下，可能會結合輕量級仿真或形式化驗證來增強檢查能力。

1. 傳統DRC的本質：靜態檢查

DRC的主要任務是通過靜態分析（無需運行仿真）檢查設計中的結構性和邏輯性違規，例如：

掃描鏈相關問題：
- 掃描觸發器（Scan Flip-Flop）未正確連接。
- 掃描鏈存在斷鏈（Broken Chain）或環路（Loop）。
- 掃描使能信號（scan_en）未驅動所有掃描單元。
時鐘與復位問題：
- 測試模式下時鐘樹不穩定（如時鐘門控未正確控制）。
- 復位信號在測試模式下不可控（導致掃描鏈無法初始化）。
不可測試邏輯：
- 組合邏輯環（Combinational Loop）導致測試模式鎖死。
- 鎖存器（Latch）未被掃描化，形成不可觀測點。
內存測試問題：
- MBIST控制器未覆蓋所有內存實例。
- 內存地址/數據總線存在沖突。

靜態DRC的優勢：速度快、資源占用低，適合大規模設計早期快速定位問題。

2. 仿真檢查在DRC中的角色：有限但存在

雖然DRC以靜態檢查為主，但以下場景可能引入仿真或準仿真操作：

(1) 動態DRC（Dynamic DRC）

某些DFT工具（如Synopsys Tessent、Cadence JasperGold）提供動態DRC模式，通過：

模擬測試模式行為：在靜態檢查基礎上，模擬掃描鏈移位、MBIST操作等動態過程，檢測：
- 掃描鏈移位時數據沖突（如多驅動）。
- MBIST控制器與內存接口時序不匹配。
形式化驗證輔助：結合形式化方法（Formal Verification）證明測試邏輯在所有可能輸入下的正確性，例如：
- 驗證scan_en=1時，所有掃描觸發器確實進入移位模式。
- 驗證MBIST控制器在測試完成后能正確釋放內存控制權。

(2) 仿真驅動的DRC（Simulation-Guided DRC）

在復雜設計（如多時鐘域、低功耗設計）中，靜態DRC可能漏檢某些問題，此時會：

生成測試激勵：通過DFT工具生成簡化的測試向量（如掃描鏈移位序列），運行功能仿真。
監控關鍵信號：檢查仿真波形中是否存在DRC違規（如掃描鏈數據未正確移位）。

示例流程：

tcl

# 生成掃描鏈移位測試向量

generate_patterns -type scan_shift -count 100

# 運行仿真并檢查波形

simulate -patterns scan_shift.v -waveform scan_wave.vcd

# 分析波形中的違規（如數據沖突）

check_waveform -file scan_wave.vcd -rule "no_multi_drive"

(3) 特定工具的混合檢查

Synopsys Tessent：在check_drc命令中可通過-dynamic選項啟用動態檢查。
Cadence Modus：結合Incisive仿真器進行DRC+仿真聯動驗證。
Mentor FastScan：在ATPG前運行仿真驗證掃描鏈連接性。

3. 仿真檢查的局限性

即使引入仿真，DRC階段的仿真與后續Verification階段的完整仿真仍有區別：

特性	DRC中的仿真檢查	Verification階段的仿真
目的	快速定位結構性違規	驗證測試模式功能正確性
激勵復雜度	簡化激勵（如單周期掃描移位）	完整ATPG向量或隨機測試向量
覆蓋率	針對特定規則（如無多驅動）	故障覆蓋率（Fault Coverage）目標
運行時間	短（秒~分鐘級）	長（小時~天級，依賴向量規模）