在時鐘樹的設計中，有很多方式處理分頻時鐘，常見的無外乎兩種模式：

• 時鐘二分頻器（reg-clkgen）
• 門控時鐘

二者在功能上略有不同，比較的大差異是前者可以簡單的實現(xiàn)50%占空比，后者卻對功耗友好同時降低了實現(xiàn)難度。這里結合INVS在CTS的手法，一起了解一下INVS對二者的處理差異。閑言少敘，ICer GO!就后端工具而言，CTS是其三大引擎之一，在當下設計的高工藝、高性能的背景下，CTS的重要性越來越凸顯，之前項目一鍵通的CTS方式，已經(jīng)越來越不能滿足日益提升的QoR訴求了。

INVS ccopt 系統(tǒng)簡介

INVS在useful skew顯然具備強大的優(yōu)勢，其中的ccopt flow，擁有靈活，高效和用戶友好等多種特性，其獨特的思維方式，給用戶在CTS階段提供了更多的選擇和漂亮的QoR數(shù)據(jù)。從SDC到ccopt系統(tǒng)轉(zhuǎn)化，讓INVS采用一種類似數(shù)字孿生（digital twins）的方式，將SDC里邊的相關命令，一一映射到ccopt系統(tǒng)中，主要來自于下列三個主命令：

• create_ccopt_clock_tree <=> create_clock
• create_ccopt_generated_clock_tree <=> create_gernerated_clock
• set_ccopt_property <==> other CTS setup

通過這種轉(zhuǎn)義/隔離，巧妙的將ccopt構建成一個CTS warpper，將CTS的實現(xiàn)和SDC進行隔斷。這樣做的好處有以下幾點：

• SDC里邊的配置和設定，可以在ccopt系統(tǒng)里邊進行修正和調(diào)整，而無需讀入CTS專用的SDC
• CTS的配置通過導出可讀文件進行抽取，繼承和維護：create_ccopt_clock_tree_spec
• 在ccopt_design開始之前，可以靈活使用set_ccopt_property 命令干預ccopt的實現(xiàn)方式，而不用擔心對原生的SDC產(chǎn)生影響。

用戶可以在CTS階段，放心大膽的使用ccopt系統(tǒng)。鑒于INVS是全局useful skew策略，即使在CTS之后，用戶任然可以使用ccopt命令對CTS結構進行微調(diào)（modify），這樣在后續(xù)的useful skew流程中，INVS仍然會使用ccopt引擎對相關的數(shù)據(jù)進行調(diào)整。

時鐘傳播的單調(diào)性

CTS的實現(xiàn)中，無論是ICC/ICC2還是INVS，都會強調(diào)；unate（單調(diào)性）

• unaet：單調(diào)傳播：譬如：正向單調(diào)性的buffer，反向單調(diào)性的inveter
• none-unate：非單調(diào)傳播：XOR，MUX，F(xiàn)F

具體解釋詳見博主老文；門控時鐘檢查（clock gating check）的理解和設計應用（上）由于每一個sink（sequential leaf）的時鐘都是單沿觸發(fā)（正沿或負沿），CTS階段的重要目標就是計算每一個sink的latency，從而對用戶的max_skew進行收斂，所以這個傳播的單調(diào)性（unate）對CTS的影響就很明顯：可以看到，在FF1的傳播路徑上，CLK時鐘是正單調(diào)性，這樣計算CLK-> FF1’CK的路徑的時候CTS工具會只會看正沿。但是到了CLK->FF2’CK的路徑上，由于XOR的none-unate特性，CTS工具計算latency的時候需要同時關注正相關和負相關的兩種情況，在late和early的兩種corner的影響下，這個計算量會成倍的增加，同時也會對實際的clock tree做了悲觀化。因為實際情況下：XOR的enable大概率是一個半靜態(tài)信號，這個會間接提高CTS的難度。由于設計的不明確性，可以用過約束來歸類這種問題。

時鐘二分頻器（reg-clkgen）和CG

從上述時鐘CTS實現(xiàn)的角度來看，基于寄存器的時鐘二分頻器（reg-clkgen）是典型的none-unate器件，而通常的CG則是一個典型的unate器件。所以，從時鐘樹構建的上看，CG是一個被推薦的時鐘網(wǎng)絡結構，但時鐘二分頻器（reg-clkgen）不是的。由于CG的結構類似下列：通常CG的尾部是一個or或者一個and，在std-lib中，這兩類門很常見，通常會有很多種驅(qū)動類型，這種正是CTS需要的風格：功能單一，驅(qū)動多樣，這個對于構建CTS會非常友好。反觀寄存器，相較or/and，不會有這么多的選擇類型，加之延遲較大，這個也會間接影響clock latency的質(zhì)量

時鐘二分頻器的CTS實現(xiàn)

對于傳統(tǒng)的組合邏輯，CTS實現(xiàn)無非面臨兩種選擇：

• 單調(diào)性傳播：AND，OR，CG， BUF， INV
• 非單調(diào)性傳播：MUX、 XOR 。、

這樣的傳播的簡單之處在于：由于是組合邏輯，時鐘可以一路傳播，不會被阻擋。但是對于采用寄存器實現(xiàn)的時鐘二分頻器（reg-clkgen），由于FF在CTS的傳統(tǒng)理解下是屬于一個sink器件，時鐘的傳播會自動在sink器件截止，所以任何穿越FF的時鐘都需要用戶單獨定義。

# root clock create_clock -name CLK [get_port CLK] -period 1 -waveform {0 0.5} # generated clock create_generated_clock -name gen_clk1 -source [get_port CLK] -divided_by 2 -master_clock [get_clock CLK] [get_pin FF1/Q] 

對于上述拓撲結構，CTS的難點不在于divided信號，而在于gen_clk1_enable。眾所周知，從CLK向下看，F(xiàn)F1/FF_A/FF_B同屬于CLK domain，但是由于FF1的特殊性，會導致FF1‘D上的時序會成為一個gen_clk1時鐘路徑上的檢查點，這個有點像clock gating檢查，但又不全是。對于傳統(tǒng)的CG檢查，INVS有自己獨到大處理方式。對于這類檢查，INVS提供了一個有趣的配置選項：這個extract_clock_generator_skew_groups的選項是說：如果配置為true（default value），那么ccopt在創(chuàng)建clock_tree_spec的時候，除過正常的基于clock的-auto_sink模式進行skew_group創(chuàng)建，還會基于ff_clkgen結構的分頻時鐘（時鐘二分頻器）再獨立創(chuàng)建一個使用 _clock_gen打頭的新的skew_group，這個SG會包括這個ff_clkgen的所有fanin以及它自己，和原始的SG相比，這個SG擁有更高的優(yōu)先級。

create_ccopt_skew_group -name CLK_SG -source clk -auto_sinks create_ccopt_skew_group -name _clock_gen_CLK_FF1_SG -source clk -sinks {FF_A FF_B FF1} -rank 1 

這種處理方式需要用戶格外注意，如果用戶擁有類似下列更為復雜的拓撲結果，INVS默認的處理方法可能并不適用于你的設計：由于這里會有下列的timing path

• FF_A/FF_B -> FF1
• FF_A/FF_B/FF1 -> FF3/FF4

從CTS角度而言，上述FF需要統(tǒng)一做平，如果使用了默認的INVS處理方式，可能會產(chǎn)生意想不到的結果。如果不想使用默認SG的處理方式，請將這個變量設定為false。個人理解**：從INVS而言，上述拓撲結構應該是不是一個典型的設計：既然已經(jīng)是ff_genclk的enable信號了，那么就應該是一個類似半靜態(tài)信號，這個不應該是一個關鍵路徑，反言之，這個半靜態(tài)信號，更應該專注于gen_clk1的生成，而非其他用途。同樣FF1既然是一個gen_clk的定義點，那就不應該出現(xiàn)clk2data的情形。一個比較合理的設計應該類似下圖：**但是，在當今百家爭鳴的年代，已經(jīng)很少看到有人可以靜下心來仔仔細細的研究coding style了，這個時候還想TO，那么靈活運用后端工具進行補刀，可能是一種適應當下情景的變通方式吧。

【敲黑板劃重點】

靈活使用ccopt，而不是簡單的一路回車，可能會去的意想不到的收獲