時(shí)鐘樹綜合（Clock Tree Synthesis）一直是數(shù)字后端實(shí)現(xiàn)中最為重要的步驟之一。隨著芯片時(shí)鐘越來越多，設(shè)計(jì)階段都采用了時(shí)鐘切換電路，時(shí)鐘結(jié)構(gòu)越來越復(fù)雜（除了func mode外，還有test mode和mbist等模式）。針對(duì)復(fù)雜的時(shí)鐘結(jié)構(gòu)，想單純依靠EAD TOOL的CTS engine來實(shí)現(xiàn)一個(gè)比較好的clock tree質(zhì)量，幾乎不太可能。而且一個(gè)比較理想的clock tree，都是要通過若干次的迭代而產(chǎn)生的，絕對(duì)不是你隨便跑一次flow就可以的。在這里順便強(qiáng)調(diào)一個(gè)觀念，數(shù)字后端實(shí)現(xiàn)絕對(duì)不僅僅是run flow，你的價(jià)值不應(yīng)該停留于此。如果你還僅僅停留在run flow這個(gè)level，勸施主早日改邪歸正，呵呵。
那么，下面進(jìn)入今天的主題。首先談?wù)労饬繒r(shí)鐘樹質(zhì)量的幾大指標(biāo)。
時(shí)鐘樹綜合（clock tree synthesis）基礎(chǔ)篇
1.clock tree latency最短
clock inverter更少，clock tree上的power更小，占用更少的routing resource以及更容易timing signoff。
2. skew 最小
skew對(duì)setup和hold都有影響。特別是hold，如果兩個(gè)需要進(jìn)行hold check的register存在較大的skew，那么hold violation就會(huì)比較大。Hold 比較大，就意味著要插比較多的buffer，有可能導(dǎo)致route的問題。
3. Duty Cycle
對(duì)于時(shí)鐘樹需要保持一個(gè)很好的duty cycle。很多IO接口像DDR，在時(shí)鐘上升沿和下降沿都會(huì)采樣數(shù)據(jù)，所以在clock tree上也需要一個(gè)rise delay和fall delay一致的clock inverter。
4. Uncommon path 最短
由于clock tree上的common path，會(huì)有一部分CRPR補(bǔ)償（考慮OCV效應(yīng)）。而對(duì)于un-common path，launch 和capture都會(huì)被加上不同的derate（假設(shè)各設(shè)5%的derate），導(dǎo)致兩個(gè)DFF的clock skew更大。
圖1 common clock path and uncommon path on clock tree
5. 信號(hào)完整性
對(duì)于clock net需要設(shè)置CTS NDR (Non-Default Rule) ，比如兩倍width，兩倍space。這樣可以有效防止crosstalk和EM。對(duì)于高頻時(shí)鐘信號(hào)或者對(duì)于時(shí)鐘質(zhì)量要求特別高的clock，我們還需要對(duì)clock net進(jìn)行shielding，保證clock tree上無任何串?dāng)_（作為一個(gè)signoff來check）。
說到CTS NDR，讓我感慨萬千。前幾天有個(gè)粉絲問了一個(gè)問題，關(guān)于為何CTO之后timing是meet的，route后timing確變差很多。當(dāng)我剛看到這個(gè)問題時(shí)就覺得最大的嫌疑是檢查route后clock tree上是否存在較大的crosstalk。結(jié)果發(fā)現(xiàn)居然NDR沒設(shè)置上，clock tree上每個(gè)cell都有個(gè)5-6ps左右的crosstalk。
說這個(gè)事情呢，主要想表達(dá)兩個(gè)小建議：
遇到問題一定要先自己分析，必須自己學(xué)會(huì)思考，學(xué)會(huì)debug。
PR各個(gè)階段都干了些啥，每個(gè)階段不同的地方是什么，這些是debug的方向。
案例分析：
下面簡單介紹下三個(gè)case。通過這幾個(gè)case，希望各位能夠慢慢養(yǎng)成獨(dú)立分析時(shí)鐘樹的能力。而且能夠?qū)㈨?xiàng)目中時(shí)鐘結(jié)構(gòu)不合理的points，反饋給數(shù)字前端設(shè)計(jì)工程師。因?yàn)橐粋€(gè)不合理的時(shí)鐘結(jié)構(gòu)，會(huì)導(dǎo)致timing 收斂非常緩慢，甚至不收斂。這樣的結(jié)局就是做項(xiàng)目大家都累得半死。
CASE1:
第一個(gè)case如圖2所示。func clock和tck1通過Mux1來進(jìn)行時(shí)鐘切換。在圖中表箭頭的地方定義了一個(gè)generated_clock。當(dāng)Tool在build func clock時(shí)（假設(shè)Register set2離root最遠(yuǎn)），該func clock的 longest clock path為Register set2中的某個(gè)reg的clock path。所以工具為了balance 寄存器組1，寄存器組2和寄存器組3，不得不在MUX1的輸出端和寄存器組1的CLK之間墊足夠多的clock inverter 。
這樣似乎沒有問題，但是在低速test mode下，tck1的clock latency顯然太長了。因此，為了避免測(cè)試時(shí)鐘的clock latency過長，我們可以復(fù)制一個(gè)MUX，使得func和test mode分別走不同的時(shí)鐘路徑，如圖3所示。
圖2 原始時(shí)鐘結(jié)構(gòu)圖
圖3 改進(jìn)后的時(shí)鐘結(jié)構(gòu)圖
case2 :
假設(shè)CK1和CK2是同步時(shí)鐘。Tool在做balance時(shí)，為了節(jié)省clock buffer往往會(huì)在MUX的output到reg group2之間插入clock inverter（有些時(shí)候可以用少量的clock buffer）。這樣做會(huì)有問題嗎？答案是可能存在問題，即導(dǎo)致Reg group1，group2和group3之間的uncommon path變長，如圖4中左側(cè)所示。如果我們將MUX輸出端的兩個(gè)clock buffer挪到mux的D0和D1 端口上，同樣可以實(shí)現(xiàn)各個(gè)寄存器組之間的balance。而且它們之間的common path變長了，uncommon path變短了。這樣的行為對(duì)Timing是極好的。
圖4 case2 優(yōu)化前后的時(shí)鐘樹
case3: power or timing based 的時(shí)鐘樹綜合
人生面臨很多選擇，我們也在不斷地做出不同的選擇，每個(gè)選擇都是一個(gè)tradeoff的過程。同樣，數(shù)字IC設(shè)計(jì)實(shí)現(xiàn)的結(jié)果也是數(shù)字IC設(shè)計(jì)實(shí)現(xiàn)工程師在不斷地做tradeoff，而所達(dá)到的一個(gè)結(jié)果（PPA）。第三個(gè)case如下圖5所示，留給各位思考。左右側(cè)兩種時(shí)鐘樹，哪種更好？他們的優(yōu)缺點(diǎn)是什么？
其實(shí)時(shí)鐘樹綜合并不難，關(guān)鍵是要理清時(shí)鐘結(jié)構(gòu)，搞清楚各種mode下時(shí)鐘如何切換，各個(gè)時(shí)鐘間的同步異步，以及哪些clock需要做inter-balance等問題。
圖5 兩種不同的時(shí)鐘樹綜合策略
聯(lián)系客服
