我之前遇到過一件事幫同事review一組transition fault的測試向量時生成結(jié)果和功能仿真都過了可一上ATE就出現(xiàn)偶發(fā)的不穩(wěn)定。幾個人排查了大半天最后定位到問題竟然出在Launch和Capture兩個時鐘沿的配置上——工具默認(rèn)按下降沿當(dāng)發(fā)射沿可那塊設(shè)計里的掃描觸發(fā)器是上升沿觸發(fā)等于所有向量都把“發(fā)射”動作放錯了位置。那次之后我就一直想寫一篇關(guān)于Scan測試?yán)風(fēng)aunch與Capture機(jī)制的文章因為這東西幾乎決定了at-speed測試能不能真正跑到點子上但它恰恰是很多DFT工程師和測試工程師容易一帶而過的地方。這篇文章會從Launch與Capture在掃描測試?yán)锏恼鎸嵎止ら_始講清楚LOS和LOC兩條路線的差異再把時鐘、SE控制、EDT壓縮這些實際操作里躲不開的細(xì)節(jié)拉出來過一遍最后分享幾個讓我花過不少時間的排錯案例。適合剛接觸DFT的芯片工程師也適合已經(jīng)跑過幾輪at-speed pattern、但始終覺得“這個沿的時序沒完全吃透”的同行。1. 別把Launch和Capture理解成“發(fā)射”和“接收”它們在測試流程里的真實分工1.1 Shift階段只是擺好姿勢真正的狀態(tài)變化要從Launch沿說起掃描測試的基本流程看起來很簡單就是把觸發(fā)器串成鏈Shift時用移位時鐘把測試向量推入各條掃描鏈再給一個Capture時鐘把響應(yīng)鎖存回來。但很多人沒細(xì)想的是Shift階段做得再多電路內(nèi)部也只是搭好了一個確定的靜態(tài)狀態(tài)并沒有發(fā)生功能意義上的跳變。真正讓電路“動起來”的是Launch沿。Launch沿產(chǎn)生的時機(jī)是在SE信號從1變?yōu)?之后。它之所以重要是因為觸發(fā)器從這個沿開始切換到正常工作路徑數(shù)據(jù)會從功能D端進(jìn)入。對transition fault測試來說Launch沿要制造一個跳變信號從0跳到1或者從1跳到0然后這個跳變沿著組合邏輯向后傳播直到下一個觸發(fā)器的D端。等Capture沿到來時如果D端已經(jīng)穩(wěn)定到期望值那就說明這條路徑能在規(guī)定時間內(nèi)完成任務(wù)。我喜歡用一個彈球的類比來解釋Shift階段相當(dāng)于把球擺到斜坡頂端擺好位置但球還沒動Launch沿就是松手讓球真正開始滾Capture沿相當(dāng)于在斜坡底部按下快門確認(rèn)球有沒有在指定時間內(nèi)滾到底。如果把快門按下得比路徑真實耗時早球的慣性還沒到明明可以通過的路徑被判成失效如果按下得太晚又會掩蓋真正的慢路徑缺陷。這就是為什么Launch和Capture不是兩個孤立的時鐘脈沖它們之間的關(guān)系本質(zhì)上就是被測路徑的時序窗口。1.2 Capture沿鎖定響應(yīng)但鎖定質(zhì)量取決于launch到capture的距離Capture沿的工作是鎖存組合邏輯輸出。這個沿出現(xiàn)的位置窗口直接決定了被測的是哪一段路徑。以最常見的two-pulse方式為例一個Launch沿讓所有信號開始轉(zhuǎn)換經(jīng)過一個周期的傳播時間Capture沿再把結(jié)果鎖入掃描觸發(fā)器。這里有一個關(guān)鍵前提——Capture沿和Launch沿之間的時間差必須和真實功能路徑的時鐘周期一致。如果捕獲沿來得早等于拿一個比真實工作頻率更快的時鐘去測所有路徑都會變得很緊測試結(jié)果會過度激進(jìn)如果捕獲沿來得晚相當(dāng)于放慢頻率小延遲缺陷會被掩蓋。很多人誤以為ATPG工具會自動處理好這件事。但工具的“自動”是建立在約束正確的基礎(chǔ)上的。如果SDC里寫錯了時鐘周期或者設(shè)計里存在門控時鐘、分頻時鐘工具默認(rèn)找出來的Launch沿未必落在真實的觸發(fā)沿上。上文提到的那個ATE偶發(fā)不穩(wěn)定案例本質(zhì)就是工具和機(jī)臺對“哪個沿算launch”理解不一致。1.3 為什么stuck-at測試只有一個Capture脈沖而transition測試必須拆成兩個沿有一類測試不需要Launch就是最經(jīng)典的stuck-at測試。它檢測的是靜態(tài)邏輯故障比如某根信號固定為0或固定為1。對這類故障來說只要給一個穩(wěn)定的激勵等組合邏輯輸出穩(wěn)定下來慢速Capture一次就能看到結(jié)果。而transition fault測試關(guān)注的是信號能不能在限定時間內(nèi)完成指定的轉(zhuǎn)換這從本質(zhì)上是一個動態(tài)問題。“能不能轉(zhuǎn)換成功”和“轉(zhuǎn)換速度夠不夠快”是兩件事。要測清楚這兩件事就必須用兩個沿先用Launch沿制造跳變再在設(shè)定的時間點用Capture沿去觀察跳變是否在容限內(nèi)完成。有些剛開始寫測試程序的工程師會把stuck-at和transition的兩拍混在一起認(rèn)為給兩個脈沖就更保險。實際上對stuck-at測試硬塞兩個脈沖不但浪費測試時間還可能因為第二次capture把本已穩(wěn)定下來的狀態(tài)推翻讓測試結(jié)果變得不可解釋。正確的做法是stuck-at一拍捕獲transition兩拍發(fā)射加捕獲。2. LOS與LOC兩條完全不同的發(fā)射-捕獲路線選錯可能讓測試白跑一輪2.1 Launch-off-ShiftLOS的原理和代價在at-speed測試?yán)飳崿F(xiàn)Launch與Capture最直接的方式叫Launch-off-Shift也就是經(jīng)常聽說的LOS也稱作skewed-load方式。它的核心思想很簡單把掃描移位過程中的最后一個時鐘沿直接當(dāng)成發(fā)射沿。具體過程是這樣的。電路一直處于Shift模式SE信號為1最后一個移位脈沖把鏈上的所有掃描單元格子填滿。這個最后一個沿本身就是Launch沿它在SE仍然為1或剛剛跳變到0的時刻完成了一次數(shù)據(jù)的移入。緊接著SE快速跳變?yōu)?電路退回功能模式然后很短時間后產(chǎn)生Capture沿。LOS的優(yōu)點非常明顯因為Launch沿來自掃描輸入工程師可以精確控制每個觸發(fā)器在發(fā)射時刻的初始值這對故障激活條件的構(gòu)造非常有利。實測下來在同樣規(guī)模的故障集下LOS的覆蓋率通常比LOC高出幾個百分點生成pattern的數(shù)量也可能更少。但代價也相當(dāng)直接。SE信號在“最后一個shift沿”和“capture沿”之間必須完成從1到0的翻轉(zhuǎn)而且留給它的時間窗口極短。如果SE翻轉(zhuǎn)得不夠快或時鐘分布網(wǎng)絡(luò)有偏斜就會出現(xiàn)部分觸發(fā)器還在Shift模式、部分已經(jīng)切回功能模式的混亂狀態(tài)。這種情況輕則測試失真重則直接產(chǎn)生亞穩(wěn)態(tài)。所以LOS并不是一個可以隨意選用的方案它對后端時鐘樹設(shè)計、DFT時鐘約束、SE信號的插入位置都有很高的要求。一旦哪一環(huán)沒做好LOS測試在ATE上跑出來的數(shù)據(jù)往往是“看起來有覆蓋率但重復(fù)性很差”。2.2 Launch-off-CaptureLOC的原理與工程優(yōu)勢和LOS相對的是Launch-off-Capture也常被叫做broadside方式。LOC的思路是先把測試向量完整地移入掃描鏈SE信號繼續(xù)保持為0足夠長的時間讓所有觸發(fā)器穩(wěn)定下來然后發(fā)出第一個Capture沿——這個沿在這個方案里承擔(dān)Launch的職責(zé)緊接著再發(fā)第二個Capture沿真正地捕獲響應(yīng)。簡單說LOC用“捕獲沿來做發(fā)射”兩個脈沖來自同一組Capture時鐘它們在時序關(guān)系上更接近芯片真實的功能操作。LOC在工程上為什么更受歡迎因為它對SE信號的要求很低。SE在第一個Capture沿到來之前就已經(jīng)穩(wěn)定為0不存在LOS那種“必須快速翻轉(zhuǎn)”的緊張窗口。時鐘樹設(shè)計也相對輕松后端CTS只需要保證正常的Capture時鐘能到達(dá)所有觸發(fā)器即可ATPG工具對這種模式的支持也是最成熟的。代價是故障覆蓋率通常會略低。原因是LOC的launch沿初始狀態(tài)并不是直接來自掃描輸入而是來自上一拍捕獲后的結(jié)果這意味著有些路徑的初始狀態(tài)約束無法被精確構(gòu)造。為了彌補(bǔ)ATPG往往需要多生成一些pattern測試時間也會小幅增加。2.3 工程上怎么選不是越高級越好而是看你的設(shè)計收斂瓶頸在哪實際項目中選擇LOS還是LOC很少是因為“哪個覆蓋率更高”這種單一指標(biāo)決定更多是在時序收斂、后端工作量和覆蓋率之間做權(quán)衡。對比維度LOSskewed-loadLOCbroadside故障覆蓋率通常更高略低但可通過pattern數(shù)量彌補(bǔ)SE時序要求極高SE需在launch沿附近快速翻轉(zhuǎn)低SE提前變?yōu)?即可時鐘樹/CTS約束嚴(yán)格需要精細(xì)設(shè)計寬松適合常規(guī)后端流程后端DFT工作量較大較小ATPG運行時間通常較短通常較長pattern數(shù)量更多典型應(yīng)用場景高性能CPU、超高速接口大多數(shù)SoC/ASIC量產(chǎn)項目我自己的經(jīng)驗是量產(chǎn)項目如果后端時序收斂壓力很大優(yōu)先選LOC這是最不容易翻車的路線。但如果設(shè)計里存在高速模塊或缺陷率一直偏高、需要更高測試靈敏度可以在關(guān)鍵模塊單獨用LOS跑一組pattern和LOC的pattern并行投入?，F(xiàn)在有些工具也支持在同一設(shè)計里讓不同時鐘域分別采用LOC和LOS這種混合模式正在成為主流因為它兼顧了兩邊的好處代價是配置復(fù)雜度上升對時序分析能力要求更高。3. 時鐘沿、SE翻轉(zhuǎn)時刻和脈沖寬度這些時序參數(shù)決定向量在ATE上能不能跑3.1 一個完整測試周期里Shift、Launch、Capture的位置關(guān)系把一次測試展開來看會看到這樣一段清晰的時序序列Shift階段SE 1測試時鐘連續(xù)輸出多個移位脈沖把下一個向量移入所有掃描鏈同時把上一輪的響應(yīng)從鏈尾移出。Launch階段SE變?yōu)?在穩(wěn)定了足夠時間后輸出第一個有效脈沖沿啟動內(nèi)部狀態(tài)跳變。Capture階段緊接著輸出的第二個有效脈沖沿把跳變后的結(jié)果鎖存進(jìn)掃描觸發(fā)器。下一輪Shift階段SE重新變?yōu)?繼續(xù)移位循環(huán)往復(fù)。在這段序列里L(fēng)aunch與Capture之間的那段時間是整條測試鏈路上最敏感的部分。這段間隔由測試時鐘周期決定而測試時鐘周期又來自芯片功能時鐘頻率的約束。測試工程師在寫ATE時基時往往需要為Shift階段設(shè)一個低速時鐘為Launch-Capture階段設(shè)一個高速時鐘這就是所謂的“慢速移位、快速捕獲”策略。這個策略的意圖很容易理解Shift階段要推入大量數(shù)據(jù)但此階段不關(guān)心時序細(xì)節(jié)用慢速時鐘可以降低測試功耗和信號噪聲而Launch到Capture這段窗口則必須模擬真實工作頻率否則transition fault測試就失去了意義。實際配置ATE的時候這兩個時基之間的切換時刻必須精確控制我見過不少測試程序就是因為時基切換早了或晚了半個周期導(dǎo)致一整個向量組全部廢掉。3.2 SE信號是at-speed測試最容易忽略、也最容易翻車的環(huán)節(jié)很多做DFT的新手在分析時序時會花大量時間盯著時鐘沿卻忽略了SE信號。但在at-speed測試?yán)颯E恰恰是最容易出錯的控制信號。一個很常見的錯誤場景是這樣的設(shè)計里的SE由測試引腳直接驅(qū)動當(dāng)測試時鐘頻率很高時SE在Launch沿到達(dá)的瞬間還沒來得及穩(wěn)定到0或者發(fā)生了跳變邊沿的毛刺。這時部分掃描觸發(fā)器仍然處于Shift模式那個所謂的“Launch沿”實際被當(dāng)成了又一個Shift沿整個鏈上鎖存的位就會被推偏一位。響應(yīng)數(shù)據(jù)從Capture沿讀出來時看起來信號都對齊了實際上壓縮器里對位的早已錯位退網(wǎng)失敗后需要很長時間才能追查到位移誤差。想盡量避免這個問題必須做好兩件事。第一在網(wǎng)表或RTL里給SE加同步邏輯讓它和測試時鐘域保持確定的時序關(guān)系第二在STA和ATPG約束里把SE聲明成偽靜態(tài)信號case analysis為0或1禁止工具在Shift和Capture交界處對SE做不合理的時序假設(shè)。3.3 多時鐘域下的跨域Launch與Capture能測才測不能測就約束住一個復(fù)雜SoC里往往有多個異步時鐘域CPU、總線、外設(shè)、模擬模塊各自跑各自的頻率。這種情況下ATPG對launch與capture的處理要比單時鐘域復(fù)雜得多。如果兩個時鐘域之間沒有確定的相位關(guān)系那么一個時鐘域的launch沿和另一個域的capture沿之間的間隔就不是固定值。此時如果ATPG強(qiáng)行跨域做launch-capture測試結(jié)果不但不可復(fù)現(xiàn)甚至連仿真故障模擬都會出現(xiàn)海量的未知態(tài)。標(biāo)準(zhǔn)做法是在工具里把異步時鐘定義成不同的時鐘組讓ATPG默認(rèn)不測跨域路徑或只做靜態(tài)stuck-at測試。如果兩個時鐘域之間存在同步器或FIFO且約束明確可以把它們放進(jìn)同一個時鐘組允許ATPG生成跨域transition pattern。這里我想特別提醒一點跨時鐘域路徑在覆蓋率報告里不應(yīng)該被簡單當(dāng)成“可測但未覆蓋”。如果大量跨域路徑因為異步關(guān)系被排除在測試之外需要評估它們對應(yīng)的功能路徑是否由其他機(jī)制比如系統(tǒng)級測試、軟件自檢兜底。否則這里的“漏測”會成為一個長期隱患尤其是芯片量產(chǎn)之后出現(xiàn)特定的耦合失效時很難用常規(guī)掃描pattern定位。3.4 在WGL和STIL文件里“看見”launch與capture而不是只靠工具生成的波形圖如果有機(jī)會直接打開ATE的WGL或STIL測試向量文件就會發(fā)現(xiàn)launch和capture的時序最終會落到具體的Timing和Waveform定義里。WGL里會為每個測試時鐘定義若干個波形形狀比如Shift的時鐘可能是普通方波而Launch和Capture常常被定義成帶絕對偏移的沿。偏移值一般是用ns為單位寫死的比如“Launch沿在t10ns處上升Capture沿在t20ns處上升”。如果這些偏移值和SDC里定義的時鐘周期不一致ATE上就會看到測試時間很短但良率下降、或過測變多。我平時會習(xí)慣直接在WGL/STIL文件里搜索波形定義反查每個launch/capture沿對應(yīng)的絕對時刻然后再對應(yīng)到std cell仿真波形上做交叉檢查。這個過程看起來繁瑣但對多時鐘域設(shè)計特別有效——曾經(jīng)有一塊芯片因為兩個時鐘域在WGL中的launch偏移互相差了一個shift周期仿真全過上機(jī)后stuck-at都穩(wěn)定唯獨transition pattern忽好忽壞最后就是靠逐行檢查STIL的Timescale才定位到問題。4. ATPG配置與EDT壓縮從工具側(cè)把Launch/Capture真正落地4.1 ATPG里最常調(diào)的那些Launch/Capture相關(guān)選項把設(shè)計網(wǎng)表讀進(jìn)ATPG工具之后真正決定launch和capture起源的是幾個看起來不起眼的配置點。第一是pattern類型。如果跑的是transition故障需要在工具里明確launch-off-capture或launch-off-shift。工具對這兩類pattern生成的內(nèi)部時序模板完全不一樣。第二是capture周期數(shù)。Transition fault測試默認(rèn)是兩拍但有些自定義故障模型可能需要更多捕獲周期這里要謹(jǐn)慎修改。第三是時鐘組定義。多個異步時鐘域必須分到不同的組工具才會自動把跨域路徑從launch/capture時序分析范圍里排除。另一個容易被忽略的是掃描單元庫里的觸發(fā)沿屬性。有些庫里的觸發(fā)器是上升沿觸發(fā)有些是下降沿觸發(fā)還有少數(shù)混合了兩種沿。ATPG生成的launch和capture沿必須根據(jù)實際情況映射到正確的極性否則就會出現(xiàn)我在開頭提到的那個案例——工具默認(rèn)把launch放在下降沿可設(shè)計的觸發(fā)沿在上升沿整體錯位。建議在每次跑ATPG之前先花半小時檢查一下時鐘信息報告看看工具理解到的launch沿和capture沿是否和你預(yù)想的一致。這比跑完幾百輪pattern之后再去查數(shù)據(jù)異常要劃算得多。4.2 “scan鏈過長EDT會覆蓋不到嗎”真實項目里的完整分析和排查路徑關(guān)于EDT和長掃描鏈的關(guān)系網(wǎng)上的說法其實很混亂。先給一個比較嚴(yán)謹(jǐn)?shù)慕Y(jié)論EDT的故障覆蓋率本身不會因為掃描鏈變長而直接下降但鏈長會顯著影響shift周期數(shù)從而改變pattern的加載/卸載效力和測試時間。真正的風(fēng)險不是“覆蓋不到”而是“效率流逝”和“數(shù)據(jù)在長鏈上被壓壞”。EDT內(nèi)嵌確定性測試的核心價值在于芯片內(nèi)部的大量掃描鏈可以并行移位外部只需少數(shù)幾個測試通道。每條鏈的長度決定了單個pattern需要多少個shift周期。假設(shè)一條鏈有3000個觸發(fā)器那么每個pattern必須經(jīng)過至少3000個shift周期才能完成一次load/unload。如果鏈與鏈之間的長度差異特別大短的鏈只能空等測試時間就被最長鏈鎖死。如果發(fā)現(xiàn)覆蓋率上不去或pattern數(shù)異常膨脹我的排查路徑一般是這樣的。先看EDT報告里的channel utilization——也就是每個外部通道是否都塞滿了有效數(shù)據(jù)如果利用效率低很多周期都在傳輸無效位鏈的均衡性就要重新評估。再跑一個簡單的chain test確認(rèn)每條長鏈上的數(shù)據(jù)能否完整、無沖突地load/unload——這一環(huán)節(jié)最常見的失敗是鏈上出現(xiàn)了未知態(tài)這些未知態(tài)一旦進(jìn)入EDT壓縮器會污染同一通道內(nèi)其他鏈的數(shù)據(jù)。最后再檢查end-of-chain的掩碼配置確認(rèn)長鏈末端的掃出數(shù)據(jù)沒有被壓縮邏輯吃掉。4.3 X態(tài)污染EDT壓縮器對launch/capture沿上不定態(tài)的反應(yīng)EDT壓縮器的存在讓測試通道數(shù)大幅減少但也帶來了一個新的敏感點它對X態(tài)異常敏感。在launch沿或capture沿附近出現(xiàn)的任何X態(tài)——比如未初始化的觸發(fā)器、被異步復(fù)位釋放的寄存器、被時鐘門控蓋掉的路徑——都會通過壓縮網(wǎng)絡(luò)傳播到觀測端把其他并行鏈里原本有效的觀測數(shù)據(jù)也覆蓋成未知。這在很多實際項目里表現(xiàn)為故障注入率正常覆蓋率卻突然掉頭或同一組pattern在幾個批次芯片上觀測到的失效不一致。定位方法也比較固定把捕捉到的響應(yīng)和仿真器的“無故障響應(yīng)”做比對找出哪些通道數(shù)據(jù)被X態(tài)污染再反推出污染源所在時鐘域或信號組。要徹底解決光靠ATPG的X態(tài)屏蔽功能還不夠更重要的是在設(shè)計階段就把異步邏輯約束好。比如復(fù)位信號必須在測試模式下同步化跨時鐘域的握手信號不能在alpha測試窗口內(nèi)產(chǎn)生跳變。DFT約束多花一份心后面測試階段就能少掉一大半不可重復(fù)的怪問題。5. 實測排錯心得三個讓我花掉整整一周的坑5.1 門控時鐘被旁路后launch沿直接丟了有一塊低功耗SoCRTL里用了大量集成時鐘門控單元。ATPG跑出來的transition覆蓋率挺不錯但故障模擬時總有零星的fail而且fail的位置不固定今天是這條鏈明天又是另一條鏈?；撕荛L時間才發(fā)現(xiàn)問題出在測試模式下時鐘門控被旁路的處理方式上——旁路使能信號是異步的導(dǎo)致某些觸發(fā)器在launch沿來臨時時鐘門控還在關(guān)閉狀態(tài)時鐘根本沒有到達(dá)時鐘端。這個案例帶給我最大的收獲是launch沿是否真的“到達(dá)”了每個觸發(fā)器的時鐘端必須依靠門控時鐘的測試約束來保證而不是默認(rèn)工具能處理好一切。后來我在所有關(guān)鍵門控單元上都加了test mode enable信號并在SDC里把門控旁路路徑聲明為測試專用路徑問題才徹底消失。5.2 LOC覆蓋率卡在91%上不去問題出在初始狀態(tài)無法構(gòu)造另一個項目里某CPU域的transition fault覆蓋率卡在91%左右怎么加pattern都紋絲不動。查了未覆蓋故障分類發(fā)現(xiàn)大量故障的激活條件需要觸發(fā)器的初始狀態(tài)為“某一特定向量組合”而在LOC模式下launch沿的初始狀態(tài)是由上一輪capture結(jié)果決定的無法像LOS那樣由掃描輸入精確指定。針對這批路徑我換了一種思路只用LOS模式生成了一組針對性的pattern單獨覆蓋這條邏輯子集。覆蓋率順利突破95%測試時間也沒有增加太多。這件事告訴我LOC和LOS不是什么“二選一”的對立關(guān)系而是可以取長補(bǔ)短的兩個工具。覆蓋率出現(xiàn)瓶頸時先看故障分類再決定要不要引入第二種launch策略。5.3 復(fù)位信號的不定態(tài)污染了整個EDT壓縮輸出最后一個案例比較隱蔽。EDT壓縮器的觀測輸出在低電壓和高溫條件下總出現(xiàn)不一致看上去像壓縮器硬件出了問題。排查到最后發(fā)現(xiàn)真正的元兇是某些寄存器的異步復(fù)位信號在capture窗口附近恰好被釋放復(fù)位釋放的瞬間產(chǎn)生了一個X態(tài)經(jīng)過兩級組合邏輯傳到EDT壓縮器里干擾了同通道好幾位有效數(shù)據(jù)。從那以后我在設(shè)計DFT測試規(guī)格的時候?qū)λ袕?fù)位信號都做了一個鐵律測試模式下復(fù)位釋放必須由同步邏輯產(chǎn)生禁止直接在capture窗口附近異步釋放。同時會在ATPG里針對這類路徑做X態(tài)屏蔽。如果設(shè)計已經(jīng)流片無法修改就只能用工具層約束兜底但代價是覆蓋率會有所損失。一些寫在最后的個人體會這些年接觸過不少掃描測試相關(guān)的項目我最大的感受是Launch與Capture機(jī)制聽起來是ATPG工具里的一個普通配置但它牽扯到的鏈條遠(yuǎn)比想象中長——從DFT架構(gòu)設(shè)計、SDC時序約束、后端時鐘樹一路延伸到ATE上的WGL/STIL時序定義和EDT壓縮配置。任何一個環(huán)節(jié)對“兩個沿”的理解有偏差最后都會以測試數(shù)據(jù)異常的形態(tài)出現(xiàn)在你面前。如果你正準(zhǔn)備開始跑transition pattern我的建議是先別急著生成海量向量而是花半天時間把你設(shè)計里所有時鐘域在launch和capture沿上的行為畫清楚確認(rèn)SE信號在每個沿附近的時序再打開門控時鐘的測試約束檢查一遍。這套動作看起來很基礎(chǔ)但它能幫你省掉后面無數(shù)個查詢“為什么覆蓋率不達(dá)標(biāo)”的深夜。等這套基礎(chǔ)打扎實了你會發(fā)現(xiàn)LOS、LOC、EDT、X態(tài)屏蔽這些更高級的話題其實都只是Launch與Capture機(jī)制的延伸和擴(kuò)展。