我覺得稱時鐘樹為芯片的大動脈一點也不夸張，因為所有flipflop 翻轉都要受到它的控制。而時鐘樹的設計到實現是一個很復雜的過程，從流程上說，它牽扯到使用的工具，流程，flow等。從人的角度講，它需要設計，綜合，dft ,pr, sta 工程師的通力合作。從知識上講它需要一定的芯片架構設計知識，一定的綜合，STA 知識，一定的dft知識，包括一定的pr 長clock tree的知識。我這里結合我的個人有限知識，結合實踐經歷以及理解對這些問題做多方面的闡述，難免有缺漏，也是為了拋磚引玉，歡迎同仁討論。集思廣益。

本文所涉及的工具綜合DC, 時序分析PT, 物理實現工具innovus.

大家需要什么樣的clocktree呢？

設計：我要更少的PLL, （更多的PLL 帶來配值的麻煩，能用各種分頻產生的頻率。盡量用分頻電路產生，能不多加PLL就不要多加。）我要沒有毛刺，PLL jitter抖動更小（設計上沒有毛刺需要電路結構上的改變 如glitch free mux ， PLL jitter需要電路上更給力的模擬單元。）。我要更低的功耗 （設計通過powerpro 添加更多的ICG 上去，ICG的效率提上去。盡量不要有組合邏輯clock gating檢查。）

DFT: 我要配值更少的PLL (盡量相同頻率的邏輯用一個PLL 去拉通，更多的PLL 需要更多的tdr 配值增加面積還帶來不確定性）。我要更少的occ (相同頻率的fanout 盡量墊一個occ， 更少的occ ，更少的面積，處理起來也更簡便）

SYN&PR :我要更精準的SDC ( 更精準的SDC 去除更多的假path, 在PR SI 分析上也能過濾掉不該分析的部分，還能指導clocktree的生長 ）。我要更好的useful skew (需要flow，分析，try run和調整，來達到不平的clock tree 與setup hold 之間微妙的平衡）。我要更長的common path ,更短的clock tree (長的common path 更短的clocktree, 可能需要設計clock tree結構調整， sdc 的調整，ccopt spec 調整， place 調整等等）。

我要PLL 的REF CLOCK 走更短的距離 （PLL ref clock 需要高的時鐘質量。提前有好的規劃，不要插多余的cell到ref clock 路徑上，pr floorplan 的迭代 控制PLL 與ref clock 的距離， 綜合過程不要給這種net上加東西。）。我要更小的SI (pr clock tree 布線上更好的布線層規劃，良好的shielding )。我要tree更好的平衡 （該balance的地方balance，不該balance的地方不要相互拖拽，需要良好的ccopt_spec， sdc ，以及setting配合。）

等等，還有很多，所有的需求都需要相互trade off 來達到一個平衡。

我以圖片舉例來挑其中一些問題針對的談談。

能不要多點長tree平衡,盡量不要多點長tree，除非迫不得已。如圖從物理實現角度說 綠色是一個block ，A 和B 兩個clock 從port進來需要相互balance。這種結構block的PR工程師好不容易把A 和B 調的tree平衡。但是到了頂層,頂層pr工程師還需要保證紅色的到A &B兩個hier pin的tree路線是平衡的。對時序收斂是不友好的。

設計牽扯到從block穿clock出來到頂層的結構那么紅色的這路去頂層的clock路徑不要帶多余的邏輯，如果有多余的邏輯分配到A 那部分去， 因為綠色的地方dft要加occ, 而occ一般是不級聯的。

設計中驅動兩個hinst如果是同頻的能用一個occ （紅色） 就盡量不要用兩個（綠色）。造成面積浪費不說，且如果A和B再有timing talk 會導致非 common path 變長。

分頻模塊在功能模式下的分頻系數頻率與dft 模式下的分頻系數盡量一致。當功能模式時候toggle fun_reset 就能讓div模塊配置到需要的系數上。當dft模式下toggle dft cgu reset 也能讓div模塊配置到相同的系數上。否則需要dft通過tdr或者其它連線來配值自己想要的參數，增加多余邏輯。不過具體情況具體分析。沒有通解。

STA 工程師盡量通過良好的使用 set_clock_group -physically_exclusive -logically_exclusive -asyncronus / set_clock_exclusivity 等命令去過濾掉C 位置不應該A B共存導致的SI 分析。

多種mode sdc 能merge的盡量merge ,不能merge再具體問題具體分析。多個mode sdc會產生更多需要分析的constraint mode 產生更多scenario 耗費更多時間。舉個例子類似我遇到的這種結構的clock 就是相對不那么好做的 A B C三個mux會從ip上去選clock。而且A B C之間相互還需要balance, 那么就是2 * 2 * 2 = 8 種可能性。關鍵是這8種可能性在真實情況下可能只有5種是真實會產生的。

你如果只通過create_clock create_generated_clock set_clock_group set_false_path 方式來做，那么就會產生過約，因為會額外約束多余那3種可能性，如果我通過給mux sel set_case_analysis 來case的話那么就會產生更多的sdc mode， 更多的view.事實上當時這種類似mode有好幾十種情況。

合理的使用set_clock_sense set_sense.應用場景有時會有個A clock 高頻clock和B clock 低頻clock 經過mux去驅動后面的A INST 與B INST, 真實情況是可能B clock 只會打到A INST 模塊進行搬運數據， 比如芯片boot階段。它不會去B INST 那么一定要用set_sense 去把B clock在B INST 前面停掉，這有利于timing分析也有利于PR 進行長clock tree。默認情況下innovus create ccopt spec 會轉換 set_sense /set_clock_sense 為 set_ccopt_property -sink_type igore [get_pin xxx] 這樣對于B clock 來說B INST 里面的sink點就不會被balance 。去掉不該balance的 sink點自然tree就會更好。

合理利用useful skew ECF/ccd

真實的設計中clock是不可能長的完全平的。那么可以通過useful skew 來達到data clock setup&hold 微妙的平衡。

通過分析DC 的timing報告人為通過set_clock_latency -clock xxx [get_pins xxxx]去調整clock tree 長度，讓DC按照不平的clock tree 長度進行優化。進入INNOVUS的時候 INNOVUS create_ccopt_spec 會轉換set_clock_latency 命令為

set_ccopt_property -insertion_delay xxx [get_pins xxxx] 來調整clock tree長度，達到更好的平衡。

或者在DC 中開啟ccd ， 通過write_scripts 寫出工具根據組合邏輯和你的設置推出來的tree長度腳本set_clock_latency -offset ， 通過腳本轉換set_clock_latency -offset 為標準set_clock_latency -clock xxx [get_pins xxx] SDC ，進入INNOVUS 優化。

或者INNOVUS 刪除set_clock_latency 開啟Cadence 自己的useful skew ECF 來自動進行不平clock tree優化。

至于結果，不好說，不同設計反映不一，推的過多會導致hold難修。當然Synopsys會推薦DC 可以開hold corner 然后來估計hold的影響，讓推的不要太兇。

針對這種結構一個M clock驅動兩坨邏輯紅色和上面黑色。

通常做法是整一個M 整一個GCLK G1 GCLK G2 然后設置clock_group 來解決。

不要嘗試直接在G2 位置create一個master clk， 然后設置clock_group

這種會導致G2 前面的source latency 丟失，導致無法分析前面路徑的延時SI 等影響，也不能用來signoff

但是這種類型的SDC 用來INNOVUS ccopt 來長clock tree是極好的。尤其是當你不怎么熟悉innovus的ccopt spec ，但是你又很熟悉sdc和clock結構的時候。

innovus默認create的spec就不會balance 紅色和藍色因為你的G2 地方的create的是一個master_clock

當然別忘了update_constraint update回來，更別忘了手動call update_io_latency/set_propagate_clock 來propagated clock 否則你長完tree你的clock還是ideal的。

最后強調一點，默認innovus create ccopt spec 是不識別sdc里面的 clock_group , false_path 的，它只根據你的clock 物理連接結構走。 當然有setting可以讓create ccopt spec去識別 clock_group 和false_path ,但是只是大家都不這么做而已。具體原因可能是工具不完善吧，也有可能是這樣創建的spec 文件太大，或者太多的這種ccopt的設置會導致不期望的結果之類的。

著重注意IP 位置的clock ,有的情況是一個ip是liberty ,internal pin會打數據 D 出來同時這個internalpin又會打clock出來 IP 外面會有flipflop來接數據，這種path由于launch clock 無法調整。導致timing不好收斂。

或者是這種IP 作為liberty internal pin會打clock出來給flipflop launch 然后再用這個internalpin到IP 邊界上去check。這種由于capture clock 沒法控制同樣不好收斂。

針對這種情況及時syn pr， 聯系vendor 與設計， 確認路徑的正確。設計能retime flipflop 多次打拍就提前做。方便timing收斂。

PR 盡量和dft以及sdc owner多溝通。了解dft test_clock sdc里面是怎么下的。通常情況test_clock 會通過不同的occ去trigger 幾乎所有的flipflop 。一般情況下dft 穿chain是分clock domain 穿的。也就是各個occ是相互不check的。當你的pr sdc為了簡便下的比較粗的情況比如一個create 一個test_clock 完事，沒有在各個occ上做test_clock的分開處理。那么建議在ccopt spec里面把test_clock skew group 設置成none不要讓它去balance。否則它會退拽整個設計的tree。

設計時鐘樹時候盡量不要讓block 的clock 穿兩個port到頂層再去trigger 兩個flipflop相互拍數據。這樣會導致clock branch point 在block內部，導致cppr過小timing不好收斂。

這對這個問題其實還有變形，原理其實都是控制clock tree 的branch point 來控制cppr來優化timing

如圖A block 產生clock 到B block 拍數據給C block 左邊連接是不是branch point 在A block內部這樣cppr 就小。

如果改成右邊的結構 branch point 就在B block cppr 就會變大。當然要注意這時候可能capture path就會過長也許對hold不利。所以要做trade off。本質點在于移動clock branck point.