時鐘樹綜合（Clock Tree Synthesis）一直是數字後端實現中最為重要的步驟之一。隨著晶片時鐘越來越多，設計階段都採用了時鐘切換電路，時鐘結構越來越複雜（除了func mode外，還有test mode和mbist等模式）。針對複雜的時鐘結構，想單純依靠EAD TOOL的CTS engine來實現一個比較好的clock tree質量，幾乎不太可能。而且一個比較理想的clock tree，都是要透過若干次的迭代而產生的，絕對不是你隨便跑一次flow就可以的。在這裡順便強調一個觀念，
數字後端實現絕對不僅僅是run flow，你的價值不應該停留於此。
如果你還僅僅停留在run flow這個level，勸施主早日改邪歸正，呵呵。
那麼，下面進入今天的主題。首先談談衡量時鐘樹質量的幾大指標。
時鐘樹綜合（clock tree synthesis）基礎篇
1.clock tree latency最短
clock inverter更少，clock tree上的power更小，佔用更少的routing resource以及更容易timing signoff。
2. skew
最小
skew對setup和hold都有影響。特別是hold，如果兩個需要進行hold check的register存在較大的skew，那麼hold violation就會比較大。Hold 比較大，就意味著要插比較多的buffer，有可能導致route的問題。
3. Duty Cycle
對於時鐘樹需要保持一個很好的duty cycle。很多IO介面像DDR，在時鐘上升沿和下降沿都會取樣資料，所以在clock tree上也需要一個rise delay和fall delay一致的clock inverter。
4. Uncommon path
最短
由於clock tree上的common path，會有一部分CRPR補償（考慮OCV效應）。而對於un-common path，launch 和capture都會被加上不同的derate（假設各設5%的derate），導致兩個DFF的clock skew更大。
圖1 common clock path and uncommon path on clock tree
5. 訊號完整性
對於clock net需要設定CTS NDR （Non-Default Rule） ，比如兩倍width，兩倍space。這樣可以有效防止crosstalk和EM。對於高頻時鐘訊號或者對於時鐘質量要求特別高的clock，我們還需要對clock net進行shielding，保證clock tree上無任何串擾（作為一個signoff來check）。
時鐘樹綜合實踐篇
說到CTS NDR，讓我感慨萬千。前幾天有個粉絲問了一個問題，關於為何CTO之後timing是meet的，route後timing確變差很多。當我剛看到這個問題時就覺得最大的嫌疑是檢查route後clock tree上是否存在較大的crosstalk。結果發現居然NDR沒設定上，clock tree上每個cell都有個5-6ps左右的crosstalk。
說這個事情呢，主要想表達兩個小建議：
遇到問題一定要先自己分析，必須自己學會思考，學會debug。
PR各個階段都幹了些啥，每個階段不同的地方是什麼，這些是debug的方向。
案例分析：
下面簡單介紹下三個case。透過這幾個case，希望各位能夠慢慢養成獨立分析時鐘樹的能力。而且能夠將專案中時鐘結構不合理的points，反饋給數字前端設計工程師。因為一個不合理的時鐘結構，會導致timing 收斂非常緩慢，甚至不收斂。這樣的結局就是做專案大家都累得半死。
CASE1:
第一個case如圖2所示。func clock和tck1透過Mux1來進行時鐘切換。在圖中表箭頭的地方定義了一個generated_clock。當Tool在build func clock時（假設Register set2離root最遠），該func clock的 longest clock path為Register set2中的某個reg的clock path。所以工具為了balance 暫存器組1，暫存器組2和暫存器組3，不得不在MUX1的輸出端和暫存器組1的CLK之間墊足夠多的clock inverter 。
這樣似乎沒有問題，但是在低速test mode下，tck1的clock latency顯然太長了。因此，為了避免測試時鐘的clock latency過長，我們可以複製一個MUX，使得func和test mode分別走不同的時鐘路徑，如圖3所示。
圖2 原始時鐘結構圖
圖3 改進後的時鐘結構圖
case2 :
假設CK1和CK2是同步時鐘。Tool在做balance時，為了節省clock buffer往往會在MUX的output到reg group2之間插入clock inverter（有些時候可以用少量的clock buffer）。這樣做會有問題嗎？答案是可能存在問題，即導致Reg group1，group2和group3之間的uncommon path變長，如圖4中左側所示。如果我們將MUX輸出端的兩個clock buffer挪到mux的D0和D1 埠上，同樣可以實現各個暫存器組之間的balance。而且它們之間的common path變長了，uncommon path變短了。這樣的行為對Timing是極好的。
圖4 case2 最佳化前後的時鐘樹
case3: power or timing based 的時鐘樹綜合
人生面臨很多選擇，我們也在不斷地做出不同的選擇，每個選擇都是一個tradeoff的過程。同樣，數字IC設計實現的結果也是數字IC設計實現工程師在不斷地做tradeoff，而所達到的一個結果（PPA）。第三個case如下圖5所示，留給各位思考。左右側兩種時鐘樹，哪種更好？他們的優缺點是什麼？
其實時鐘樹綜合並不難，關鍵是要理清時鐘結構，搞清楚各種mode下時鐘如何切換，各個時鐘間的同步非同步，以及哪些clock需要做inter-balance等問題。
圖5 兩種不同的時鐘樹綜合策略
這幾天，粉絲越來越多了，提問的人也越來越多了。有的是重複的問題，有的則是新問題。對於之前我回答過的問題，想透過找歷史回答記錄，似乎很困難（要麼去翻群歷史訊息，要麼去翻個人歷史訊息）。
所以個人覺得這個不是長久之計，知識和解答不容易隨著時間的積累而慢慢沉澱下來。所以小編注冊了知識星球（原小密圈），建立了一個數字後端技術交流圈（需要付費，志願加入原則）。在這裡，各位可以提問，小編會在24小時內給予解答（也可以發表你對某個知識點的看法，或者職業發展規劃等）。反正它是一個縮減版的論壇，增強了大家的互動性。更為重要的是，微信有知識星球的小程式入口。星球二維碼如下，可以掃描或者長按識別二維碼進入。
