對于高性能CPU設計，特別是在16 nm以及更高級的工藝節點上，signoff的corner很多，增加公共時鐘路徑長度、改善各RC端角下時鐘延遲的一致性、降低設計的局部時鐘偏斜已經成為數字后端設計師的共識。Cadence innovus工具新增的multi-tap FlexHtree結構時鐘樹方案不僅提供了H-tree對稱的時鐘緩沖器單元結構和相等的線長特點，而且其對幾何對稱性降低了要求，確保了時序單元擺放完畢后就可以進行時鐘樹綜合。建立了一個自動化的FlexHtree實現流程來降低不同corner下的時鐘偏斜。詳細討論了FlexHtree tap點的數量以及子樹時鐘綜合引擎對時鐘偏斜和設計時序的影響，進而找到了一個較好的FlexHtree實現方案。最后從時序、功耗和單元數量等方面對FlexHtree、CCOPT和魚骨型Fishbone結構時鐘樹進行了較為全面的比較，從而得出該設計更適合采用靈活的FlexHtree結構。

0 引言

現代高性能處理器對數據傳輸和數據處理需求越來越高，時鐘樹作為處理器時鐘信號傳遞的載體，對整個處理器的計算性能有著直接的影響。要想在低時鐘偏差（clock skew）的要求下將時鐘信號分配到各個局部區域在高性能系統中變得極富挑戰。

時鐘結構主要分為兩種：樹形結構與網狀結構。樹形結構設計比較成熟，以CadenceinnovusCCOPT為典型代表，EDA工具能夠根據指定的約束條件自動生成時鐘樹，并且可以選擇平衡樹還是借用有用偏差（useful skew）的不平衡樹，樹形結構廣泛應用于手機和物聯網等芯片設計中；而網狀型時鐘結構需要大量的手工工作，并經過大量的嘗試調整之后才能體現出優勢，其見諸于高性能計算芯片中。

數字同步邏輯電路時鐘樹實現方案的合理選擇才能使得CPU的高性能不是浮云。例如，網狀型（Mesh）、魚骨型（Fishbone）時鐘結構作為Intel和IBM CPU處理器慣常采用的結構，其共同特點是時鐘傳播延時（latency）、時鐘偏斜（skew）、片上偏差（OCV）都很低。Mesh結構的缺點是功耗（power）偏大、布線資源開銷大，而魚骨型結構由于子樹手工劃分比較難，手工操作比較多。目前以Flexible H-tree（縮寫為FlexHtree）結構為代表的時鐘樹近年來廣泛應用于ARM架構處理器，其特點是使用靈活、功耗低、各工藝端角（corner）下時鐘偏差比較小。

本文將以帶多末梢點（multi-tap）的FlexHtree作為研究對象，嘗試在降低clock skew的同時不對建立時序（setup）和功耗帶來明顯的影響。本文的設計結果給高性能CPU的時鐘樹設計提供了一個較優的解決方案，同時對目前自主高性能芯片的后端物理實現提供了工程參考。

1 Multi-tap FlexHtree和Fishbone時鐘結構介紹

以高性能CPU為研究對象，本文主要討論和對比兩種時鐘結構，multi-tap FlexHtree和Fishbone，以下將從結構及特點方面對兩種結構進行簡單描述。

1.1 帶multi-tap的H-tree時鐘樹結構

傳統單一的H-tree多用于Mesh、Fishbone時鐘結構的前級驅動，或者部分對clock skew有要求的電路結構進行時鐘的平衡。圖1中所示帶multi-tap點的H-tree的結構可以與時鐘樹綜合（CTS）相結合來控制整個時鐘樹的clock skew[1]。時鐘根節點（root pin）可以是時鐘輸入端口，也可以是時鐘緩沖器，借助H-tree將時鐘信號傳遞到各個葉節點（sink）。最上面7個驅動器組成了H-tree的“H”形結構，當tap點比較多時可以采用多級的H-tree網絡實現tap點之間的多工藝端角（multi-corner）下時鐘延遲的平衡。最后一級驅動器為子樹的根節點，該子樹可以使用普通的CTS完成。

FlexHtree結構具有實現流程簡單，易于嵌入到整個P&R（布局和布線）流程中實現的特點。并且對于含有存儲器（memory）和宏模塊（macro）的布局也可以采用H-tree實現。還有其對時鐘門控單元（clock gating）結構的復雜度也沒有過多要求。由于其不需要過分關注H-tree上時鐘緩沖器和時鐘主干的幾何對稱性，只要能保證在multi-corner下RC參數的電氣對稱性也可實現clock skew的降低。而對于傳統的H-tree，出于幾何對稱性的考慮，必須對H-tree sink數量以及sink位置進行約束[1]。

1.2 Fishbone時鐘結構

顧名思義，Fishbone時鐘結構就是其形狀類似于魚骨頭的一種時鐘結構。依據主干的條數，通常將Fishbone時鐘網絡分為單魚骨結構、雙魚骨結構與多魚骨結構。圖2中是一個單魚骨結構的示意圖，灰色三角形為前級驅動器，白色三角形為主干驅動器。灰色為時鐘分支。Fishbone前級驅動一般多采用H-tree結構來驅動多扇入緩沖器陣列，根據負載點的數量來選擇金字塔形狀的多扇入驅動緩沖器陣列級數。正是由于最后一級主干驅動器并聯提供的驅動能力，魚骨（trunk）才可以“橫穿”整個floorplan，保證每根魚刺（branch）上的局部緩沖器時鐘到達延時相同。這里的局部緩沖器作為子樹的根節點，使用CTS生成時鐘樹。

Fishbone結構的優點是skew小，時鐘latency短，OCV小，只需要很少的緩沖器，功耗低，布線開銷小，可實現useful skew。缺點就是不能自動化，需要大量手工調整[2]。其比較適用于長條形較為對稱的floorplan。

2 Multi-tap FlexHtree實現

本節主要介紹FlexHtree的時鐘樹綜合流程，對各步驟進行了說明。然后分別討論tap點個數對clock skew的影響，并對比了子樹使用innovus ICTS和CCOPT引擎生成時鐘樹對時序的影響。本節也同時對比了CTS、FlexHtree和Fishbone 3種結構實現時鐘樹的clock skew變化，指導芯片設計者更進一步挖掘3種結構的特點。

2.1 FlexHtree時鐘樹綜合流程

圖3所示為使用Cadence innovus工具綜合帶multi-tap的FlexHtree的流程，先將做完memory、macro和標準單元布局的數據庫作為FlexHtree綜合的起點，此時數據路徑延時優化已經做好。具體步驟：(1)工具依據標準時序約束(SDC)來創建時鐘樹spec；(2)定義時鐘樹繞線規則，對時鐘主干和分支指定不同的繞線規則；(3)確定時鐘樹設計約束，以達到預期的skew、transition和時鐘緩沖器扇出數量；(4)定義FlexHtree創建規范，如時鐘源點、是否對稱、tap點個數及位置區域等；(5)對定義的Flex-Htree主干進行綜合，綜合之后檢查tap點位置及trunk繞線是否比較合理；(6)對放好的multi-tap點創建時鐘以及定義時鐘分組；(7)對定義子樹進行綜合，子樹內部可以采取平衡樹，也可以采取借用useful skew的不平衡樹，此時子樹綜合后的時序不理想就要分析子樹的劃分是否合理，是否依據邏輯關系、物理位置進行了合理的掛載，同時要注意單個子樹的clock latency是否過長。

用帶multi-tap點FlexHtree實現時鐘樹的難點在于tap點數量的確定以及不同tap點下合理掛載sink問題。

2.2 不同tap點個數對clock skew影響

本節tap點子樹使用了ICTS引擎進行平衡樹生成，保證tap點以下子樹內的clock latency也能做平。為了探討不同tap點對clock skew的影響，分別選取了4、6、8、18個tap點生成FlexHtree，圖4為tap點個數與clock skew分布關系圖。橫軸為clock skew范圍，每50 ps一個步長，縱軸是各clock skew區間下條數占總條數百分比。

從圖4中可以看出，菱形setup折線的峰值點主要出現在-150 ps～125 ps區間內，圖4(b)和圖4(c)skew分布比較集中于-150 ps～0 ps范圍，這與工具使用負的useful skew來修保持時序（hold）違反有關系；圖4(b)和圖4(c)中正的useful skew集中于25 ps～100 ps，說明工具將時鐘樹做得比較平衡，而圖4(a)和圖4(d)比較離散，時鐘樹做得不是很平。對hold折線來說，圖4(b)和圖4(c)的skew分布更為集中在-75 ps～0 ps和25 ps～175 ps這兩個區間，因此其setup時序好于其他兩者。圖4(c)中clock skew更為集中在-75 ps～0 ps以及25 ps～125 ps區間，這說明8個tap點在兼顧setup時序的同時也修了hold。從4個圖中可以看出8個tap點下clock skew較小，且比較集中， setup和hold好于其他3種情況。

2.3 Multi-tap FlexHtree tap點合理劃分分析

為了深一步搞清楚8個tap點下時序好的原因，圖5提供了8個tap點FlexHtree在floorplan中的sink分布。從圖中可以看出，本設計為典型的長方形結構，memory成對稱放置，沿上下出pin區域左右兩邊分別歸屬于l3c_pipeline_0和l3c_pipeline_1 module。圖中8塊位置用不同顏色以及邊界折線區分開來，同時在相應區塊中標記了sink所屬module，高亮的直線為8tap點H-tree結構。這樣的tap點劃分充分考慮到了sink點的物理位置以及module間交互（talk）關系，避免了tap點與sink距離過遠和tap點下所帶sink數過大導致的子樹clock latency偏大，從而不利于子樹間talk path時序的收斂。圖5中module的切分考慮到了減少talk path，更多將某些小的module都掛載到一個tap點下，因此這種8個tap的定義才獲得了時序容易滿足的好處。

表1為8個tap點所帶sink數目以及tap點common path clock latency（簡稱CPCL）在子樹平均clock latency中百分比。從表中可以看出Htree_tap0下面掛載sink數量最多，對應圖5liu_pre_processor module所在區域；Htree_tap1下掛載sink數量次之，對應圖5 L3c_cfg和L3c_pipeline_0 module所在區域；Htree_tap4下掛載sink數量最少，對應圖5中間右下位置L3c_pipeline_1 module區域。其他tap點下掛載sink數量基本接近。8個tap點下CPCL都在40%以上，這樣OCV對tap點下sink的影響就沒那么大。從tap點下sink數量與CPCL的對應關系看，Htree_tap0和Htree_tap1并沒有因為sink數量多平均clock latency就越大，出現這種情況說明工具對tap0和tap1 sink切分合理，子樹下sink clock latency做得比較平。從另外一個方面來看，8個tap點的CPCL百分之間偏差不大，8個子樹之間做得也比較平，這樣對子樹間hold響主要就是OCV了。所以，分析FlexHtree做得好不好，可以從子樹sink module劃分、物理位置、子樹sink數目和CPCL百分比出發。

圖6為8個tap點在5個不同corner下公共clock latency的比較圖。從柱狀圖中可以看出tap點時鐘clock latency在不同corner下的偏差不超過70 ps，tap點之間的clock latency相差不到3 ps，這也證實了前面1.1節所提到的FlexHtree特點：multi-corner下RC參數的電氣對稱性，以及tap點之間的RC參數電氣對稱性。這樣保證了各corner下時序的一致性。

2.4 使用平衡和非平衡樹綜合tap點子樹

本節中討論了分別使用innovus的ICTS和CCOPT引擎綜合tap點子樹的時序結果，如表2、表3所示，表格中wns（worst negative slack）代表時序違反最差路徑，tns（total negative slack）代表所有時序違反路徑的違反值之和。兩表格中的setup和hold結果均為postroute階段innovus報出的結果。從表2和表3中wns和tns結果來看，8個tap點效果最好，不論setup和hold；tap點多的情況下hold的wns和tns會好于tap點少的情況。

將表2與表3進行比較可知，使用CCOPT引擎綜合的子樹對于4個、6個和8個tap點時wns和tns均會變差，但tap點為18個時，setup的wns和tns會變好。因此可以得出如下結論：tap點多更適合于降低hold違反條數，在tap點比較多情況下，使用CCOPT引擎綜合子樹的時序效果好于ICTS引擎。

3 3種不同結構實現時鐘樹時序、面積和功耗比較

本節將3種不同結構時鐘樹FlexHtree、CCOPT和Fishbone從時序、面積和功耗方面進行比較，進而選出一種更優的時鐘樹實現方案。從表4中可以看出8個tap點的FlexHtree setup和hold時序均要好于CCOPT和Fishbone結構，從側面也反映了8個tap點方案對clock skew控制要好于另外兩種結構，并且其density利用率也是最低的，從clock buff count也進一步證明了其使用了較少的useful skew。從average clock latency來看，由于FlexHtree使用了高層繞線，其值要低于CCOPT，但高于Fishbone。從功耗來看，FlexHtree的功耗，尤其是使用ICTS引擎綜合子樹的FlexHtree，其clock network功耗要高于CCOPT和Fishbone結構。表格中一個顯著的特征就是，Fishbone結構時鐘樹功耗最小，這與其占用的布線資源少、使用的時鐘緩沖器少有直接的關系。但是對于Fishbone結構，由于必須手工進行，子樹的劃分是一個難題，本文也只是做了大量的嘗試，但時序結果看起來并未有多少好處。這也是本文選用FlexHtree的原因。

4 結論

本文在innovus工具平臺下建立了帶multi-tap的FlexHtree自動化時鐘樹綜合流程。使用innovus實現了4、6、8和18個tap點的FlexHtree，同時針對tap點子樹要不要做平，分別選用了ICTS和CCOPT進行子樹的綜合。為了更深入地說明為何選用FlexHtree結構，也嘗試了CCOPT綜合和Fishbone手工實現時鐘樹的方案，從clock skew、時序、面積和功耗等方面進行了比較，最終確定了使用FlexHtree方案實現L3 cache設計。同時本文也對FlexHtree tap點合理劃分進行了分析，有利于接下來對tap點位置和sink掛載進一步優化，控制clock skew，實現setup和hold均比較容易收斂的結果。本文的結果也對類似memory比較多的設計提供直接的時鐘樹設計經驗，同時本文的分析方法也可以指導設計者探索時鐘樹物理空間。