前言——晶片由MPW試産進入量産階段的時候，DFT可測性設計是前後端設計者都無法繞過的必修課。DFT的設計，既屬于晶片功能設計的範疇，又對後端的設計流程有顯性的影響。
前端設計者需要了解：
- DFT可測性設計都做些什麼？
- 是如何實作存儲器、IO和邏輯的測試的？
- DFT系統是如何搭建的？
- DFT的IP如何與我的RTL設計配合？
後端設計者則需要了解：
- DFT的IP對面積和時序有怎樣的影響？
- DFT mode的時鐘樹如何搭建，時序如何收斂？
這個系列旨在：
- 介紹DFT方面的基礎知識和重要概念，幫助建立對DFT測試的初步印象；
- 主要面向前端設計介紹DFT對RTL設計的前置需求，讓前端設計者更容易寫出一步到位的DFT ready的RTL代碼，減少因DFT測試需求不能滿足而重複疊代修改的工作量；
MBIST存儲器内建自測試
1. MBIST的含義與目的
MBIST是Memory Build-In-Self Test的簡稱，意為存儲器内建自測試。“内建”的含義是指針對存儲器的測試向量不是由外部測試機台（ATE：Auto-Test-Equipment）生成，而是由内建的存儲器測試邏輯自動産生，并進行結果的對比。MBIST測試中，隻需要從機台通過JTAG标準接口下達測試的指令，就可以從TDO接口擷取測試結果。
為什麼要進行内建自測試呢？原因主要有：
- a）存儲器在很小的面積内內建了很多存儲單元，對ATE的測試成本過高，不适用于從外部灌入針對存儲器的測試向量；
- b）Memory測試的特殊性——需要測試的單元很多，但分布規整，可利用算法批量産生測試向量；
- c）線上測試的需求——汽車電子的安全性，需求在晶片運作時仍保持線上測試（即不依賴測試機台，可內建于闆級、晶片内或由軟體調用，來實作随時随需的測試），随時排除可能出現的故障。
是以我們可總結出内建自測試的優勢：因為測試向量由内部邏輯生成，相應子產品可同被測試的存儲器一同工作在内部的高速功能時鐘下，而無需由機台慢速時鐘移入測試向量，可節省大量的測試時間；另一方面，對比驗證也同樣交給内部邏輯自行完成，測試機台隻需要收集測試結果，也可大幅減少測試時間。代價是内建自測試的邏輯對面積的占用很高，也不具備自由配置或更改測試向量的條件。
MBIST測試的架構由測試控制、硬體向量生成、比較器組成：
當測試控制子產品接收到開始測試的指令後，首先會切換存儲器的輸入輸出到測試模式，同時啟動硬體向量生成子產品開始産生和給出測試激勵，同時計算存儲器的輸出期待值。存儲器接收到測試向量之後，會間隔執行寫/讀/使能的操作，周遊測試所有位址下每個bit單元的寫/讀功能。最後，通過Q端輸出的讀取值，會與測試控制子產品計算的期待值進行比較，是否正确的結果回報到測試控制子產品。
2. TESSENT MBIST邏輯的結構和原理介紹
- TAP：Test Access Port
- BAP：BIST Access Port
- SIB：Segment Insertion Bit
- TMB：Tessent Memory BIST Controller
Tessent MBIST結構基于IEEE 1687标準（TAP 仍基于IEEE 1149.1）。TAP的功能是由JTAG五組端口擷取外部給予的測試指令，并轉換到IJTAG掃描鍊上，并移位到其後的子產品内；SIB可以開啟或關閉其下對應的IJTAG掃描鍊，掃描鍊的開啟意味着該部分Memory進入測試狀态；BAP起到SIB下發到MBIST Controller的接口作用；MBIST Controller内含對Memory測試控制的狀态機邏輯和生成向量的邏輯；Memory Interface包含了上節所述的選擇輸入輸出的MUX；而結果比較電路，包括ROM的期待值，則可以位于MBIST Controller中（面積更優，時序和擁塞更差）或位于Memory Interface中（效果反之）；比較結果會彙總為測試結果，由IJTAG掃描鍊，經過TMB、BAP、SIB、TAP移出到TDO端口。
MBIST測試中的關鍵訓示信号有RUN、GO、DONE信号，由MBIST Controller結合狀态機和比較器的比較結果來給出。RUN信号訓示目前Controller以及下屬的Memory進入測試狀态（MBIST Mode）；GO=1信号訓示開始向下屬的Memory輸出測試向量，測試開始，=0訓示測試有比較器報出Fail；DONE=1信号訓示MBIST測試已結束。GO和DONE信号結合起來，可判定出目前Controller下屬Memory的測試情況：
- GO一直未拉高或DONE一直未拉高：Controller執行有誤；
- GO拉高後，DONE尚未拉高：Memory測試執行中，尚未出錯；
- GO拉高後在DONE拉高前回落：有Memory測試失敗；
- GO拉高後，DONE拉高：Memory測試正确通過。
GO信号根據使用者需求不同，可以有以下輸出方案：
- 全部測試信号彙總為一個GO信号移出，隻訓示設計的MBIST測試結果；
- 每個Memory對應一個GO信号移出，可具體訓示哪一塊Memory有故障；
- 每個Comparator對應一個GO信号移出，可細化到Memory的哪一位輸出有故障；
- 若要具體到哪一位BitCell有故障，預設不能實作，需要調用Tessent的Diagnosis Feature。
3. RTL設計滿足MBIST內建的前置需求
如上所示是Tessent MBIST邏輯的時鐘和複位信号示意圖。複位信号由TRST、TAP、SIB、BAP逐級提供給TMB和Memory Interface，隻有在需要的時候，下一級才會由上一級拿到複位信号開始工作。時鐘信号方面，TAP、SIB、BAP三者都在IJTAG掃描鍊上，是以工作在機台的慢速時鐘（TCK）之下；TMB、Memory Interface則直接挂在待測試Memory的時鐘源（FuncClk）之下，向量的産生和測試過程都是工作在高速時鐘下，以節省測試時間和便于對memory進行全速測試。
是以我們可以很清楚地了解到，MBIST邏輯能正常工作，不依賴系統原有的複位，但需要保證Memory的時鐘源準确有效。時鐘網絡中的時鐘門控（Clock Gate）、時鐘選擇（Clock Mux）、時鐘分頻（Clock Divider）和晶振時鐘（PLL），在功能模式下可能是正确有效的；但若未在代碼設計時考慮到Memory在測試模式下的時鐘路徑，很有可能發現在電路切換到MBIST模式下之後，由于信号配置出錯，或部分功能邏輯不能工作，而導緻時鐘路徑不通，或時鐘頻率不比對全速測試的要求。其結果是前端設計人員不得不返工修改代碼，造成項目不必要的疊代。抑或由DFT工程師自行對電路結構進行ECO解決，但如此做的問題是代碼難以達到完備标準，ECO修改工作需反複占用DFT工程師的工作時間，在每次項目更新、不同DFT工程師（如客戶方）、和新老項目複用時都會造成重複勞動。
另外，雖然MBIST邏輯不依賴系統原有複位，但時鐘相關的邏輯，例如我們CPU中的時鐘分頻電路和SOC平台中的時鐘管理子產品，仍需要正常工作來提供正确的時鐘。是以，時鐘相關邏輯需要拿到一個與功能模式相同的複位上升沿信号。而其它無關的邏輯，在MBIST測試中需要保證其複位一直為低，保證無關邏輯在測試期間不會由于信号翻轉而産生過高的功耗。如上圖SOC平台中的複位處理方法。
以下我們将以幾個例子來說明測試模式下時鐘路徑上可能會遇到的問題：
- 案例1——時鐘門控作為分頻器
此案例中，時鐘門控單元扮演了一個時鐘分頻器的角色。在功能模式下，時鐘門控的使能信号E是通過CPU指令調配而産生的一個類似1G時鐘的信号，進而産生門控後的時鐘隔一拍通過的效果，即一個占空比是1:4的二分頻時鐘（設計的初衷是實作可由指令選擇的不同分頻時鐘）。而在MBIST模式下，系統最多隻能拿到一個複位上升沿信号，不能執行讀寫指令的操作，上述使能信号是不能擷取的，是以時鐘門控單元處于常開的狀态，其後的邏輯沒有時鐘驅動。
解決時鐘門控單元擋住時鐘的問題，需要對時鐘門控的E或TE提供正确的使能信号。如下圖所示為目前對普通的時鐘門控單元的處理方法（由工具完成）。對于Memory的前置時鐘門控單元，E端前會加入一個MBIST模式選擇的MUX（OR門實作），在mbist_mode=1時直接關閉時鐘門控；與Memory時鐘無關的門控單元不作處理。對全部時鐘門控單元，TE端交給Scan_Enable信号控制，此處理方法可使E端前置邏輯變為可測。
對于本案例的解決方案，一種選擇是直接在時鐘門控之後加一級CKMUX，由外部/頂層提供測試模式下的分頻時鐘（一部分第三方IP選擇此方案）；另一種選擇是類似于上圖的解決方法，但E端在MBIST模式下不是提供1‘b1，而是提供功能模式下類似的信号（此信号不再依賴讀寫指令的操作，可自動生成），進而在這裡獲得所需的二分頻時鐘。本案例中我們選擇了第二種方法解決。
- 案例2——寄存器作為分頻器
寄存器作為時鐘二分頻是一種非常常見的時鐘結構，但該寄存器的複位信号，在功能模式下與其他寄存器是一緻的，往往不會有針對測試模式的考慮，因而直接與其他寄存器共用同一個複位信号端口。這麼做的結果是，在測試模式下，複位信号轉交由機台提供的測試複位信号，MBIST模式下為0，時鐘分頻寄存器沒有上升沿複位信号時，不能産生二分頻時鐘。解決方案是在分頻寄存器的複位端加入一個MUX，dft_mode=1時，轉接到晶片頂層的時鐘管理子產品的FUNC_RESET複位信号上，原有複位信号此時将接到晶片的SCAN RESET上，在MBIST模式下保持為0。
- 案例3——Clock Deglitch
Clock Deglitch結構用于消除時鐘選擇路徑上的毛刺，在功能模式下，選擇邏輯輸出的兩個使能信号是保證互斥，并且與時鐘沿對齊，以此保證其後或門輸出的時鐘，不會有兩個時鐘上升沿交疊部分導緻的時鐘毛刺。該結構中（目前遇到的）存在不受系統複位控制的邏輯，例如産生使能信号的寄存器，其複位信号由MUX Change Control内部生成的這一情況。是以在測試模式下，該邏輯同樣是不能工作的，即也無法輸出正确的時鐘信号。解決方法是在整個Clock Deglitch的輸出時鐘之後加一級CKMUX，跳過Deglitch結構，直接選擇到預期的時鐘輸入源上。
此處注意，我們是否可以更改ICG的使能E信号，或是更改MUX Change Control的結構來産生同樣的預期效果呢？這麼做在邏輯上是可行的，但因為工具（Tessent / Spyglass）預設的處理方法的影響，并不是一個好的選擇。Tessent工具在檢查時鐘路徑的時候，是由Memory的CLK輸入端向前追溯的，在追溯的路徑上遇到的未作特殊定義的時鐘門控ICG單元時，會按照案例1中講過的處理方法，在ICG E端加一級MUX強制關閉門控。那麼對Clock Deglitch結構來說，工具會同時處理兩個ICG，或門會同時拿到兩個時鐘，無法輸出正确的時鐘。DFT工程師通過修改sdc檔案和配置Tessent工具，可以規避這一情況；但這需要建立在工程師了解該Clock Deglitch的存在和預期要選擇的時鐘的基礎上（換言之，一定需要Debug），無法實作DFT流程的自動化。是以，推薦選擇上面所述的跳過整個Clock Deglitch的修改方法。
- 案例4——硬核IP産生的時鐘
有很多第三方IP會內建硬核PHY，PHY有可能作為時鐘産生源，為第三方IP内部的Memory和邏輯提供高速時鐘信号。如上圖所示，PHY提供的高速時鐘源，在PHY Controller内部會經過比較複雜的選擇和分頻電路，産生多個預設頻率可變的工作時鐘。PHY Controller在dft_mode下通常是不能以功能模式的行為工作的，也就是說其後應該給出的時鐘是無效的。一般第三方IP也會內建時鐘MUX，用來在dft_mode下提供旁路的測試時鐘，但也有未作周全考慮的IP，或前端設計中對第三方IP的邏輯部分做了修改的情況。此時，就需要如上圖所示，對相應的時鐘做旁路處理，由晶片頂層的PLL和Clock Manager子產品提供額外的測試時鐘，用來代替功能模式下由PHY側提供的時鐘。
- 案例5——測試模式下PLL時鐘頻率不比對
通常PLL在功能模式下預設輸出的頻率是可能需要工作的最高頻率。由于功能設計通常需要PLL時鐘的輸出頻率可控可調，PLL的輸入配置信号會交給其它子產品産生和提供。在此過程中，前端設計有可能因忽略或出錯，dft_mode下PLL輸出時鐘的頻率不等于功能模式預設提供的最高頻率。如上圖，PLL1在dft_mode下輸出的時鐘頻率未達到實際的最高頻率，不能正确執行全速測試，PLL2則輸出了過高頻率的時鐘，實測時會因為時序不滿足而測試失敗。
在完備的RTL設計中，應将PLL在dft_mode下的輸出時鐘控制于預期的最高工作頻率上。如上圖左所示，在dft_mode下PLL會拿到一組預設的配置信号，來産生預期的時鐘。另外，在dft_mode下，也需要實作PLL頻率的可調可控，那麼通常會通過DFT工具加入的TDR（Test Data Registers）子產品來旁路處理。如上圖右所示，預設的dft_mode測試過程中，TDR處于無效狀态，選擇信号輸出為0，PLL會輸出最高工作頻率；需要降頻測試時，TDR會旁路原有的預設配置信号，産生新的配置信号，來控制PLL輸出降頻時鐘信号。
- 總結
以上針對MBIST memory時鐘的描述實際上也适用于需要做全速測試的邏輯部分（Scan：At-Speed）。對前端設計者來說，設計具備DFT設計的前提條件：
- 被測試邏輯的時鐘信号在dft_mode下有效，頻率正确；
- 與時鐘信号有關的邏輯在dft_mode下能夠正确工作（複位有效，旁路/選擇正确等）；
- SDC中對時鐘源、時鐘結構（即Generated Clock）描述準确無誤；
前端設計在設計過程中，即需要對以上幾點進行考慮和規劃；設計完成後，也需要對設計在dft_mode下的時鐘頻率進行前仿驗證，或執行Spyglass DFT檢查。并且，傳遞的時鐘結構文檔和SDC是DFT工程師了解和判斷時鐘通路的必備依據，是以提供的SDC也應要包含準确的時鐘描述。DFT完備的RTL設計，将會大幅縮減DFT工程師Debug和前端疊代RTL的工作量。
預告
- （二）MBISR存儲器内建自修複
- （三）BSD邊界掃描
- （四）JTAG與IJTAG規範
- （五）Scan邏輯掃描
- （六）Transition測試與OCC
- （七）掃描鍊壓縮技術與EDT
- （八）ATPG自動測試向量生成
原文作者：和琰
點選檢視原文