手把手教你如何在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已经写好了，那么我们打开它，大体上内容如下所示：

从这个文件中可以清楚地知道每个步骤做完的summary，比如clustering，balancing做完后的clock tree的长度，clock tree上所用的buffer、inverter，icg cell数量，clock skew等信息。

从上图中得知，做完balance后的clock tree latency有个比较大的突变，即从clustering的1.224ns变成2.103ns。理论上balance这步只会按照skew group来做各种clock的balance，做完后的tree的长度应该还是在1.3ns左右。对基本概念清晰的同学应该就能猜到这里可能是clock skew group有冲突，导致原来这里的sink要与别的skew group的sink做balance了。因此，需要去检查skew group定义是否正确。

另外，如果你发现clustering后的最大的clock tree latency太大了，怀疑cell 摆放有问题，那么你可以做一个快速版的cts，即只做clustering这步。那么怎么做呢？具体命令如下：

set_ccopt_property -balance_mode cluster

ccopt_design  -cts

是不是有种so easy的感觉？

2.定位最长的clock path

做完clustering后就可以知道整体tree的长度。此时我们可以通过下面的命令报出所有skew group的最长和最短clock path。

report_ccopt_skew_groups -summary 

我们需要重点关注最长的clock path。也可以通过下面的命令来报出max clock path的ID。

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？