手把手教你如何在Innovus中分析clock tree質量

今天，小編將手把手教你如何debug clock tree latency。對的，你絕對沒有看錯，的確是手把手教會，而且是認真看完一定能學會的那種。是不是有點小激動呢？那么，我們開始進入主題吧。

1.查看log分析clock tree 長度

認真看過innovus的cts log的小伙伴們，一定對Clock DAG這個關鍵詞非常熟悉。這個關鍵詞附近的信息類非常大，而且非常有用。因此，我們可以利用grep將這部分內容抓取出來。可以通過使用下面的命令來抓取并寫到一個新的文件中。

grep -E -A2 'Clock DAG|Primary reporting' cpu_cts_log | grep -v '\-\-' >> info_for_clock_tree_latency_debug.rpt

關于innovus中時鐘樹綜合的幾個步驟，之前這篇文章已經有比較詳細的介紹。如果還不是特別清楚的，可以把下面這篇文章再復習下。

如何在Innovus中做好Clock Tree Synthesis?

主要的步驟分為：

Clustering 

Banancing

Routing of Clock Tree

Post-Conditioning

上面我們想要的文件info_for_clock_tree_latency_debug.rpt已經寫好了，那么我們打開它，大體上內容如下所示：

set_ccopt_property -balance_mode cluster

ccopt_design  -cts

get_ccopt_skew_group_path -skew_group <skew_group_name> -longest

為了更直觀地分析，我們可以通過下面的命令在layout中高亮出最長的那條clock path。

ctd_win （做ctd_trace之前需要執行該命令）

ctd_trace -from [lindex [get_ccopt_skew_group_path -skew_group <skewGroupName> -longest] 0] -to [lindex [get_ccopt_skew_group_path -skew_group <skewGroupName> -longest] end] -color red

由于工具在做時鐘樹綜合時也要考慮盡量將common clock path做長，即時鐘越晚分叉越好，所以分析時最好將top 10的都報出來。common clock path越長越好，請問這樣做的好處是什么呢？（面試必問！此處劃重點！）

時鐘樹綜合CTS技術經驗分享（高薪必備！）

CRPR能補償crosstalk嗎？

source highlighting_worst_ID_paths.tcl （篇幅有限，腳本放在小編知識星球上）

highlightingWorstIDpaths -skew_group my_clk/functional_func_slow_max -number_of_paths 10

執行上述操作后，layout上就已經show出最長的十條clock path，如下圖所示。看到這十條clock path，不知道你有何想法？至少小編是非常有感覺的。你覺得這十條clock path合理嗎？

如果是被別人拖長的clock path，它的clock tree上會有帶ccd后綴的clock inverter或buffer。這點可是debug問題的突破口哦！

因此，我們可以通過展開clock tree的path來做進一步分析。clock inverter/buffer所帶后綴名字的含義，可以通過下面的命令報出來。

show_ccopt_cell_name_info

3.找出physical上最長clock path

上面的分析是報出實際上長tree后最長的clock path。然而，這些clock path往往并非physical上最長的clock path。以上圖為例，報出的那十條clock path顯然不是physical max clock path，明白人一看他們是被“拖后腿的”。因此，我們需要找到那個真正的“罪歸禍首”。

那么，怎么得到physical上最長的clock path呢？通過以下方法能夠快速get！

source finding_geometrically_farthest_sinks.tcl

findingFarthestSink -in_clock_tree my_clk -root clk -skew_group my_clk/functional_func_slow_max

理論上physical 上的max clock path是不能出現任何detour的。因為它的物理位置直接決定整條tree的長度，而且是整條tree latency的瓶頸。

數字芯片設計實現中修復setup違例的方法匯總

如果physical max clock path上存在detour現象，比如上圖中綠色部分所示路徑。一看到這樣的max clock path，就能判斷一定是有問題的。那么看到圖中所示的path，你能指出可能的原因嗎？（面試的時候完全可以畫個圖，然后讓你分析的哦！）

下面簡單列舉常見的幾種原因：

  1.時鐘路徑上存在fixed的clock cell且cell擺放位置不合理

get_db [get_db clock_trees .insts -if { .place_status == fixed }] .name

  2. floorplan相關

比如memory的channel留的不好，比如channel的blockage類型加的不對等。

  3.power domain相關

比如跨power domain的情況。

數字IC后端時鐘樹綜合專題（OCC電路案例分享）

如果分析后發現physical上最長的clock path是合理的，那么這條tree的clock latency就大體上鎖定在這個范圍了。但是，如果你想進一步優化clock tree latency還需要做進一步的探索。這些細節做好就看可以讓你做出來的東西比別人要好。

我們通過命令報出某個sink點的tree上的各種信息，比如各個clock tree上cell delay，net delay以及各個clock cell的cell類型。

以下圖為例，CTS_ccl_buf_00379這顆cell的delay為0.102ns，前一級output到當前CLKBUF A pin的net delay為0.003ns。假如你發現clock tree上net delay普遍比較大，接近甚至大于cell delay，那可能會有比較大的問題。

【思考題】那么如果net delay普遍比較大，請問有何潛在風險？

為了進一步分析net delay的異常情況，我們可以把每段clock net的詳細信息都報出來。這些信息包括net route type，每段net的layer分配情況和每段net的總長度，如下圖所示。看到這些信息是不是覺得太贊了。再也不用不斷放大縮小去看每段net的各種信息了。

這樣豈不是可以省下很多時間來打游戲了？

source calculate_path_net_length_layer_wise.tcl

calculatePathNetLengthLayerWise -skew_group my_clk/functional_func_slow_max  -sink proc0/rf0/u0/u0/rfd_reg_75_25/DFF/C

以上圖為例，我們發現CTS_20這段net大都使用低層metal來走線，高層反而很少用。這很明顯是存在問題的，這個會導致net delay偏大。這樣就可以定位到net delay偏大的原因，然后做進一步分析。

解決好net delay偏大的問題，后期timing signoff你會更輕松。細節決定成敗。文中所用到的腳本可以前往小編知識星球進行下載。

好了，今天的內容分享就到這里。下期我們將繼續分享如何在innovus中debug clock skew專題。看到這里你是否也學會了如何分析clock tree latency？