1. 從一塊“跑不起來”的芯片說起保持時間違例為什么是個隱形殺手我做了十多年數(shù)字IC后端設(shè)計見過太多這樣的場景前端RTL仿真一切正常綜合后的網(wǎng)表看起來也沒什么問題結(jié)果流片回來之后芯片要么完全無法工作要么在特定溫度、特定電壓下隨機性地出故障。更讓人頭疼的是這種故障往往不是靠降頻就能解決的——你把時鐘頻率從1GHz降到100MHz問題依舊存在仿佛芯片在跟你較勁。類似的案例在行業(yè)里并不少見甚至有工程師戲稱芯片設(shè)計里有“兩大玄學(xué)”——復(fù)位釋放有問題和保持時間違例。前者通常還能靠調(diào)整復(fù)位時序補救后者一旦流片回來才發(fā)現(xiàn)基本就是整批芯片報廢的結(jié)局。今天的文章我想把保持時間違例hold time violation這個問題掰開揉碎說說它為什么會成為芯片設(shè)計中最“致命”的時序問題以及在實際工程中我們是怎么定位、分析和修復(fù)這類問題的。無論你是剛開始接觸數(shù)字IC設(shè)計的學(xué)生還是已經(jīng)在芯片后端、DFT、驗證崗位工作的工程師理解保持時間違例的本質(zhì)都能幫你在項目中少踩一個大坑。畢竟建立時間違例還能靠降頻救回來保持時間違例是真的會把芯片“毀”掉的。2. 建立時間與保持時間的本質(zhì)區(qū)別為什么一個能救、一個不能救想搞清楚保持時間違例的殺傷力我們得先把時序分析中最基礎(chǔ)的兩個概念講透建立時間setup time和保持時間hold time。很多初學(xué)者會把它們混為一談但實際上這兩者在芯片設(shè)計中地位完全不同。2.1 建立時間數(shù)據(jù)要“提前到”的約定建立時間setup time指的是在時鐘有效沿到來之前數(shù)據(jù)信號必須提前穩(wěn)定下來的最短時間。通俗地講就像你趕高鐵列車發(fā)車時鐘沿之前你必須已經(jīng)檢票進站數(shù)據(jù)穩(wěn)定進站這個動作需要提前多久完成這個提前量就是建立時間。在靜態(tài)時序分析STA里我們檢查的是數(shù)據(jù)從上級觸發(fā)器FF1的時鐘沿出發(fā)經(jīng)過組合邏輯的傳播延遲到達下級觸發(fā)器FF2的數(shù)據(jù)輸入端口之后這個數(shù)據(jù)能否在下一個時鐘沿到來之前提前Tsetup時間穩(wěn)定下來。如果數(shù)據(jù)到達得太晚也就是數(shù)據(jù)路徑延遲太大就會產(chǎn)生建立時間違例。關(guān)鍵點來了建立時間違例發(fā)生時如果這個設(shè)計不是特別極端你通?？梢酝ㄟ^降低時鐘頻率來“救回來”。為什么因為建立時間的約束里包含時鐘周期Tclk你把Tclk拉長給數(shù)據(jù)路徑上多留一點時間數(shù)據(jù)就能在下一個時鐘沿前穩(wěn)定下來了。頻率降低系統(tǒng)變慢但至少能工作。2.2 保持時間數(shù)據(jù)要“賴著不走”的約定保持時間hold time指的是在時鐘有效沿到來之后數(shù)據(jù)信號必須繼續(xù)保持穩(wěn)定的最短時間。繼續(xù)用高鐵的類比發(fā)車之后你仍然需要待在車廂里一段時間而不是剛上車就跳下去這個必須“賴在車上”的持續(xù)時間就類似于保持時間。在靜態(tài)時序分析中保持時間的檢查方式和建立時間有個本質(zhì)區(qū)別它檢查的是同一個時鐘沿。也就是說當FF2的時鐘沿到達時FF1在這個時鐘沿發(fā)射的數(shù)據(jù)不能太快地傳播到FF2的數(shù)據(jù)端口并把它“沖掉”。如果數(shù)據(jù)路徑的延遲太短——注意是太短——數(shù)據(jù)在FF2的保持時間窗口內(nèi)就發(fā)生了變化就會導(dǎo)致FF2采到不確定的值。2.3 為什么降頻救不了保持時間違例這是整個問題的核心也是很多初入行的工程師最容易想不通的地方。我們來看保持時間檢查的計算公式數(shù)據(jù)到達時間 時鐘偏斜clock skew 數(shù)據(jù)路徑延遲clock-to-Q 組合邏輯延遲數(shù)據(jù)要求時間 時鐘周期 時鐘偏斜 保持時間hold time化簡之后你會發(fā)現(xiàn)時鐘周期Tclk在等式中被抵消了。也就是說保持時間違例的檢查結(jié)果和時鐘頻率沒有任何關(guān)系。你把時鐘從1GHz降到10MHz保持時間違例照樣存在因為問題根本不在于數(shù)據(jù)來得“太慢”而在于數(shù)據(jù)變得“太快”——上一個時鐘沿采到的數(shù)據(jù)還沒來得及被保存就被下一個沿的發(fā)射數(shù)據(jù)覆蓋了。打個更直觀的比方保持時間違例就像你用相機連拍上一張照片還沒存進內(nèi)存卡下一張照片的數(shù)據(jù)就已經(jīng)把緩存沖掉了無論你把連拍速度調(diào)得多慢降頻只要“上一張存入內(nèi)存卡”這個動作本身比“下一張數(shù)據(jù)到達”更慢問題就一直存在。2.4 保持時間違例的“不可預(yù)測性”是它更可怕的地方建立時間違例通常表現(xiàn)為功能完全錯誤或者在某些極端工況下出現(xiàn)固定模式的邏輯錯誤——這至少是可復(fù)現(xiàn)的、可定位的。但保持時間違例的表現(xiàn)形式要狡猾得多。我曾經(jīng)遇到過一個案例芯片在實驗室里做功能測試時某些板子跑得好好的某些板子一上電就報錯同一塊板子今天測試通過明天又不通過溫度升高之后問題消失溫度降下來問題又出現(xiàn)。排查了很久最后定位到是一小段關(guān)鍵路徑的保持時間違例在作怪。原因在于保持時間違例是否真正觸發(fā)功能錯誤取決于數(shù)據(jù)路徑上信號的競爭-冒險race結(jié)果。如果數(shù)據(jù)路徑延遲剛好略小于保持時間要求那么采到錯誤數(shù)據(jù)的概率就取決于PVT工藝、電壓、溫度波動、電源噪聲、時鐘抖動等一系列因素。這種“看心情”出錯的故障在調(diào)試階段簡直是噩夢。3. 保持時間違例在芯片物理實現(xiàn)中的真實成因既然保持時間違例這么可怕它在實際項目中是怎么產(chǎn)生的呢我總結(jié)了一下主要有四大來源。3.1 時鐘偏斜最經(jīng)典的“幫兇”時鐘偏斜clock skew指的是同一個時鐘信號到達不同觸發(fā)器的時刻不一致。在芯片物理實現(xiàn)中時鐘樹綜合CTS之后時鐘到達每個觸發(fā)器的路徑長度不同就會產(chǎn)生偏斜。為了理解時鐘偏斜對保持時間的影響我們需要關(guān)注一個有意思的現(xiàn)象偏移對建立時間和保持時間的影響方向是相反的。對建立時間如果FF2的時鐘比FF1的時鐘晚到正偏斜那么FF2的建立時間要求實際上被放寬了——因為下一個時鐘沿更晚來數(shù)據(jù)有更多時間可以傳播。對保持時間同樣這個正偏斜卻讓FF2的保持時間要求變嚴格了——因為同一個時鐘沿也更晚到達FF2FF1發(fā)射的數(shù)據(jù)有更多時間沖到FF2的數(shù)據(jù)端口。所以在時鐘樹綜合階段我們既要控制全局偏斜global skew又要關(guān)注局部偏斜local skew尤其是時序關(guān)系緊密的相鄰觸發(fā)器之間的偏斜。如果你在時鐘樹設(shè)計時只盯著建立時間優(yōu)化忽略了局部偏斜對保持時間的影響后期就會很被動。3.2 數(shù)據(jù)路徑“過短”被低估的風險如果說時鐘偏斜是“幫兇”那么數(shù)據(jù)路徑延遲過短就是保持時間違例的“主犯”。很多人覺得自己設(shè)計的組合邏輯鏈路挺長的不太可能出現(xiàn)延遲過短的問題但實際上在高性能芯片中很多數(shù)據(jù)路徑就是純粹的寄存器到寄存器register-to-register直連中間只有兩級Buffer甚至只有一條金屬走線。這類短路徑的延遲通常在幾十到幾百皮秒ps量級而標準單元庫中觸發(fā)器的保持時間要求通常在幾十ps到一兩百ps之間。聽起來好像延遲夠了別忘了我前面說的還要考慮時鐘偏斜、工藝角變化、片上波動OCV等因素。在慢工藝角下數(shù)據(jù)路徑延遲和時鐘路徑延遲的比值會發(fā)生變化可能就差那么幾十ps保持時間就違例了。尤其是在使用了大量流水線結(jié)構(gòu)的設(shè)計中相鄰觸發(fā)器之間幾乎沒有任何組合邏輯這種結(jié)構(gòu)的保持時間風險會被顯著放大。3.3 信號完整性與串擾Crosstalk的“時間偷竊”到了先進工藝節(jié)點28nm以下信號完整性問題對保持時間的影響越來越不可忽視。相鄰走線之間的耦合電容會在信號翻轉(zhuǎn)時產(chǎn)生串擾噪聲這種噪聲表現(xiàn)為兩種情況受害網(wǎng)絡(luò)victim net被攻擊網(wǎng)絡(luò)aggressor net同向跳變“推了一把”導(dǎo)致信號提前到達或延后到達受害網(wǎng)絡(luò)被反向跳變“拉了一把”信號出現(xiàn)毛刺或延遲增大。對于保持時間檢查我們最關(guān)心的是“數(shù)據(jù)提前到達”的情況——因為保持時間違例的本質(zhì)就是數(shù)據(jù)變得太快。如果一根數(shù)據(jù)線上的信號因為串擾被提前了幾個皮秒到達觸發(fā)器在原本已經(jīng)逼近極限的保持時間余量上這“幾個皮秒”可能就成了壓死駱駝的最后一根稻草。3.4 工藝角與OCV簽核中的“放大鏡”在簽核signoff階段我們用靜態(tài)時序分析工具檢查保持時間時會考慮不同的工藝角process corner、電壓和溫度組合。對于保持時間檢查最惡劣的情況通常出現(xiàn)在快速工藝角FF corner快速工藝角下晶體管的閾值電壓偏低、溝道長度偏短晶體管開關(guān)速度更快數(shù)據(jù)路徑延遲變小保持時間違例風險增大。高電壓、低溫也會讓晶體管速度變快進一步壓縮數(shù)據(jù)路徑延遲。片上波動OCV同一顆芯片上不同位置的晶體管參數(shù)也存在偏差。對于保持時間檢查我們要考慮“數(shù)據(jù)路徑最快、時鐘路徑最慢”這個最悲觀組合也就是我們常說的“l(fā)ate clockearly data”。這也是為什么在先進工藝下保持時間修復(fù)要留出足夠的時序余量margin不能算得太“精打細算”。在簽核階段我們通常會在保持時間檢查里額外加一個derate factor比如1.1倍把這個悲觀組合的效應(yīng)量化出來。4. 保持時間違例的修復(fù)手段ECO中的“三板斧”如果流片前通過靜態(tài)時序分析發(fā)現(xiàn)了保持時間違例那算是萬幸因為我們還有修復(fù)的機會。在實際項目中保持時間違例通常在布局布線后的時序收斂階段被發(fā)現(xiàn)這時候修改RTL已經(jīng)不太現(xiàn)實我們主要依靠工程變更單ECO手段來修復(fù)。業(yè)內(nèi)針對保持時間違例的修復(fù)方案其實非常固定我用“三板斧”來概括。4.1 第一板斧插入延遲Buffer這是最經(jīng)典、最直接的保持時間違例修復(fù)手段。原理非常簡單在數(shù)據(jù)路徑上插入一個或多個Buffer人為地增加數(shù)據(jù)到達FF2的時間。具體操作是找到保持時間違例的端點endpoint在它的數(shù)據(jù)輸入路徑上插入一個延遲適當?shù)腂uffer然后重新跑靜態(tài)時序分析驗證。聽起來簡單但實際做起來有不少門道Buffer的選型很有講究。標準單元庫里通常有不同驅(qū)動強度、不同延遲特性的Buffer有的Buffer專門為延遲優(yōu)化而設(shè)計delay buffer有的則是普通的平衡Buffer。修復(fù)保持時間違例時優(yōu)先選用延遲特性好、本身延遲對工藝偏差不敏感的Buffer單元。有些工藝庫還提供了專門的delay cell內(nèi)部串聯(lián)了電阻電容結(jié)構(gòu)延遲更穩(wěn)定。插入位置也有講究。很多人想當然地認為把Buffer插在靠近目的地FF2的位置效果最直接但實際上這樣做會增大該網(wǎng)絡(luò)的扇出和負載可能導(dǎo)致上游驅(qū)動能力不足。比較穩(wěn)妥的做法是在數(shù)據(jù)路徑的中段找一個信號完整性較好的位置插入同時注意不要引入新的布線擁塞。還有一個容易被忽略的問題插入Buffer之后它本身也成為了時鐘樹上的負載可能會影響周圍的時序收斂。所以做完修復(fù)后一定要跑全局時序收斂而不是只看局部。4.2 第二板斧調(diào)整時鐘偏斜既然時鐘偏斜是保持時間違例的重要成因那么反向操作——通過調(diào)整時鐘路徑延遲來改善保持時間也是一種思路。具體做法是在保持時間違例的路徑上給FF2的時鐘路徑增加延遲讓時鐘沿到達FF2的時間往后推這樣FF1發(fā)射的數(shù)據(jù)就有更多時間可以“通過并穩(wěn)定下來”相當于變相滿足了FF2的保持時間要求。聽起來很完美對不對但這里有個潛在問題增加FF2時鐘路徑的延遲會讓FF2到下一級觸發(fā)器的建立時間變緊張——因為你同時推遲了FF2的數(shù)據(jù)發(fā)射時間。所以調(diào)整時鐘偏斜本質(zhì)上是個“拆東墻補西墻”的操作必須在局部建立時間和保持時間之間找到平衡。在實際項目中我們只有在插入Buffer實在沒有空間、或者插入Buffer會引發(fā)擁塞問題時才會考慮這個手段。而且修改時鐘樹的風險比插Buffer大得多因為時鐘網(wǎng)絡(luò)是全局性的牽一發(fā)而動全身。4.3 第三板斧調(diào)整單元尺寸與邏輯結(jié)構(gòu)有時候保持時間違例的根源是數(shù)據(jù)路徑上的某些單元驅(qū)動能力過強導(dǎo)致信號傳播太快。此時可以考慮把路徑上的某些Buffer或邏輯門更換為驅(qū)動能力更弱尺寸更小的版本從而降低信號翻轉(zhuǎn)速度、增加延遲。不過這種操作在深度物理實現(xiàn)階段已經(jīng)比較少見因為改變單元尺寸可能導(dǎo)致布局和布線的大幅調(diào)整ECO成本較高。更多時候我們是通過綜合階段的約束來預(yù)防——比如在綜合時對關(guān)鍵短路徑設(shè)置hold margin讓綜合工具在優(yōu)化階段就主動插入延遲單元。說到底保持時間違例的修復(fù)最佳策略從來都是“防大于治”。在綜合階段就對時鐘樹結(jié)構(gòu)和短路徑傳播有前瞻性的規(guī)劃遠比后期在布局布線上打補丁要高效得多。4.4 一個實際的修復(fù)案例我之前做過一個項目一顆SoC芯片在簽核階段連續(xù)報出來十幾個保持時間違例全部集中在一條高速總線的接收端。最嚴重的一條路徑保持時間余量為-0.27ns負的0.27納秒這在后端設(shè)計中已經(jīng)屬于相當嚴重的違反了。當時我們第一步是打開時序報告分析違例路徑的詳細信息。報告中顯示這條路徑的數(shù)據(jù)路徑延遲只有0.43ns而FF2的保持時間要求是0.7ns——數(shù)字本身就很清楚地說明了問題數(shù)據(jù)路徑太短數(shù)據(jù)到達得太早。時鐘偏斜的分析也確認了FF2的時鐘比FF1早到了0.1ns進一步惡化了保持時間余量。我們當時的修復(fù)方案是在這條數(shù)據(jù)路徑上插入一個延遲約為0.3ns的delay buffer。選型時對比了標準Buffer和專用delay cell的延遲特性曲線最終選擇了對電壓波動不那么敏感的delay cell。插入之后重新布線、重新提取寄生參數(shù)、重新做時序簽核最終保持時間余量變成了0.05ns雖然余量不大但對于這類短路徑來說已經(jīng)可以接受了。這里也分享一個我踩過的坑一開始圖省事直接選了延遲最大的buffer結(jié)果插入后發(fā)現(xiàn)該網(wǎng)絡(luò)上的負載暴增上游驅(qū)動單元出現(xiàn)了transition違例連帶影響了周邊好幾條路徑的時序。所以修復(fù)保持時間違例時插入Buffer的延遲值寧小勿大加了之后多跑幾輪收斂不要指望一步到位。5. 如何準確分析保持時間違例從時序報告到簽核策略分析保持時間違例是所有芯片后端工程師的基本功。這里我詳細說下實際工作中的操作流程和關(guān)鍵細節(jié)。5.1 讀懂保持時間檢查的時序報告以Synopsys PrimeTimePT為例保持時間違例的時序報告通常包含以下關(guān)鍵信息報告項說明檢查重點Startpoint發(fā)射數(shù)據(jù)的起點通常是上級觸發(fā)器確認路徑起點是否正確Endpoint接收數(shù)據(jù)的終點發(fā)生違例的觸發(fā)器確認違例位置Launch Clock Path發(fā)射時鐘路徑延遲關(guān)注時鐘偏斜方向Capture Clock Path捕獲時鐘路徑延遲與發(fā)射時鐘對比Data Path Delay數(shù)據(jù)路徑總延遲判斷是否“過短”Hold Requirement保持時間要求值由庫文件和時鐘關(guān)系決定Slack時序余量負值即違例實操中我有個習慣拿到時序報告先看Slack的數(shù)值大小如果只是-0.01ns到-0.05ns這種小違例通常可以通過微調(diào)OCV derate或優(yōu)化時鐘樹來修復(fù)如果超過-0.1ns就要認真考慮插入Buffer了。同時我會特別關(guān)注報告里的時鐘偏斜數(shù)值如果發(fā)現(xiàn)FF2的時鐘比FF1早到很多負偏差那即使數(shù)據(jù)路徑不算太短保持時間也可能違例——這時候修復(fù)時鐘樹可能比插Buffer更有效。5.2 簽核策略用“笨辦法”保證安全從我的經(jīng)驗來看處理保持時間違例寧可簽核時“保守”一點也不要過分追求工藝極限。很多團隊在建立時間的簽核上已經(jīng)積累了豐富的經(jīng)驗但在保持時間簽核上容易掉以輕心覺得反正是個“短路徑”問題不會有太大影響。但實際上保持時間違例一旦流入量產(chǎn)階段造成的經(jīng)濟損失遠比建立時間違例嚴重。我的建議是在項目規(guī)劃階段就定好幾條保持時間簽核的“鐵律”在所有工藝角、電壓、溫度組合下都跑保持時間檢查尤其是FF corner、高電壓、低溫這個組合。對OCV derate保持一個合理的悲觀度不要為了讓時序“看起來過了”而無腦調(diào)小derate factor。在保持時間檢查中加入對時鐘抖動clock jitter的悲觀估計。對高速接口、異步處理單元等關(guān)鍵模塊額外增加保持時間余量約束。5.3 利用有用的時鐘偏斜useful skew前面提到時鐘偏斜對保持時間有負面影響但反過來如果處理得當時鐘偏斜也可以成為我們的工具——這就是“有用偏斜”的概念。當一條路徑的建立時間余量非常充裕、但保持時間余量緊張時我們可以人為地讓FF2的時鐘比FF1早到一點點負偏斜這樣FF2的捕獲沿更早到來留給數(shù)據(jù)的保持窗口也就更寬松。這個操作在時鐘樹綜合時可通過對特定單元的延遲約束來實現(xiàn)但這需要全局視角因為FF2的時鐘早到會犧牲它自己作為發(fā)射端時的建立時間預(yù)算。6. 保持時間違例的“三坑”實錄那些讓我銘記至今的故障排查前面講的都是理論和方法最后我想分享幾個真實的故障排查案例讓大家直觀感受一下保持時間違例在工程中的真實面貌。6.1 競態(tài)條件造成的“薛定諤的故障”這是我最早期遇到的一個案例。一顆MCU芯片在做系統(tǒng)級測試時偶爾會出現(xiàn)UART串口數(shù)據(jù)錯亂。我們用邏輯分析儀抓波形發(fā)現(xiàn)數(shù)據(jù)完全不符合協(xié)議規(guī)范但又不是完全無輸出。排查了很久最后懷疑到時鐘上。通過掃描鏈測試和診斷我們定位到UART接收模塊的一個關(guān)鍵FIFO寫指針觸發(fā)器存在保持時間違例。問題出在UART模塊的時鐘是分頻產(chǎn)生的分頻器輸出時鐘與系統(tǒng)時鐘之間的相位關(guān)系不固定導(dǎo)致時鐘偏斜在某個特定相位組合下突破了保持時間容忍極限。這個案例給我的教訓(xùn)是不要只盯著系統(tǒng)主時鐘路徑上的保持時間分頻時鐘、門控時鐘、多路選擇時鐘clock mux這些特殊時鐘路徑上的保持時間檢查往往才是真正的雷區(qū)。6.2 “降頻仍然死機”的經(jīng)典案例另一個案例來自一顆工業(yè)控制芯片?？蛻舴答佌f芯片在某些溫度下穩(wěn)定工作在另一些溫度下頻繁死機。我們嘗試把所有頻率都降到最低檔死機問題依舊。當時團隊里已經(jīng)有人開始懷疑是芯片本身制造缺陷了。后來通過定位我們發(fā)現(xiàn)是某條復(fù)位信號釋放路徑上的保持時間違例。復(fù)位釋放時復(fù)位信號與時鐘沿的時序關(guān)系不滿足觸發(fā)器的保持時間要求導(dǎo)致部分觸發(fā)器在復(fù)位釋放后采到了不確定值。這種問題跟主時鐘頻率完全無關(guān)自然降頻沒用。而且因為復(fù)位信號的傳播路徑和時鐘樹的偏差隨溫度變化所以不同溫度下故障表現(xiàn)不一樣。修復(fù)方式是在復(fù)位釋放路徑上插入延遲單元同時在復(fù)位釋放邏輯里增加同步處理確保復(fù)位信號與時鐘沿之間有足夠的時序余量。6.3 異步FIFO跨時鐘域的灰色地帶最后一個案例來自一個包含多個時鐘域的大型SoC。我們在異步FIFO的跨時鐘域邊界上用格雷碼做同步理論上是安全的。但在一次低溫測試中偶爾會出現(xiàn)數(shù)據(jù)亂序。排查后發(fā)現(xiàn)格雷碼雖然可以保證多個比特不會同時變化但格雷碼路徑本身在跨時鐘域同步時如果同步器的兩個觸發(fā)器之間存在保持時間違例——尤其是格雷碼信號在快時鐘域到慢時鐘域的傳輸過程中——依然可能出現(xiàn)亞穩(wěn)態(tài)傳播。我們原本以為“格雷碼兩級同步器”就萬無一失了但實際分析后才發(fā)現(xiàn)正是保持時間違例給了亞穩(wěn)態(tài)“可乘之機”。后來的修復(fù)措施除了在跨時鐘域路徑上做嚴格的保持時間約束和插入Buffer外我們還把所有跨時鐘域路徑在約束文件里顯式標記為false path僅對單比特控制信號同時對多比特信號強制使用握手協(xié)議或異步FIFO結(jié)構(gòu)從根上杜絕了這類問題。這幾個案例雖然場景不同但都有一個共同點保持時間違例總是以最不顯眼、最難復(fù)現(xiàn)的方式出現(xiàn)。等到它在量產(chǎn)后大規(guī)模爆發(fā)時一切就都晚了芯片在這個環(huán)節(jié)上一旦設(shè)計失誤就沒有“軟件升級”這種補救的概念了——這才是它真正“毀掉”芯片的方式。7. 寫在最后我的一點實戰(zhàn)心得跟保持時間違例打了這么多年交道我的核心體會是保持時間違例不是那種“等你遇到了再解決”的問題它必須在設(shè)計流程中前置預(yù)防。如果你正在做芯片后端設(shè)計建議在每一版netlist落地之后第一件事就是用靜態(tài)時序分析跑一遍保持時間檢查尤其是對短路徑、高速接口、跨時鐘域路徑這些區(qū)域哪怕暫時不做修復(fù)也要對違例數(shù)量和分布有清晰的認知。另外一個很實用的習慣是每次做ECO修復(fù)保持時間違例時順手記錄一下插入Buffer的類型、位置和延遲值。長期積累下來你就會對芯片的“體質(zhì)”有一個直覺——哪種單元庫的delay cell在這個工藝角下最穩(wěn)定、哪類路徑最容易出現(xiàn)保持時間問題、時鐘樹上的哪些位置適合做useful skew調(diào)整。這些經(jīng)驗遠不是只看幾本教科書就能獲得的。芯片設(shè)計是一場成本極高的賭博每一顆流片回來的芯片都承載著整個團隊的心血。保持時間違例雖然常常潛伏在不起眼的角落里但只要在設(shè)計階段給它足夠的重視它就完全是可以被馴服的。希望這篇文章能幫你在未來的項目中少走我走過的那些彎路。