做數字后端的人應該都有體會流片回來如果時鐘有問題整顆芯片基本就廢了。時序違例還能靠ECO補救時鐘偏斜如果控不住尤其是那種跨die的偏斜可能連基本功能都跑不起來。所以時鐘樹綜合CTS在整個數字后端流程里可以說是最考驗功力的環(huán)節(jié)之一。這篇筆記想聊的就是CTS里頭最核心的主角——時鐘信號本身從定義、參數到工具里的處理方式再到實際項目中常見的坑盡量一次說透。這篇內容適合剛接觸數字后端、準備跑第一個CTS的工程師也適合那些已經跑過幾步流程但對工具報告里的Jitter、Skew、Latency還一知半解的朋友。我會從概念講起但重點會放在工具實操和項目經驗上畢竟那些報告和命令才是每天要面對的東西。1. 內容整體設計與思路拆解1.1 為什么CTS在數字后端里地位這么特殊做數字后端的人常說一句話Floorplan是骨架Placement是血肉CTS是神經系統(tǒng)。前兩步把邏輯放對位置CTS則決定了這些邏輯之間能不能按時通信。舉一個很直觀的例子假設一個數據路徑源寄存器到目的寄存器的組合邏輯延遲只有2ns但是時鐘到達這兩個寄存器的時刻差了0.5ns。如果數據是時鐘上升沿發(fā)出、上升沿采到那這0.5ns會直接影響建立時間裕量。更麻煩的是如果在物理上離得很近的兩個寄存器因為時鐘路徑上負載不同出現了0.3ns的偏斜那數據路徑本來算好的時序就有可能在真實硅片上直接翻轉結果。這就是CTS存在的意義在物理上構建時鐘網絡把時鐘信號的到達時間差Skew控制到可接受范圍同時減小延遲Latency保證芯片能在一個合理的主頻下穩(wěn)定工作。我見過不少剛入行的同事覺得CTS無非是讓工具自動插buffer跑通就行。但實際上CTS的質量直接決定后續(xù)route的時序收斂難度也直接決定芯片能不能跑到目標頻率。工具默認參數確實可以跑出結果但那個結果通常是“能用”而不是“好用”。想要“好用”必須自己理解時鐘信號的特性并且愿意花時間去調。1.2 時鐘信號在芯片里的三種存在形態(tài)理解CTS之前先要清楚時鐘信號在芯片里是怎么演變的這決定了工具在各階段如何處理它。第一個階段是真實物理時鐘也就是從芯片外部PAD進來的時鐘或者由內部PLL產生的時鐘。這個時候的時鐘是真實存在的物理信號有RC延遲會受到工藝波動影響也是CTS要最終構建出來的對象。第二個階段是理想時鐘Ideal Clock。在綜合和布局階段工具假設時鐘到達每個寄存器的時間完全相同沒有延遲、沒有偏斜、沒有抖動。這時候做的STA靜態(tài)時序分析只是一個非常粗粒度的檢查只能用來排除明顯的邏輯問題不能用來做精確的時序收斂。所有數字后端工具在place階段都是按照理想時鐘來優(yōu)化邏輯只關注數據路徑的物理距離和擁塞情況。第三個階段是傳播時鐘Propagated Clock。CTS工具會用真實單元和真實繞線把時鐘網絡物理實現出來。時鐘從源頭到達各個寄存器走的是一條實實在在的RC網絡每一段都有延遲每個單元都有delay不同路徑之間的延遲差就是Skew。只有到了這個階段時序分析才真正貼近實際硅片的行為。這個演化過程想說明一件事CTS是把“理想”變?yōu)椤罢鎸崱钡姆炙畮X。在做CTS之前時序分析是虛的做完CTS之后時序分析才落地。這也是為什么業(yè)界常說CTS是數字后端最核心的環(huán)節(jié)之一。1.3 整篇筆記的內容走向接下來的章節(jié)我是這么安排的先從時鐘信號的參數定義講起幫你構建一個“什么是好的時鐘”的認知框架。然后深入到CTS的核心實現環(huán)節(jié)解析工具如何從無到有構建時鐘樹包括長中短時鐘樹的策略選擇。接著講實操層面的核心技術比如Skew Group、有用偏差、報告分析這些每天都要用的東西。最后是信號完整性和實際項目中的問題排查把那些“跑完就掛”的典型案例擺出來分析。這樣一條線走下來你既能理解CTS背后的邏輯也能在工具里實操落地。2. 核心概念時鐘信號的參數與質量衡量2.1 時鐘信號的三個核心參數Skew、Latency、Jitter圍繞時鐘信號有三個參數是天天要看的Skew、Latency、Jitter。它們分別刻畫了時鐘信號在“空間不一致性、時間延遲、瞬時波動”三個維度上的表現。Latency中文叫時鐘延遲指時鐘信號從源頭到達某個寄存器時鐘端的時間。它由兩部分組成Source Latency時鐘源到時鐘樹根節(jié)點的延遲包含片外走線或PLL內部延遲和Network Latency時鐘樹根節(jié)點到各寄存器端點的延遲。在物理設計里我們最頭疼的往往是Network Latency因為它直接受時鐘樹緩沖器級數和繞線長度影響。工具會在約束里給你一個target latency的期望但實際是否滿足取決于時鐘樹構建質量。Skew時鐘偏斜指同一時鐘域內時鐘信號到達各個寄存器的時間差。這個差的本質是不同路徑長度和負載不同導致的delay差。Skew是CTS要解決的頭號問題。假設一個時鐘域里有1萬個寄存器工具希望到達這1萬個寄存器的時鐘沿盡量對齊。但物理上這是不可能的因為位置有遠有近負載有大有小。工具能做的是把Skew壓制到一個足夠小的范圍內讓時序預算里的不確定性足夠低。Jitter時鐘抖動指時鐘信號在時域上每個周期的邊沿位置相對理想位置有微小隨機偏移。這個偏移來自PLL自身的噪聲、電源噪聲、串擾是物理世界無法消除的。Jitter在CTS階段通常作為外部約束輸入你沒法通過物理實現手段去消除它只能在時序分析時把它當作uncertainty的一部分扣除。從業(yè)這么多年我遇到過不少新人混淆這三個概念。其實有個很簡單的類比Latency像是公交車從總站到達某一站的時間Skew是不同站點的公交車到達時間差Jitter則是同一輛車每次到達同一站點的時間波動。CTS管的是Skew同時盡量壓低Latency而Jitter更多是設計架構和電源網絡的范疇。2.2 全局偏斜與局部偏斜哪個更重要Skew還有全局和局部之分這個區(qū)分在實際項目中非常關鍵。Global Skew是時鐘源到達時鐘域內所有寄存器端點的最大時間差。Local Skew則是時鐘源到達彼此有時序關系的兩個寄存器比如一條數據路徑上的源寄存器和目的寄存器的時間差。從時序分析的角度看Local Skew才是真正影響路徑時序的。因為一條時序路徑上只有兩個端點源寄存器和目的寄存器。它們之間的時鐘到達時間差直接影響這條路徑的建立和保持時間裕量。但是關鍵在于CTS工具優(yōu)化的主要目標通常是Global Skew因為讓所有葉子盡量對齊是最簡單、最robust的策略。這樣做的好處是對于任意一條路徑Local Skew的上限天然就被Global Skew限制住了不需要逐一分析。這種設計哲學很像“寧可同歸于盡也要絕對公平”——把時鐘偏差壓到全局統(tǒng)一換來時序穩(wěn)定。不過Global Skew壓得太低也是有代價的。把一片片上物理位置差距極大的寄存器都對齊到同一個時鐘邊沿意味著要為遠的寄存器插入更多buffer增加延遲和功耗也增加布線資源占用。所以實際項目中高扇出、大時鐘域一般不追求極致低的Global Skew而是追求“足夠好”的Local Skew。這一點后面講Skew Group的時候會再展開。2.3 從約束角度看時鐘定義是CTS的輸入前提CTS不是一個憑空的物理構建過程它的行為完全受約束驅動。時鐘定義不對后面做得再漂亮也是錯的。這里就涉及SDCSynopsys Design Constraints里的核心時鐘約束命令。用得最多的就是兩個create_clock和create_generated_clock。create_clock用于定義原始時鐘通常定義在芯片的輸入端口或者PLL輸出端口。它需要指定周期period、波形waveform還可以定義不確定性uncertainty和延遲latency。如果你定義了一個錯誤的周期比如周期寫小了后續(xù)所有CTS優(yōu)化都會按照過緊的時序預算去跑工具會插一大批多余的buffer功耗和面積直接爆掉。反過來周期寫大了CTS跑出來的時鐘樹松垮垮時序檢查過于寬松流片回來大概率翻車。create_generated_clock用于定義分頻、倍頻、多路選擇后的時鐘。它需要指定源時鐘master clock和分頻系數或倍頻系數。這個命令在CTS中同樣重要因為工具需要知道哪些時鐘是從哪些源演變來的才能正確判斷時鐘域之間的關系和時鐘樹結構的歸屬。所以在啟動CTS之前我強烈的建議是先花一個小時把SDC里的時鐘定義逐條看一遍。確認每個時鐘定義在正確的端口、周期正確、generated clock的主時鐘源正確。這一步省下來的時間至少是后排查CTS問題時間的五倍。很多人CTS跑完發(fā)現Skew報告亂得沒法看回頭一查果然是時鐘定義里有個master pin選錯了。這種事情我?guī)缀趺孔鲆粋€項目都能碰上至少一次。3. CTS的實現機制從短時鐘樹到長時鐘樹3.1 為什么不能用簡單buffer鏈搞定CTS很多人對CTS的理解是插buffer把信號從根節(jié)點送到所有終點。聽上去簡單為什么工具實現起來這么費勁核心原因有三個。第一分支路徑絕對不可能等長。芯片上寄存器的物理位置分布極不均勻有的在時鐘網絡根節(jié)點旁邊有的在die的對角。要把這些位置完全不同的點串成一棵樹自然會出現路徑長短不一的情況。第二每個節(jié)點的負載不同。寄存器的時鐘輸入端電容、時鐘網絡的走線長度都會影響delay。負載大的分支天然更慢負載小的分支天然更快不加以干預Skew自然就形成了。第三前級buffer的驅動能力有限。一個buffer能驅動的負載是有上限的負載超過上限delay會急劇增大甚至導致信號邊沿變緩引發(fā)保持時間問題。所以CTS本質上是一個需要不斷插入buffer、調整buffer尺寸、調整樹的拓撲反復迭代收斂的過程。3.2 短時鐘樹策略面向低頻與少量寄存器在進入工具如何構建長時鐘樹之前先說說“短時鐘樹”這個概念。因為很多人做項目面對的其實不是那種動輒幾萬寄存器的超高頻時鐘域而是一兩個甚至十幾個寄存器的小模塊。如果一個時鐘域只有二十個寄存器分布在一塊很小的區(qū)域里離時鐘源端口也很近這時候CTS就走短時鐘樹比如單一層或兩層buffer就夠了。短時鐘樹的優(yōu)勢是延遲小、功耗低、面積小且天然Skew小因為你不需要為了平衡遠處寄存器而人為拖慢近處寄存器。工具一般是根據扇出和物理分布自動決定時鐘樹層級的。但如果你的約束里對某些時鐘設置了非常嚴格的target latency工具就可能被迫多插幾層buffer把短時鐘樹變成中時鐘樹。這時候你的約束就起到了反作用——非但沒有讓時鐘更好反而讓功耗和面積白白浪費了。所以在寫SDC的時鐘約束時不要想當然地給時鐘加一個特別小的latency期望。除了少數高頻接口時鐘大多數內部時鐘latency大一點小一點并沒有那么關鍵關鍵是Skew和transition達標。這個觀念一定要扭轉過來。3.3 長時鐘樹策略平衡偏斜與延遲的全局考量當寄存器數量上去了比如上萬物理范圍鋪滿了整個芯片CTS就不得不用長時鐘樹策略了。長時鐘樹通常是H-tree或者在工具看來是“多級平衡樹”的形式。工具構建長時鐘樹時邏輯上會經歷這樣幾步第一步確定葉子節(jié)點集合。工具從時鐘根節(jié)點出發(fā)沿著時鐘網絡去追蹤所有終點通常是寄存器的clock pin。這個過程在Innovus里可以通過report_clock_tree來查看工具會列出所有sink以及它們所屬的時鐘域。第二步分層構建。工具不會從根節(jié)點直接接一長串buffer把每個sink都驅動起來而是先驅動一個大buffer作為“大干線”再從大干線分出幾條支路每條支路再驅動下一級buffer逐級展開直到覆蓋所有葉子。每一級都在做一個子樹的平衡最終整棵樹近似平衡。第三步插入延遲單元。為了平衡整體Skew光靠選對buffer尺寸還不夠有時候必須犧牲某些路徑的延遲來配合全局。一個常見的做法是在較短路徑上插入額外的delay單元讓該路徑的延遲與其他路徑拉齊。這個做法在時序分析里有專門的名字——useful skew我們放到后面講。第四步迭代修正。工具會根據當前樹的實測delay和Skew情況重新調整buffer的尺寸和位置。這個過程在Innovus的CTS log里能看到多次迭代的記錄。每次迭代都會更新wire load模型和RC值逐步逼近收斂。對于長時鐘樹有一個容易被忽視的點時鐘樹的頂層走線寬度和處理方式與普通信號完全不同。在Innovus里你通常會為時鐘樹專門定義一組寬金屬、低電阻的route層并且允許它使用比普通信號更寬的線寬。這不是為了好看而是為了降低電阻減小RC延遲保證時鐘信號在長距離傳輸過程中的邊沿不會惡化。3.4 時鐘樹參考單元與硬件準備CTS要能跑起來除了邏輯本身還必須有時鐘樹參考單元也就是CTS庫通常在.lib文件里標記為clock_gating_integration_cell、clock_buffer、ct_cell等屬性的單元。這些參考單元主要分三類時鐘緩沖器Clock Buffer專用buffer特點是延遲對負載的敏感性較低、輸入電容匹配好、rise/fall延遲對稱性好。對稱性在時鐘樹里特別重要。因為時鐘信號在傳遞個幾百個寄存器的過程中如果rise delay和fall delay不一致高電平占空比會逐漸失真導致時序分析時遇到底部偏移的問題。時鐘反相器Clock Inverter在某些工藝節(jié)點上clock inverter因為本身結構簡單延遲波動更小反而更能做出低Skew的樹。不過用inverter搭時鐘樹會帶來相位翻轉的問題工具需要額外處理。時鐘門控單元ICG用于時鐘門控在低功耗設計里是標配。ICG通常自帶latch和AND門結構能避免門控時鐘產生毛刺。在定義CTS參考單元的時候有兩種策略一種是限制工具只能使用指定的幾組buffer另一種是放開讓工具從標準單元庫中自動選擇。我的建議是除非你的庫非常成熟、參考單元分類很良好否則盡量手動指定一個或幾個尺寸的buffer。工具自動選庫里的所有單元去優(yōu)化時鐘樹雖然理論上能找到一個更優(yōu)的尺寸點但在庫里混雜了通用邏輯buffer、低功耗buffer的情況下工具選出來的單元未必適合時鐘用途容易在后期出現transition違例。手動圈定一個緩沖器集合既是經驗之談也是逼著自己去熟悉庫里的單元特性。4. 實操要點Skew Group、有用偏差與時鐘樹質量評估4.1 Innovus中CTS的基本流程與常用命令進入工具實操環(huán)節(jié)。這里以Innovus為例因為目前業(yè)界用的最多。流程上place做完之后跑CTS之前有幾件事是必須做的第一件確認clock定義無誤?？梢酝ㄟ^report_clock -summary快速瀏覽所有時鐘。重點看周期、主時鐘、group。如果發(fā)現group是默認的最好手動分組。第二件設置CTS專用變量。Innovus里有大量與CTS相關的變量其中最重要的幾個包括cts.target_max_trans目標transition時間、cts.target_skew目標偏斜值、cts.max_fanout最大扇出限制、cts.buffer_cells允許使用的buffer列表。這些變量在開始之前就要設置好。第三件執(zhí)行時鐘樹綜合。在Innovus里直接跑clock_design就能啟動CTS。跑的過程中工具會打印出很多信息包括正在建的樹、當前延遲、Skew收斂情況等。第一次跑CTS不要著急去翻tcl腳本細節(jié)先關注三個內容log里是否有warning/error、報告出來的Skew是多少、tree的depth是多少。第四件做post-CTS的時序分析。跑完CTS之后需要把時鐘設為propagated重新做一次時序檢查。命令是set_propagated_clock [all_clocks]然后重跑STA。這時候的結果比place階段要真實得多可以看出來CTS到底合不合格。我個人的習慣是跑CTS之前先手動創(chuàng)建一個“時鐘樹調試用”的工程目錄備份。這樣如果在CTS后發(fā)現是時鐘定義的問題可以快速回到place階段重新來過不用再做一次place。這個習慣救過我很多次尤其是處理一些上百個宏單元、多時鐘域混雜的復雜設計時。4.2 Skew Group為什么應該手動劃分時鐘組默認情況下Innovus的CTS會為每個時鐘自動建一個時鐘組Clock Group。但實際設計中一個時鐘域內部由于數據流的關系并不是所有寄存器都需要被嚴格對齊的。最典型的場景是可測性設計DFT。在shift模式下scan鏈上的寄存器要求時鐘能夠同時翻轉這需要一個極低的Skew。但在功能模式下掃描鏈路兩端的時序要求可能是完全不同的。如果工具按照功能模式下的時鐘約束去建樹得到的Skew可能在shift模式下不滿足。這時候就需要手動把同一個時鐘里的寄存器劃分成不同的Skew Group讓工具在不同的組間做有傾向性的優(yōu)化。比如scan時鐘域可以建立一個專門的group要求極低global skew而功能時鐘域只要保證local skew夠好就行。Innovus里劃分Skew Group用create_clock_tree_group命令。你可以根據時鐘樹根節(jié)點和組內sink來劃分也可以指定一組特定的寄存器pin作為組內成員。比如create_clock_tree_group -name func_group -clock CLK -sinks [get_pins ...list_of_ff_ck_pins...]實際項目管理中我們通常先跑一版默認CTS然后從報告里看哪些路徑的時序最差再針對性地把這些路徑上的寄存器劃到同一個group里做精細優(yōu)化。這個過程要迭代好幾輪也正是數字后端工程師最耗時間的地方。4.3 有用偏差Useful Skew的高級用法講到Skew Group就繞不開Useful Skew。這個概念前文提過一句這里展開講透。傳統(tǒng)CTS的目標是把全局Skew壓到最小。但如果我們放寬這一目標允許一定的偏斜利用它去“幫忙”修復時序那就是Useful Skew。它本質上是一種主動地、有方向性地控制Skew的行為。舉一個具象的例子假設有一條數據路徑從FF_A到FF_B路徑延遲是2.2ns而時鐘周期是2ns正常時序無法滿足。如果我們能讓時鐘到達FF_B的時間比到達FF_A的時間晚0.3ns那么在數據沿到達FF_B之前時鐘沿還沒到來目的寄存器“晚一點采樣”就多給了0.3ns的建立時間預算。這條路徑就修好了。反過來對于保持時間的違例我們可以讓FF_B的時鐘比FF_A早一點到這樣數據變化沿到達之前舊數據已經被采樣過了從而消除保持時間違例。這就是保持時間方向上的Useful Skew。但是Useful Skew是一把雙刃劍。你今天讓FF_B晚采0.3ns雖然滿足了FF_A到FF_B的時序但FF_B它自己作為源寄存器到達下游FF_C的數據路徑是獨立的一條它的晚采樣不一定能保證下游路徑。如果下游路徑也是緊的那你用Skew補了上游漏了下游反而可能越調越亂。所以實際工程中Useful Skew通常不是手工去調的而是交給工具。Innovus里有一個專門的模式——在時鐘樹綜合時允許工具利用skew來修復時序比如set_analysis_mode配合時序預算、或者時鐘樹選項ccopt_useful_skew相關的變量。新手階段我不建議手動做useful skew經歷不夠的話非常容易把自己繞進去。4.4 怎么通過報告評估時鐘樹質量CTS跑完怎么判斷質量好壞我一般按這個順序看報告。先看report_clock_tree -detail里面每一層有Cell count、Net Length、Cpin等。重點看第一列根節(jié)點到sink的延遲Latency以及sink之間的Skew。如果延遲異常大排除時鐘定義或庫的問題后很可能是工具用了太多級的buffer可以考慮換更大的主干buffer。再看report_clock_timing -type skew或report_clock_timing -type latency這里展示每個時鐘域的skew統(tǒng)計和latency。Skew達標與否不光看平均還要看最大差值。有的工具報告顯示平均skew是幾十ps但max差值可能幾百ps這種情況說明少數sink拖了后腿需要單獨檢查這些sink的物理位置。再然后看report_timing -from [時鐘根] -to [哪個sink]用于逐條分析延遲構成。如果發(fā)現某一段延遲異常要看是不是因為繞線太長或者經過的特殊單元太多。最后看transition報告。時鐘信號的transition如果太大不只影響本路徑還會影響下級寄存器的時鐘輸入端的建立和保持時間計算。Innovus里CTS做完后如果check_report說有transition violation你可以在工具里設set_clock_tree_options -target_max_trans來收緊目標或者調整clock buffer的尺寸?？催@些報告最忌諱的就是只看一個數字然后下結論。時鐘樹是一個整體網絡局部指標好不代表整體好整體skew達標也可能存在局部transition問題。要結合起來看。5. 時鐘樹的信號完整性與可靠性問題5.1 時鐘樹上的串擾與噪聲到了深亞微米工藝之后時鐘樹的信號完整性問題越來越突出。時鐘樹是全局網絡中走線最長、buffer級數最多的網絡之一天然容易受到相鄰信號的干擾。串擾導致的結果有兩類一類是串擾延遲即相鄰信號的翻轉改變了時鐘信號的傳播速度另一類是串擾噪聲即相鄰信號翻轉時在時鐘信號線上感應出電壓脈沖嚴重時可能導致時鐘沿提前或延遲到達。在Innovus里CTS做完后一般會有一個ccopt_design或post-CTS的SI分析環(huán)節(jié)。如果報告顯示時鐘樹上有明顯的SI問題常見處理手段包括將時鐘網絡的繞線間距擴大double spacing減少與相鄰signal net的耦合電容。對關鍵時鐘網絡做特殊繞線屏蔽shielding但這會占用大量繞線資源一般只用在高頻超關鍵路徑上。調整時鐘網絡所在的金屬層讓它們避開擁塞區(qū)域減少串擾風險。需要注意的是這些SI修復手段都會額外增加繞線資源和功耗所以不是所有時鐘網絡都需要做一般只對high-frequency clock或high-fanout clock做。低頻時鐘串擾的影響相對有限放寬一點也沒有關系。5.2 時鐘樹上的IR Drop與電源噪聲再說電源問題。時鐘buffer在翻轉的瞬間會抽取瞬時大電流如果供電網絡不好局部的IR Drop會很大。而IR Drop又直接影響了buffer本身的延遲導致不同位置的時鐘buffer延遲不一致間接惡化Skew。這就是為什么在時鐘樹優(yōu)化時除了看時序報告還要關注電源域劃分和power mesh的密度。如果某個角落的IR-drop報告特別嚴重就得提前在物理實現階段把power mesh加密而不是在CTS階段想著靠插buffer去彌補。工具再強也補不出電源質量問題。另外時鐘樹本身也會消耗不小的動態(tài)功耗。時鐘每翻轉一次所有clock buffer以及所有寄存器的clock pin都要跟著翻轉。一個幾萬寄存器的時鐘域時鐘樹的動態(tài)功耗可能是整體芯片功耗的15%到25%。如果你做的是低功耗設計CTS階段就要考慮如何減小時鐘樹深度、減少高功耗buffer的使用。5.3 時鐘門控Clock Gating的注意事項低功耗設計里ICGIntegrated Clock Gating cell用得非常多。時鐘門控的引入帶來一個CTS里特有的副作用它把時鐘樹的負載切成了幾個子域并且每個ICG輸出的時鐘信號只有在使能時才翻轉這就導致每個ICG輸出的子時鐘樹雖然在物理上是同一根時鐘網路上分出去的但在邏輯上可能在某些時間點是相對獨立的。CTS工具在構建時鐘樹時會把每一個ICG視為一個“半透明”的節(jié)點。也就是說時鐘到達ICG輸入端之前要走一段公共路徑到達ICG之后各子樹單獨平衡。這個結構帶來一個麻煩如果ICG的EN信號質量不好或者ICG本身的delay在不同電壓溫度下差異大那么ICG之后的子時鐘樹之間會產生額外的skew。在檢查CTS報告時額外關注一下ICG的輸出端到葉子之間的延遲。如果發(fā)現不同ICG下的子樹skew偏大極有可能是因為ICG插入位置不合理比如某些ICG離時鐘根節(jié)點太近某些又太遠。這時可以通過移動ICG的位置、或者在ICG輸入端加緩沖器來重新平衡各子樹。6. 常見問題與排查技巧實錄6.1 問題一CTS后Skew反而惡化我遇到最多的情況是CTS跑完后報告里的Skew比預估的還要大。排查思路如下。先確認時鐘定義。在Innovus里執(zhí)行report_clock -summary -skew看這個時鐘域的sink數量是不是異常多。有些時候時鐘定義沒有正確排除DFT mux導致工具把scan時鐘和功能時鐘當作同一棵時鐘樹來建工具為了平衡兩邊的延遲只能靠加buffer最終結果就是Skew變大、面積變大兩邊都沒討好。其次看sink的分布。用GUI或命令打開sink的物理坐標如果發(fā)現sink分布呈現兩個極端比如大部分集中在左上角少部分跑到右下角說明工具為了平衡全局必然要把左上角也拉長到和右下角一樣的delaySkew自然就大了。這時候的思路是拆成多組時鐘樹而不是死磕單一平衡樹。6.2 問題二transition時間過大導致setup違例時鐘信號transition過大本質是驅動能力不夠或者繞線過長。排查方式很簡單在報告里找到transition違例的時鐘網絡去GUI里看它的物理路徑看是不是繞了一圈才到達端點。如果是繞線過長手段是換驅動能力更大的clock buffer或者讓工具把該時鐘網絡的繞線層限制到低電阻層。如果是因為負載太重先看sink數量是不是一個buffer帶了異常多的寄存器可以通過set_clock_tree_options -max_fanout限制最大扇出讓工具手動多插一級buffer。但要小心分叉層級的增加會直接增加latency而latency增大會影響hold margin的計算。所以transition和latency是CTS里一對需要平衡的矛盾指標。修transition時要時刻關注latency的變化不要按下葫蘆浮起瓢。6.3 問題三多個時鐘域交互處的CTS優(yōu)化多個時鐘域交互CDC是CTS里的一塊硬骨頭。異步時鐘域之間不用做同步但時鐘樹物理上如果重疊工具會默認去平衡兩個域的skew導致兩邊都做不好。這里的關鍵是把異步時鐘域的CTS約束隔離開。在Innovus里可以用set_clock_groups -asynchronous把時鐘組之間的時序路徑設為false path讓工具不去優(yōu)化它們之間的時序。這樣做之后CTS會更加“自私”地優(yōu)化各自域內的skew效果通常立竿見影。另外一個常見陷阱是跨時鐘域的保持時間違例。因為異步域數據不是同步的可能會有偶爾的保持違例命中。處理辦法是檢查SDC里是否對CDC路徑做了set_false_path或set_max_delay約束。如果沒做請盡快補上。6.4 項目實戰(zhàn)中的經驗心得總結做CTS這幾年最大的感受是CTS最難的從來不是工具怎么用而是你怎么理解你的設計。工具是一個高度智能的求解器你給它正確的約束它能給你一個高質量解你給它糊涂的約束它只會裝模作樣地“優(yōu)化”出一個滿足你錯誤約束的糊涂結果。有幾個原則是我一直堅持的時鐘定義一定自己過一遍不要輕信綜合腳本里的SDC。綜合工程師可能為了時序收斂在SDC里寫了各種奇怪的時鐘約束這些約束在邏輯階段是好的但到后端階段可能變成CTS的枷鎖。CTS之前先做floorplan review。寄存器密度、macro位置、電源網絡密度這些都會深刻影響時鐘樹質量。如果floorplan里macro擺放把一塊時鐘區(qū)域切割得支離破碎再厲害的CTS也建不出漂亮的樹。與其在CTS階段折騰不如回到floorplan階段把關鍵模塊調整好。每個項目都要積累屬于自己的CTS check list。把上一步驟、本步驟、下一步驟的檢查項目列表記錄下來每次做新項目都翻一下按順序打鉤。CTS環(huán)節(jié)的不少問題都有強烈的上下文依賴性換一個設計、換一個工藝庫之前管用的參數可能就不管用了但檢查清單是通用的。寫在最后時鐘樹綜合是一面鏡子照見的是你對芯片物理本質的理解程度。理解了時鐘信號的傳輸特性理解了Skew、Latency、Jitter在時序分析中的角色理解了工具優(yōu)化目標的取舍邏輯你才能真正駕馭CTS而不是被工具的報告追著跑。這一篇側重的是時鐘信號本身的原理和CTS的整體框架下一期我打算結合具體的Innovus腳本來做一次完整的CTS實戰(zhàn)演示包括約束設置、時鐘樹選項調優(yōu)、時鐘樹報告解讀那個環(huán)節(jié)。如果你們在項目里遇到過什么特別的CTS問題歡迎在評論區(qū)聊我盡量都回復。