這顆芯片第一次從測試機(jī)下來的時(shí)候ATPG的pattern怎么跑都掛在同一個(gè)向量上speed test更難看shmoo圖紅了一大片。一開始所有人都在懷疑是不是DFT插入的時(shí)候把哪條路徑的約束做松了負(fù)責(zé)時(shí)序的同事翻了三天的timing report也沒看出毛病。最后我拿示波器探頭戳在下游PLL的參考時(shí)鐘引腳上才反應(yīng)過來一個(gè)特別低級的邏輯問題級聯(lián)PLL的下游那一級被我做的OCC時(shí)鐘控制給“餓死”了。簡單說就是我把上游PLL在測試模式下旁路掉下游PLL沒有了參考時(shí)鐘直接失鎖測試時(shí)鐘鏈自然就斷了。DFTC做OCC時(shí)鐘控制本身是SoC芯片里at-speed測試很成熟的一條路徑但級聯(lián)PLL這個(gè)場景特別容易踩坑。級聯(lián)結(jié)構(gòu)在每個(gè)SoC里幾乎都有比如外部晶振進(jìn)主PLL主PLL的輸出再喂給音頻PLL、SerDes的恢復(fù)時(shí)鐘PLL、或者USB PHY做參考時(shí)鐘——外部晶振不夠用、PCB上不想多放晶振、又或者需要跟片上時(shí)鐘嚴(yán)格同源的時(shí)候這種“PLL串PLL”的設(shè)計(jì)非常常見。問題就出在OCC邏輯要管的是測試模式的capture時(shí)鐘而測試模式下我們習(xí)慣性會把“用不到”的PLL全部旁路掉。這一句“用不到”里就埋著“餓死”的雷。1. 一顆芯片死在測試模式級聯(lián)PLL“餓死”的現(xiàn)象與代價(jià)先說清楚“餓死”到底指什么。PLL本質(zhì)上是一個(gè)閉環(huán)反饋系統(tǒng)它需要一個(gè)參考時(shí)鐘作為輸入鑒相器才能正常工作。級聯(lián)PLL的下游這一級參考輸入不是來自晶振而是來自上游PLL的輸出。上游PLL一旦在測試模式下被旁路、被關(guān)掉、或者輸出被切換到其他時(shí)鐘路徑下游PLL的參考輸入就等于斷了。PLL失鎖之后輸出頻率會漂移或者干脆停在某個(gè)不穩(wěn)定的狀態(tài)這個(gè)時(shí)候不管OCC邏輯本身做得有多對從它出來的測試時(shí)鐘都是有問題的。我在那個(gè)項(xiàng)目里遇到的現(xiàn)象很典型。Scan pattern全部能過因?yàn)閟can shift本來就用的是慢速測試時(shí)鐘低頻下PLL狀態(tài)根本不影響但一到at-speed的capture階段就掛。掛在哪個(gè)向量上也不是固定的有時(shí)候同一個(gè)pattern這次跑過下次又跑不過完全看PLL失鎖之后輸出頻率漂到了哪個(gè)位置。這種“時(shí)好時(shí)壞”的表現(xiàn)在封測廠那邊會特別難排查測試工程師的第一反應(yīng)往往是覺得pattern有race或者DFT約束有violation沒人會想到是參考時(shí)鐘鏈斷了。這事的代價(jià)遠(yuǎn)不止調(diào)兩天pattern。那顆芯片因?yàn)閟peed test過不了只能靠redundant pattern和低速功能測試來彌補(bǔ)at-speed覆蓋率的缺口直接導(dǎo)致測試質(zhì)量下降。后面為了驗(yàn)證確實(shí)是PLL餓死的問題我們把PCB上那顆芯片拆下來重新bonding了測試點(diǎn)又花了三周時(shí)間。算下來前后接近一個(gè)半月兩個(gè)FAE、一個(gè)DFT工程師、一個(gè)驗(yàn)證工程師的人力全搭在這個(gè)問題里。回過頭看這類問題其實(shí)在設(shè)計(jì)階段完全可以避免關(guān)鍵是搞清楚一點(diǎn)OCC的參考時(shí)鐘不是“你想用哪個(gè)PLL就用哪個(gè)PLL”而是“這個(gè)PLL能不能在這個(gè)時(shí)刻穩(wěn)定地給出參考時(shí)鐘”。級聯(lián)結(jié)構(gòu)下這個(gè)“能不能”是和上游所有PLL的狀態(tài)綁在一起的。2. 為什么不能把OCC簡單看成“時(shí)鐘選擇器”它在at-speed測試?yán)锏恼鎸?shí)角色很多剛接觸DFT的工程師會把OCC理解成一個(gè)多路選擇器功能模式切功能時(shí)鐘測試模式切測試時(shí)鐘capture的時(shí)候控制一下脈沖數(shù)就完了。如果只是這樣想就很容易在級聯(lián)PLL的配置上出錯(cuò)。OCC的全稱是On-Chip Clock Controller它的核心任務(wù)是在at-speed測試的capture階段產(chǎn)生精確數(shù)量的、頻率可控的時(shí)鐘脈沖同時(shí)保證launch和capture之間的時(shí)序關(guān)系是確定的。它不是隨便切一下時(shí)鐘而是要把“功能路徑上的時(shí)鐘行為”在測試模式下復(fù)現(xiàn)出來。DFTCDesign For Test Compiler是工具流程OCC是它插入的硬件邏輯結(jié)構(gòu)兩者是“工具”和“產(chǎn)物”的關(guān)系。一個(gè)典型的OCC邏輯包含這樣幾個(gè)部分時(shí)鐘選擇mux用來在功能時(shí)鐘、測試慢時(shí)鐘、以及PLL輸出之間切換脈沖計(jì)數(shù)器用來控制capture階段產(chǎn)生幾個(gè)時(shí)鐘沿使能控制邏輯用scan_enable、shift_enable這類信號來區(qū)分shift階段和capture階段還有PLL lock信號的處理邏輯用來保證在PLL穩(wěn)定之前不會發(fā)出capture脈沖。這里最容易被忽視的就是最后一點(diǎn)PLL lock信號的處理。OCC在設(shè)計(jì)上是“等PLL鎖定了再發(fā)脈沖”的但“等”多久、在什么條件下“等”取決于DFTC插入時(shí)的配置。在單PLL場景下這很簡單反正那個(gè)PLL只管自己等它lock了就行。但在級聯(lián)PLL場景下問題變成了你等的這個(gè)PLL下游PLL它自己都沒“吃飽”——它的參考時(shí)鐘來自上游PLL而你在測試模式下恰好把上游PLL的一部分功能給關(guān)了或旁路了。OCC等一個(gè)永遠(yuǎn)等不到的lock信號capture自然就廢了。打個(gè)不精確但很好懂的比方OCC就像一個(gè)廚房里的傳菜員它要知道菜好了沒有l(wèi)ock信號才能上菜。單PLL場景里菜是單獨(dú)一個(gè)灶臺做的傳菜員盯著這個(gè)灶臺就行。級聯(lián)場景里下游這個(gè)灶臺的火是靠上游那個(gè)灶臺供氣的你把上游的煤氣閥門關(guān)了下游的菜永遠(yuǎn)做不熟傳菜員再怎么等也沒有用。所以級聯(lián)PLL場景下DFTC插入OCC的視野必須是全局的。你不能只看“OCC的參考時(shí)鐘選了哪個(gè)PLL”而要沿著這個(gè)PLL的參考時(shí)鐘鏈一路往上游看確認(rèn)整條鏈上每一個(gè)環(huán)節(jié)在測試模式下都能維持穩(wěn)定。3. 級聯(lián)PLL餓死的三個(gè)根因旁路開關(guān)、lock窗口和仿真模型的“假象”把級聯(lián)PLL餓死這個(gè)問題拆到根上通常逃不出三個(gè)原因旁路邏輯放錯(cuò)了位置、lock等待窗口不夠、仿真模型掩蓋了問題。我一個(gè)個(gè)說。3.1 旁路開關(guān)的一刀切測試模式把所有PLL都bypass很多芯片設(shè)計(jì)里都會有一根全局的test_mode或dft_bypass信號進(jìn)了PLL之后會把PLL強(qiáng)制到旁路模式也就是讓時(shí)鐘繞過PLL的倍頻環(huán)路直接把參考時(shí)鐘透傳出去。這樣做的初衷是方便某些低速測試省得PLL鎖定的時(shí)間拖慢測試節(jié)奏。但問題也出在這根全局信號上。在級聯(lián)結(jié)構(gòu)里上游PLL的旁路信號實(shí)際上同時(shí)控制了下游PLL的“口糧”。你把上游PLL旁路了它的輸出還會存在但已經(jīng)不是正常的、干凈的被鎖定的時(shí)鐘了下游PLL拿這個(gè)亂跳的信號當(dāng)參考鑒相器根本鎖不住輸出就變成一團(tuán)糟。在我們那個(gè)芯片里設(shè)計(jì)上為了穩(wěn)妥把測試模式下的所有PLL都接到了同一個(gè)bypass控制上。功能模式一切正常一到測試模式上游主PLL被旁路下游音頻PLL瞬間斷糧。DFTC插入的OCC邏輯本身沒有任何問題但因?yàn)樗靶湃巍绷嗽O(shè)計(jì)給的PLL狀態(tài)就跟著一起出問題。這個(gè)根因的解法其實(shí)不難級聯(lián)結(jié)構(gòu)里作為“參考源”的上游PLL在測試模式下不能被旁路要讓它保持正常的鎖定輸出狀態(tài)。如果確實(shí)需要旁路要么在旁路邏輯上對不同的PLL做區(qū)分要么讓下游PLL在測試模式下改用獨(dú)立的慢時(shí)鐘源不要依賴上游PLL。3.2 lock信號的等待窗口PLL重新鎖定也要時(shí)間第二個(gè)坑和PLL lock信號的時(shí)序有關(guān)它更隱蔽。即使你沒有旁路上游PLL上游PLL輸出正常下游PLL也可能因?yàn)闇y試過程中信號擾動(dòng)、電源噪聲等種種原因而短暫失鎖需要重新鎖定。PLL的鎖定時(shí)間典型值在幾十微秒到幾百微秒量級具體看環(huán)路帶寬和分頻比。OCC邏輯在capture之前是要等lock信號的但DFTC插入時(shí)的等待邏輯通常是不管PLL是“一直鎖定”還是“剛重新鎖定”的它只看lock信號有沒有拉起來。有些設(shè)計(jì)里的lock計(jì)數(shù)窗口比較短PLL還沒完全鎖定lock標(biāo)志已經(jīng)拉起來了有些PLL在臨界鎖定狀態(tài)lock信號會抖動(dòng)這時(shí)候OCC以為PLL好了實(shí)際上頻率還沒穩(wěn)住capture打出來的波形自然是錯(cuò)的。我在后來的項(xiàng)目里總結(jié)了一條經(jīng)驗(yàn)DFTC配置OCC的時(shí)候lock信號的來源和時(shí)序一定要讓PLL供應(yīng)商的模型里帶出來的lock behavior對上。如果PLL的lock輸出在鎖定初期有毛刺OCC的等待邏輯就得加過濾或者干脆用lock_count多等幾拍。這個(gè)在單PLL場景下可能不致命但級聯(lián)場景下下游PLL的鎖定時(shí)間還要疊加上游PLL的擾動(dòng)窗口很容易不夠。3.3 仿真模型的“假象”PLL模型在參考丟失時(shí)到底輸出什么第三根因是最坑的因?yàn)樗鼤屒懊嫠袉栴}在設(shè)計(jì)驗(yàn)證階段“看起來不存在”。很多PLL的行為級模型在參考時(shí)鐘丟失或者混亂的時(shí)候輸出的是一個(gè)X態(tài)或者未知態(tài)。在仿真里X態(tài)會直接傳播到OCC邏輯導(dǎo)致capture使能一直拉不起來仿真直接報(bào)錯(cuò)。這種情況下驗(yàn)證工程師會發(fā)現(xiàn)“測試模式跑不通”但定位方向很容易走偏以為是自己控制邏輯寫錯(cuò)了。更麻煩的是有些模型在參考丟失時(shí)保持上一時(shí)刻的輸出頻率看起來波形完全正常仿真里ATPG pattern能跑過但實(shí)際芯片里PLL早就失鎖了。這就是“仿真通過、實(shí)測全掛”的經(jīng)典劇本。我見過的項(xiàng)目里這個(gè)問題往往要等芯片回來才能暴露代價(jià)極大。所以做級聯(lián)PLL場景的DFT驗(yàn)證時(shí)必須主動(dòng)去檢查仿真模型在參考時(shí)鐘異常的情況下是什么行為如果模型過于理想就得人為注入故障來驗(yàn)證OCC的fail-safe行為或者至少在仿真環(huán)境下強(qiáng)制檢查參考時(shí)鐘鏈上每個(gè)節(jié)點(diǎn)的合法性。這一點(diǎn)DFTC本身不會替你做需要flow里額外加check。4. 定位餓死問題的完整排查鏈路從“pattern跑掛”到“揪出參考時(shí)鐘鏈斷點(diǎn)”如果你已經(jīng)在芯片上看到了類似癥狀這里有一條我自己用過的排查路徑每一步做了什么事、怎么判斷都寫清楚可以照著一步步走。4.1 第一步判斷是生成問題還是硬件問題用仿真復(fù)現(xiàn)遇到at-speed pattern掛第一件事是區(qū)分問題的性質(zhì)。先把同一個(gè)pattern在仿真環(huán)境里重新跑一遍用SDF反標(biāo)時(shí)序看看仿真里能不能復(fù)現(xiàn)。如果仿真里也掛那大多是邏輯功能或約束問題如果仿真里全過而實(shí)測掛基本上可以默認(rèn)懷疑測試時(shí)鐘路徑的硬件行為有異?！狿LL鏈路是首要嫌疑。這一步的關(guān)鍵技巧是仿真通過不代表硬件沒問題因?yàn)樾袨槟Ｐ涂赡苎谏w了真實(shí)PLL的非理想行為。所以額外要做一件事就是檢查仿真里用的PLL模型是不是“理想得太離譜”如果是直接跳到第三步不要糾結(jié)仿真結(jié)果。4.2 第二步示波器實(shí)測看PLL輸出頻率和lock信號芯片貼到測試板上之后如果懷疑PLL鏈路直接量波形不要看pattern。把示波器探頭戳在下游PLL的輸出時(shí)鐘引腳上觸發(fā)條件設(shè)成測試模式的入口沿然后抓整個(gè)at-speed測試窗口內(nèi)的時(shí)鐘波形。正常情況應(yīng)該看到一個(gè)頻率穩(wěn)定、占空比穩(wěn)定的時(shí)鐘。如果看到的波形是亂的、頻率在漂移的、或者長時(shí)間停在某個(gè)電位上基本可以判定PLL工作狀態(tài)異常。再拿第二根探頭去量下游PLL的lock信號配合時(shí)鐘波形一起看——如果lock信號在capture階段之前根本沒有拉高或者拉高之后又掉下來那問題就鎖定在PLL鎖定環(huán)節(jié)。4.3 第三步順著參考時(shí)鐘鏈往上查找到斷點(diǎn)確認(rèn)PLL有問題后不要急著改DFTC配置要逆著參考時(shí)鐘鏈往上查。下游PLL的參考時(shí)鐘是哪來的如果是來自上游PLL繼續(xù)查上游PLL在測試模式下是什么狀態(tài)。把測試模式下的控制信號波形拉出來看bypass信號有沒有被置位、上游PLL的輸出是否正常、中間有沒有mux切到了別的路徑。這一步是定位餓死的決定性環(huán)節(jié)。我當(dāng)時(shí)就是在這里看到上游主PLL的bypass信號在測試模式下一路拉高同時(shí)下游PLL的參考時(shí)鐘引腳上波形稀爛一下就明白了。4.4 第四步實(shí)驗(yàn)性修改驗(yàn)證根因找到斷點(diǎn)之后不要急著流片先用一個(gè)實(shí)驗(yàn)性修改來驗(yàn)證判斷。最簡單的辦法是在測試模式下強(qiáng)行讓上游PLL保持正常的非旁路狀態(tài)再跑一遍ATPG pattern。如果之前掛的pattern現(xiàn)在能過那根因基本石錘。如果上游PLL沒法在測試模式下保持退一步的方案是把下游PLL的參考時(shí)鐘在測試模式下切到一個(gè)獨(dú)立的、可用的時(shí)鐘源上比如直接把晶振時(shí)鐘引過來這樣下游PLL也有飯吃O(shè)CC也能正常工作。這個(gè)方法在很多項(xiàng)目里是最終的workaround雖然會增加一點(diǎn)時(shí)鐘切換邏輯但能保住at-speed測試覆蓋率。5. 級聯(lián)PLL場景下DFTC配置的幾個(gè)關(guān)鍵雷區(qū)從時(shí)鐘邊界到同步處理確認(rèn)了餓死的原理之后再回到DFTC配置本身有一些具體的地方是特別容易踩雷的這里一條條過。5.1 時(shí)鐘分組和OCC參考時(shí)鐘的選擇DFTC在插入OCC的時(shí)候需要為每個(gè)時(shí)鐘域指定OCC的參考時(shí)鐘。在級聯(lián)PLL的場景里指定參考時(shí)鐘的時(shí)候一定要把PLL之間的依賴關(guān)系考慮進(jìn)去。比如下游PLL_OCC的參考時(shí)鐘選了PLL_B那PLL_B的參考時(shí)鐘PLL_A必須在整個(gè)測試窗口內(nèi)穩(wěn)定。操作上我會在DFTC的時(shí)鐘規(guī)范里把PLL_A的時(shí)鐘定義成“測試期間必須保持的時(shí)鐘”不讓工具在優(yōu)化的時(shí)候把它優(yōu)化成test clock。同時(shí)把PLL_B的鎖定條件依賴的時(shí)鐘路徑全部設(shè)成false path或者case analysis避免工具在STA的時(shí)候誤報(bào)。這些約束看起來很小但少一個(gè)都可能導(dǎo)致工具在優(yōu)化時(shí)動(dòng)到你不希望動(dòng)的邏輯。5.2 全局bypass信號的層級分配很多設(shè)計(jì)的dft_bypass信號在頂層統(tǒng)一拉線到所有PLL這在功能上很簡單但DFTC視角下這個(gè)信號會變成一個(gè)很大的約束扇出。如果某些PLL不能bypass就得通過DFT信號約束把它們的bypass關(guān)系打斷。推薦的做法是在頂層定義清楚“可旁路PLL”和“不可旁路PLL”的清單然后給不可旁路的PLL單獨(dú)做約束確保它們的bypass狀態(tài)在測試模式下不被全局信號覆蓋。這個(gè)清單最好能直接掛在DFT plan文檔里方便后面人接手時(shí)不會改錯(cuò)。5.3 lock信號的異步處理和跨時(shí)鐘域PLL的lock信號來自PLL的模擬部分和數(shù)字邏輯的時(shí)鐘是異步的。DFTC插入的OCC邏輯里lock信號如果直接進(jìn)到數(shù)字時(shí)序邏輯會有亞穩(wěn)態(tài)風(fēng)險(xiǎn)。雖然OCC本身的時(shí)序容錯(cuò)性還好但最好的實(shí)踐是給lock信號加兩級同步器并且讓同步器的時(shí)鐘和OCC的控制時(shí)鐘保持一致。級聯(lián)PLL場景下下游PLL的lock信號還隱含了上游PLL的穩(wěn)定性信息所以在約束上要把lock信號的到達(dá)時(shí)間相對于OCC的capture時(shí)鐘沿留出足夠裕量。我在一個(gè)項(xiàng)目里見到過因?yàn)閘ock信號同步器時(shí)鐘選錯(cuò)導(dǎo)致capture階段鎖存到錯(cuò)誤的lock值進(jìn)而少發(fā)一個(gè)脈沖的情況排查起來極其痛苦。5.4 多PLL同時(shí)啟動(dòng)的功耗和串?dāng)_問題級聯(lián)結(jié)構(gòu)里還有一個(gè)容易被忽略的問題如果測試模式下所有PLL都要保持開啟尤其是有好幾個(gè)PLL串在一起的時(shí)候模擬部分的功耗會比單PLL場景大不少。IR drop一大PLL的抖動(dòng)特性會變差可能從“穩(wěn)定鎖定”變成“鎖定但抖動(dòng)超標(biāo)”最終還是會體現(xiàn)為at-speed測試失敗。這個(gè)層面的問題DFTC管不了需要在芯片的電源規(guī)劃階段就給測試模式留出足夠的余量。我建議在做PLL鏈路的功耗仿真時(shí)專門跑一個(gè)“全PLL開啟at-speed capture”的模式看一下電源網(wǎng)絡(luò)上最大的壓降點(diǎn)在哪里。如果壓降超標(biāo)調(diào)整電源mesh或者加去耦電容都比事后在測試上補(bǔ)強(qiáng)要便宜得多。6. Hierarchy Flow的落地建議從子模塊到頂層的時(shí)鐘鏈統(tǒng)一規(guī)劃前面聊的很多還是單芯片級別的問題一旦上了Hierarchy Flow也就是層次化設(shè)計(jì)流程餓死的風(fēng)險(xiǎn)還會再高一截因?yàn)槊總€(gè)子模塊的DFTC是分開跑的工具很難看到完整的全局時(shí)鐘鏈。這里給幾條實(shí)際操作建議。6.1 子模塊DFTC插入前先做時(shí)鐘依賴分析Hierarchy Flow下子模塊做DFT的時(shí)候往往是blackbox掉其他模塊的你在這個(gè)子模塊里看到PLL_B但PLL_B的參考時(shí)鐘來自頂層你是看不到的。所以在子模塊跑DFTC之前必須先做一輪時(shí)鐘依賴分析把每個(gè)OCC參考時(shí)鐘的源頭一路追到真正的參考源晶振或者上游PLL然后把這條鏈路單獨(dú)列出來標(biāo)注出“測試期間必須保持穩(wěn)定”的節(jié)點(diǎn)。這個(gè)分析結(jié)果要寫進(jìn)子模塊的DFT約束文件里并且在插入OCC之后人工確認(rèn)一遍。6.2 頂層接口信號規(guī)劃讓“必須保持”的PLL不受測試模式干擾層級化設(shè)計(jì)的接口規(guī)劃里最容易出的問題是子模塊里PLL的bypass信號被頂層測試控制信號接管了而頂層設(shè)計(jì)師并不知道這個(gè)PLL是另一個(gè)模塊的參考。所以接口文檔里必須明確列出哪些PLL是“本模塊需要”的哪些PLL是“其他模塊需要”的。對于后者你的模塊在測試模式下絕對不能動(dòng)它。這個(gè)列表在Hierarchy Flow里比在flat flow里重要得多因?yàn)槟忝鎸Φ目赡苁嵌鄠€(gè)團(tuán)隊(duì)開發(fā)的模塊互相之間根本不了解對方時(shí)鐘鏈路的細(xì)節(jié)。6.3 頂層OCC和子模塊OCC的協(xié)同避免兩層都等lock還有一個(gè)很實(shí)際的問題如果頂層也插了OCC子模塊也插了OCC兩級OCC的lock等待邏輯可能互相沖突。頂層OCC在等頂層級聯(lián)PLL的lock子模塊OCC在等子模塊PLL的lock兩級的等待時(shí)間如果疊加在一起測試pattern的時(shí)序預(yù)算就非常緊張。我的建議是遇到級聯(lián)PLL盡量不要做兩級OCC都等待的配置。要么讓頂層的OCC統(tǒng)一控制capture子模塊的OCC只做時(shí)鐘選擇不復(fù)用lock等待要么反過來子模塊控制頂層只透傳。總之lock等待邏輯要收斂在一個(gè)層級不要兩級同時(shí)參與否則時(shí)序很難收。6.4 Signoff前的一張自查清單最后分享一張我每次做類似項(xiàng)目signoff前都會過一遍的清單。不復(fù)雜但每一項(xiàng)都是真金白銀換來的教訓(xùn)所有OCC的參考時(shí)鐘逐條追到最終參考源確認(rèn)測試期間整條鏈路都保持穩(wěn)定關(guān)閉所有不必要的PLL旁路特別是級聯(lián)鏈路里的上游PLL確認(rèn)PLL lock信號的同步器時(shí)鐘選擇正確且等待窗口足夠覆蓋PLL重鎖時(shí)間仿真驗(yàn)證里加入?yún)⒖紩r(shí)鐘斷鏈的負(fù)向測試用例確認(rèn)OCC能正確fail或進(jìn)入安全狀態(tài)頂層和子模塊之間明確lock等待邏輯的歸屬層級不重復(fù)等待電源仿真覆蓋“測試模式全PLL開啟”場景確認(rèn)IR drop不超標(biāo)和PLL供應(yīng)商確認(rèn)模型在參考丟失時(shí)的行為不該理想的地方不要理想這套清單看起來繁瑣但每次跑完都能攔下至少一兩個(gè)問題有些問題如果流片之后才發(fā)現(xiàn)可能就是幾十萬美金的代價(jià)。做DFT的很多時(shí)候干的就是這種“在設(shè)計(jì)階段多花一小時(shí)省下流片后一個(gè)月”的活兒。最后再多說一句個(gè)人體會DFTC始終是一個(gè)工具它可以按你的約束完美插入OCC邏輯但它不知道你的PLL之間誰是誰的“飯票”。級聯(lián)PLL的時(shí)鐘鏈在測試模式下能不能活本質(zhì)上取決于做DFT的人有沒有把芯片的真實(shí)時(shí)鐘依賴關(guān)系Mapping到工具的約束里。這塊思路理清了DFTC只是執(zhí)行理不清它就帶你在坑里兜圈子。