對于時鐘樹綜合，各位后端工程師應該都很熟悉，做好一個模塊/一個chip的時鐘樹，對整個項目的功耗和Timing影響都是巨大的。一個優秀的后端工程師，也不會只是單純的放置幾個TAP點，來工具根據source group來自己分點做Tree，這樣只會跑flow 做樹的工程師在面對工具搞不定的復雜時鐘結構的時候，只能束手無策，導致繞線完返修，花費很多時間在signoff階段，對時序和功耗硬修，甚至導致流片delay，今天我們就來根據項目經驗來幫助大家做出更好，更完美的時鐘樹！

圖一 一個最常見的muti Clock的時鐘樹結構

首先我們要明白做樹的最終目的—當然是為了PPA的提升，其實不做樹可不可以？當然可以！當你當前的模塊規模比較小，且沒啥時序風險和PV，PI風險的時候，甚至可以不做樹。但是時鐘結構復雜/時序功耗本身就有風險的模塊就不行了，樹做的不好將會導致ecoRoute完signoff階段的時序收不下來，功耗很差，甚至根本沒法收斂，導致最后回退版本，老老實實回去做樹！那小編覺得就完全沒有必要了，我們以innovus為例，來幫助大家快速做到對樹的收斂，從而對CTS有更深的理解，而非只會跑flow看結果。

其實對于CTS這個步驟，我們可以把從初始時鐘結構到最終的時鐘樹結構分為三個階段，并且在這三個階段分別去存對應的Database，以方便分析究竟是哪一步出問題了？

第一部分—分點，這一部分主要靠工具去完成，工具會識別后端工程師提供的source group（這個根據工程師設置的tap點來定組），并將同一skew group下source group下面的對應tap點（可以是MUX，BUFF，INV，ICG等等）的OutPutPin的generate clk視為一樣的時鐘結構，進而工具會clone主Gating下除Sink點以外的原本時鐘路徑上的邏輯單元和時序單元，并將整條Path包含Sink點掛到離其最近，時序更優的Tap點下，這一分點形成初始樹的過程，在Innovus下通過以下命令實現：

對于復雜的時鐘結構，即多個分頻時鐘，倍頻CRG子時鐘，工具沒辦法很好的去分點或者說沒有過多的考慮時序，而是單純考慮距離，對Sink點進行暴力切分，導致Common Path的長度非常的短，共同路徑由source port到clone gating變成只有source port到主 ICG，這有可能會使得不同分點下的兩個Sink的local skew偏大，進而影響postCTS后的timing。這種情況我們可以通過分點完后自己手動ec掛點/分點前在Spec約束文件添加preserve port來控制工具的分點結果。

第二部分—Cluster解DRV，這一部分也主要靠工具去完成，在開始這步驟之前，工程師需要檢測對于部分Net有么有設置dont touch，有沒有設置ideal net，以免CTS綜合后發現部分CK Cell的transition過大，一追溯發現是DRV沒有解決，這一部分引起latency增大的原因其實主要是因為Placement擺放CK cell位置的不合理，使得時鐘路徑發生了detour，增加了Net delay和部分本可以不存在的解transiton的INV。這一部分遇到問題的主要解決辦法為：1.檢查place階段是不是有些Sink的局部density過大/過小，導致工具在修DRV的時候拉扯較遠/沒有位置擺放INV；2.手動ec，將最后一級INV的Fanout Sink直接掛到最近一級Clone的gating上，再解DRV（記得帶個強驅動的BUFF一起掛，否則可能會因為clone gating的outputload突然增大而導致transition解的不好，傳遞到下幾級，導致latency增大）

第三部分—Full階段長樹，這一部分工具會根據你的Spec約束來對Sink之間的Skew進行平衡，在innovus中我們一般通過ccopt_design來進行長tree和OPT同步的操作，實際上innovus在ccopt階段初期，首先會確定placement的信息，其中包括density和DRC的相關信息的check，然后在準備階段，innovus會刷新一遍IO的skew，并判斷各個skewgroup之間的關系，哪個是主clk，哪個是generateclk，是否存在復制關系？在判斷完skewgroup的復制關系后，innovus會進行early global route，進行快速繞線，以判斷有沒有繞線風險，并且檢查檢查NDR以及track的完整性等等。

所以基于以上工具的三個階段操作，后端APR工程師們需要明確分點做樹的階段目標是什么？1.降低latency，以與其他模塊的時鐘樹串起來對齊；2.降低local skew，以減少后期fix timing工作量，降低timing風險；3.增加common path的delay，目的也是為了降低latency和local skew；4.減少CK cell的數量，有利于降低面積和功耗。在這里，小編基于日常項目給出幾種做短樹的latency和做小skew的方法：

增加TAP點的數量，這個方法雖然可以有效的降低skew和latency，但是會帶來功耗負擔以及面積浪費，并且隨著TAP點增加到一定數量，收益其實會逐漸收斂。所以這個方法后端工程師最好建立在規定數量TAP點實在修不下來delay和skew的時候再使用。

修改target來優化工具的分點和balance長樹，內容主要包括（注: 修改要在clk spec生產后，即generate spec后分點前）

增加new skrewgroup以及generated clk來指導工具解drv和長tree（這個主要優化latency，skew變化并不大）,以圖一的CLK結構為例子，Fast Clk下MUX的ZN端可以設置generate CLK，并以這個為source，設置一個新的skew group.

Size up時鐘路徑上的icg以及buffer/inv,logic等instance，這樣可以增加驅動，降低transition，進而降低latency（這種方式不僅會優化latency，skew也會由一定的優化），比如D4的DCCKBUF換成D8的BUFF，H12的BUFF換成H9的BUFF等等。

可以通過提樹/推樹的xxx ps的方法，來做長做短樹，Place階段推樹/cts階段設置insertation delay都有利于樹的做短（這個方法主要影響的是balance長tree階段），這個通?？梢葬槍luster階段latency不大，但是balance長tree階段突然樹長變長的path，例如

修改Space中的CK Pin的類型，有些不影響Timing的前提下把Pin設置成為stop ignore throughpin（這個方法主要影響的是balance長tree階段）

一些ec操作，一般是工具分點/解DRV有問題的時候，才需要工程師去手動，比如重新掛點，presever pin，手動clone icg掛點等等

掌握了以上這些內容，想必各位ICer將會對CTS有更深的理解，CTS的實現其實隨著模塊時鐘復雜的變化會有更多其他方法去降低Latency以及Skew，例如調整flowPlan，與前端商量修改RTL代碼的時鐘結構，修改綜合時候map的lib cell，引入Mesh Cell等等。但是所有的一切，都是為了芯片有個更好的PPA，這樣才能讓你和大家的加班沒有白費！

審核編輯：劉清