Home
Explore Uedu
Student Console
Register as Member/Login
(2) In future presentations of the research findings, in addition to the course project website and public presentations, your real name and personal information will not appear in this research report. If you are interested in the research results, we can provide you with an executive summary after the study is completed.
問卷中心
Teacher Console
Course Setup
Support & Messages
Uptime Data

UeduGPTs

--

Jupyters

0

Local AI

--

CISOSE26 本地 AI UG26
政治大學 AQI 19 29°C

AI Reply Desktop Notifications

Show a desktop notification when the AI TA finishes replying

Chat Message Notifications

Notify me when classmates post messages in the forum

Sound notification

Play an alert sound whenever there is a new notification

軟體與 EDA
軟體與 EDA

驗證與可測試性設計(DFT)

晶片做好之前要先「驗對」,做好之後還要能「測得出壞」。

驗證與可測試性設計(DFT) 概念示意插圖
概念示意插圖(AI 生成,僅供輔助理解,非精確技術圖示)
研究所  ·  約 18 分鐘  ·  驗證DFT測試

兩個容易混淆的問題:驗對 vs. 測壞

數位設計流程裡有兩個名字相近、目的完全不同的環節,常被混為一談:

  • 驗證(Verification):在晶片製造之前,確認設計的「行為」符合規格——RTL 描述的邏輯是不是真的做對了該做的事。這是「驗對」。
  • 可測試性設計(DFT, Design for Test):在晶片製造之後,能不能用自動測試機(ATE)有效率地「測得出」哪幾顆晶片有製造缺陷。這是「測得出壞」。

前者對抗的是設計錯誤(design bug),後者對抗的是製造缺陷(manufacturing defect)。一顆驗證完美的設計,若沒有 DFT,量產後仍無法經濟地篩出壞品。

功能驗證:狀態空間爆炸的戰爭

為何驗證比設計還難

一個含 n 個正反器的設計,其狀態空間高達 2^n。即使 n=100,狀態數就遠超宇宙原子數,窮舉不可能。驗證工程師常占 IC 團隊人力的 60~70%,因為「設計做什麼」相對明確,「證明它在所有情況都對」卻是組合爆炸。

模擬式驗證與覆蓋率

主流仍是模擬式驗證(simulation-based),輔以結構化方法論:

  • 約束隨機驗證(CRV, Constrained Random Verification):用 SystemVerilog 在合法輸入空間隨機產生大量激勵。
  • UVM(Universal Verification Methodology):標準化 testbench 架構(driver/monitor/scoreboard),可重用。
  • 覆蓋率驅動(coverage-driven):用程式碼覆蓋率(行/分支/FSM 狀態轉移)與功能覆蓋率(covergroup 描述的場景)量化「驗了多少」。目標通常要求功能覆蓋率達 95~100%

形式驗證

形式驗證(formal verification)用數學證明取代模擬:

  • 等價性檢查(equivalence checking):證明 RTL 與合成後網表、或網表與版圖在邏輯上完全等價,常用 BDD(二元決策圖)SAT solver
  • 屬性檢查(property/model checking):用 SVA(SystemVerilog Assertions)描述「永遠不會發生 X」,工具窮舉證明或給反例。

形式方法能達 100% 完備,但受狀態爆炸限制,只適用於控制邏輯、協定、仲裁器等規模可控的區塊。

DFT:故障模型與可控可觀測性

為什麼需要 DFT

製造缺陷(微塵、斷線、短路)會讓某個內部節點卡在 0 或 1。問題是:晶片內部數百萬個節點,從外部接腳根本摸不到也看不到——這就是可控性(controllability)可觀測性(observability)不足。DFT 的本質,是在設計裡加電路讓內部變得「可控可觀測」。

故障模型

測試針對抽象的故障模型而非真實物理缺陷:

  • stuck-at fault(固定故障):節點固定在 0(stuck-at-0)或 1(stuck-at-1),最經典。
  • transition / at-speed fault(延遲故障):邏輯對但太慢,需全速測試抓出。
  • bridging fault(橋接故障):兩節點短路。

掃描鏈與 ATPG

掃描鏈

掃描設計(scan design)把設計中的正反器換成 scan flip-flop,測試模式下串成一條或多條掃描鏈(scan chain)

# 正常模式:FF 各自接原本邏輯
# 測試模式(scan_enable=1):所有 FF 串成移位暫存器
#   1. shift-in:  從 scan_in 把測試向量逐 bit 移入所有 FF
#   2. capture:   切回功能模式 1 個週期,捕捉組合邏輯回應
#   3. shift-out: 把捕捉值逐 bit 移出 scan_out,與預期比對

如此一來,每個 FF 都同時變得可控(可任意設值)可觀測(可讀出),把困難的時序電路測試轉化為較簡單的組合電路測試。

ATPG 與覆蓋率

ATPG(Automatic Test Pattern Generation,自動測試向量生成)演算法(如 D-algorithm、PODEM、FAN)自動算出能偵測每個故障的輸入向量。核心是故障敏化(sensitize)路徑傳播(propagate)

  • 故障覆蓋率(fault coverage):被偵測故障 / 總故障數,量產品質要求通常 > 99%,缺陷率(DPPM, defective parts per million)才能壓到個位數百萬分比。
  • 一顆複雜 SoC 的 stuck-at 測試向量可達數萬到數十萬個 pattern

測試成本與壓縮

測試時間直接等於 ATE 機台佔用成本,向量越多越貴。測試壓縮(test compression)技術(如 EDT、掃描鏈解壓縮/壓縮)在晶片內加 decompressor 與 compactor,可把測試資料量與測試時間壓縮 10~100 倍,是控制量產測試成本的關鍵。

技術 解決問題 量化指標
掃描鏈 內部不可控/不可觀測 覆蓋幾乎全部 FF
ATPG 自動生成測試向量 故障覆蓋率 > 99%
測試壓縮 向量太多、測試太貴 壓縮比 10~100×
BIST 外部測試能力不足 記憶體/邏輯自測

BIST 與其他 DFT 結構

  • MBIST(Memory BIST):記憶體陣列規則但密度極高,用內建電路跑 March 演算法自我測試與修復(redundancy repair)
  • LBIST(Logic BIST):以 LFSR 產生偽隨機向量、MISR 壓縮回應成 signature,用於高安全/車用晶片的開機自測。
  • Boundary scan(JTAG, IEEE 1149.1):測 PCB 上晶片之間的連線。

取捨、失效模式與前沿

DFT 不是免費的:掃描鏈增加面積(2~5% 額外邏輯)功耗(測試時翻轉率遠高於功能模式,可能造成測試中 IR drop 過大反而誤判),且 scan 結構可能成為安全側通道。失效模式包括:覆蓋率不足讓壞品漏網、測試功耗過高造成 over-test、以及 at-speed 測試對延遲故障靈敏度不足。

前沿方向:3D IC 與 chiplet 的測試(die 堆疊後內部更難觸及,需 die-to-die 測試與 KGD, Known Good Die 篩選)、功能安全(ISO 26262)要求的線上自測、以及 AI/ML 用於缺陷診斷與良率學習。隨著晶片進入異質整合時代,「測得出壞」的難度與成本只會持續上升。

延伸閱讀:〈從 RTL 到 GDSII:數位設計流程〉、〈晶片測試:CP、FT 與良率的最後防線〉、〈佈局與繞線(P&R)〉。

接著問 AI 助教

點一下複製提問,到 ClassroomGPT、優學伴(AIDA)或你的 UeduGPTs 頻道貼上,AI 會引用本專區內容回答。

AI 共讀助教正在陪你讀:驗證與可測試性設計(DFT)
嗨!我是這篇文章的共讀助教,只根據〈驗證與可測試性設計(DFT)〉的內容回答。可以問我「解釋某段」「舉個例子」「出題考我」,或反白文中段落後點下方「解釋選取段落」。