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