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

圖一 一個最常見的muti Clock的時鐘樹結(jié)構(gòu)

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

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

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

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

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

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

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

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

修改target來優(yōu)化工具的分點和balance長樹，內(nèi)容主要包括（注: 修改要在clk spec生產(chǎn)后，即generate spec后分點前）

增加new skrewgroup以及generated clk來指導(dǎo)工具解drv和長tree（這個主要優(yōu)化latency，skew變化并不大）,以圖一的CLK結(jié)構(gòu)為例子，F(xiàn)ast Clk下MUX的ZN端可以設(shè)置generate CLK，并以這個為source，設(shè)置一個新的skew group.

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

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

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

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

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

審核編輯：劉清