可測試性設計 （DFT） 在市場上所有的電子設計自動化 （EDA） 工具中是最不被重視的，縱然在設計階段提高芯片的可測試性將會大幅縮減高昂的測試成本，也是如此。最近的分析數據表明，在制造完成后測試芯片是否存在制造缺陷的成本已增至占制造成本的 40%，這已達到警戒水平。
　　DFT 可以降低通過問題器件的風險，如果最終在實際應用中才發現器件有缺陷，所產生的成本將遠遠高于在制造階段發現的成本。它還能避免剔除無缺陷器件，從而提高良率。插入 DFT 亦能縮短與測試開發相關的時間，并減少測試裝配好的芯片所需的時間。
　　DFT 是電子行業的警鐘，它采用自動測試模式生成器 （ATPG） 和存儲內置自測試 （MBIST），是在芯片上插入測試結構（例如掃描鏈、MBIST 結構或壓縮/解壓邏輯）。掃描鏈通過串行移位寄存器增加了可控性和可觀察性。借助掃描鏈，測試電路的工作得到簡化和縮減。使用 ATPG 工具自動生成測試模式能夠減少耗時繁瑣的測試向量創建任務。
　　當設計經過功能驗證后，片上測試架構（或掃描鏈）會在門級的基礎上被插入，執行此操作時必須小心謹慎，因為這可能會影響芯片的功能正確性。設計更改需要進行門級驗證，以確保設計完整性未受影響。測試將由測試模式的長序列執行，這是一項計算密集型任務，比寄存器傳輸級 （RTL） 驗證繁瑣得多。
　　值得一提的是，從設計角度而言，創建并插入 DFT 結構是一項十分簡單的工作。不過，從密度和規模的層面來看，設計規模會增加，同時測試設計所需的測試模式數量也會使設計規模大大增加。
　　DFT 驗證
　　當設計尺寸達到數億門時，基于軟件仿真器的驗證對于門級檢查而言速度過于緩慢。DFT 方法只會讓事情變得更糟。如果這些負擔還能夠應付，那么優先使用軟件仿真陣列來推進流片有助于設計工程師的工作，但會為測試工程師帶來阻礙。芯片通常只進行極少的 DFT 驗證就進行流片，而在流片后才執行徹底的 DFT 測試，這時要修復設計缺陷為時已晚。
　　DFT 驗證具有多種形式，包括需要驗證的自定義初始化模式。它可以是由自動測試模式生成器工具插入的片上時鐘控制器，這需要在模式執行期間進行動態驗證；也可以是為 MBIST 添加的邏輯，這通常需要對測試模式的相關邏輯進行功能驗證。SoC 可能包括一個自定義初始化模式，此模式能夠配置測試并完成從功能模式到測試模式的轉換。其他測試模式可能會采用低功耗技術，測試期間，芯片的一部分將進入低功耗模式，這就需要在適當情況下的有效測試結構。
　　使用 DFT App 進行硬件加速仿真
　　硬件加速能夠縮短執行徹底 DFT 驗證所需的仿真周期。同時還能驗證各種規模和復雜性的芯片的功能。
　　30 年來，人們一直使用硬件加速仿真部署可重復編程的硬件來增加驗證周期，而新的部署模式使這項技術成為更可行的驗證工具，同時也為“App”的方法奠定基礎。對于仍受困于基于軟件仿真器進行驗證的芯片設計團隊而言，近期推出的一些硬件加速仿真應用程序無疑是個好消息。DFT App 能夠加速需要進行全面門級仿真的芯片設計進程。借助自動生成的模式，設計團隊能夠縮短整個模式開發周期。
　　這類硬件加速仿真的可擴展硬件和編譯器能夠對嵌入了掃描和其他測試結構的大型門級設計進行測試模式驗證。它具有出色性能，能夠運行更多仿真周期，加快 DFT 分析。DFT App 支持行業標準 STIL 格式文件，可以與其他工具協同工作，STIL 文件可用于生產測試程序以便在制造過程中發現受損芯片。
　　用于硬件加速仿真的 DFT App 改變了硬件加速器在開發階段的編譯流程和運行時間。這將為編譯流程和運行時間帶來重大變化。具有掃描和 MBIST 結構的門級設計被載入硬件加速仿真的編譯器。編譯器創建了用于讀取Stil文件中測試向量的測試結構，然后將這些向量應用到可綜合的待測器件 （DUT） 以及進行輸出比較。編譯器將用戶網表重新編譯并合成到一個能夠兼容硬件加速仿真的結構化描述中。編譯器創建了用于讀取Stil文件中測試向量的測試結構，然后將這些測試向量用到可綜合的待測設計上，再將網表重新編譯并合成到一個能夠兼容硬件加速仿真的結構化描述中。測試控制架構還包括比較輸出的機制。