可測試性設計(DFT)存在於SoC設計的起點、終點及整個設計流程的所有環節

全新嵌入式DFT解決方案可提供準確的早期驗證以及和下游的合成工作無縫交遞

英文原文：DFT For SoCs Is Last, First, And Everywhere In Between

2021年 1月12日於《Semiconductor Engineering》刊登

過去，IC 測試是設計流程中的最後一項工作。首先要設計出晶片，然後編寫功能性測試程式去驗證製造出來的晶片運作狀況是否如預期。功能測試程式中某些部分經常會被重複用於製造測試，以確定晶片的設計是否有缺陷，因此不需花太多心力。

時至今日，一切有所不同。雖然現今依然有驗證晶片功能性和篩檢晶片缺陷的必要，但實現此目標的方法更加複雜。設計複雜度顯著增加的同時，測試的方法也越趨成熟。可測試性設計(DFT)現在已是一門有明確定義的學問，可用以處理複雜 SoC 的可測試性。在早期設計的 RTL 階段嵌入 DFT 可實現早期驗證，但這種方法對於功耗、性能和面積的優化並不十分有效。若是在設計後期嵌入 DFT，則能達到較高的PPA優化，但會使驗證的步驟延後而導致進度延遲。這些交互影響因素顯示出 DFT 的「陰」與「陽」。讓我們來檢視這兩股相反的力量，瞭解為什麼在設計最初、最終以及其間的所有環節都必須考慮進行 SoC DFT。

陰 – DFT 的功能性驗證

這是個複雜度管理的情況。大型的設計，就需要複雜且類似的大型測試策略。DFT 複雜度持續增加的範例包括：

核心系統與子系統的結構性測試
掃描壓縮
邏輯內建自我測試 (LBIST)
記憶體內建自我測試 (MBIST)
IEEE 1149.1協議下的邊界掃描，以及包含數據、控制訊號、和16個狀態的Tap控制器
IEEE 1500協議的核心包覆(core wrapper)
基於 EEE 1687 的存取網絡 (即 iJTAG)
片上(on-chip)時脈控制器

為了實現早期驗證，可以在設計的 RTL 階段實施 DFT，進而完成早期驗證，並更加容易實現DFT交互邏輯的偵錯。這類的驗證和偵錯通常是以 Verilog代碼進行模擬，往往會比閘級(gate-level)電路仿真更有效率。雖然這個方法可顯著提升生產力，但由於 RTL DFT 中並不包含物理性的合成指南，所以它仍然不是最佳的 PPA。

陽 – 最佳 PPA

正如設計技術不斷擴展以支持各式各樣的 DFT 方案，Design Compiler NXT 和 Fusion Compiler 等合成工具也為了支援這些技術的物理性嵌入而有所擴展。這種 DFT實作方法可輕鬆應用在多種設計中，並利用合成技術確保最佳的 PPA。

問題在於，直到能提供含有嵌入DFT結構的閘級電路網表(gate-level netlist)之前，這個方法可能會延後驗證的步驟，所以會降低設計項目的速度。下圖說明這項挑戰。

答案 – 驗證左移(shift-left)

要處理 DFT 的陰/陽問題，就需要全新的嵌入DFT與驗證方法，一種能在 RTL 對主要 DFT 元件進行準確且早期的驗證，並且能無縫交遞到下游的合成和底層底层DFT 實作。此方法可以實現全設計的早期驗證，讓下游的 DFT 工作，包括：掃描鏈重新排序、核心包覆、壓縮結構在物理層的擁塞優化、測試點等，能與完整流程無縫融合。此方法稱為左移，如下圖所示。