那麽，下面進入今天的主題。首先談談衡量時鐘樹質量的幾大指標。
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更大。
CRPR能補償crosstalk嗎？
圖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 ?兩種不同的時鐘樹綜合策略
原文鏈接： 數字後端實現之時鐘樹綜合實踐篇 - 知乎 (zhihu.com)