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

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

文章右侧广告为官方硬广告，与吾爱IC社区无关，用户勿点。点击进去后出现任何损失与社区无关。

今天，小编将手把手教你如何 debug clock tree latency。对的，你绝对没有看错，的确是手把手教会，而且是认真看完一定能学会的那种。是不是有点小激动呢？那么，我们开始进入主题吧。

1. 查看 log 分析 clock tree 长度

认真看过 innovus 的 cts log 的小伙伴们，一定对**C****lock 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 -longest] 0] -to [lindex [get_ccopt_skew_group_path -skew_group -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？

如果还有问题，欢迎加入小编的知识星球，让我们一起学习成长！每天成长一点点，经过时间的复利效应，一定能成大器！不要小看你走的每一小步，因为它正在决定你的人生道路！

另外，因为公众号更改推送规则，小编分享的每篇干货不一定能及时推送给各位。为了避免错过精彩内容，请关注星标公众号，点击 “在看”，点赞并分享到朋友圈，让推送算法知道你是社区的老铁，这样就不会错过任何精彩内容了。

小编知识星球简介（如果你渴望进步，期望高薪，喜欢交流，欢迎加入 ****）：

在这里，目前已经规划并正着手做的事情：

• ICC/ICC2 lab 的编写

• 基于 ARM CPU 的后端实现流程

• 利用 ICC 中 CCD（Concurrent Clock Data）实现高性能模块的设计实现

• 基于 ARM 四核 CPU 数字后端 Hierarchical Flow 实现教程

• 时钟树结构分析

• 低功耗设计实现

• 定期将项目中碰到的问题以案例的形式做技术分享

• 基于 90nm 项目案例实现教程（ICC 和 Innovus 配套教程）

• 数字 IC 行业百科全书

吾爱 IC 社区知识星球星主为公众号” 吾爱 IC 社区” 号主，从事数字 ic 后端设计实现工作近八年，拥有55nm,40nm,28nm,22nm,14nm等先进工艺节点成功流片经验，成功tapeout 过三十多颗芯片。

这里是一个数字 IC 设计实现高度垂直细分领域的知识社群，是数字 IC 设计实现领域中最大，最高端的知识交流和分享的社区，这里聚集了无数数字 ic 前端设计，后端实现，模拟 layout 工程师们。

在这里大家可以多建立连接，多交流，多拓展人脉圈，甚至可以组织线下活动。在这里你可以就数字 ic 后端设计实现领域的相关问题进行提问，也可以就职业发展规划问题进行咨询，也可以把困扰你的问题拿出来一起讨论交流。对于提问的问题尽量做到有问必答，如遇到不懂的，也会通过查阅资料或者请教专家来解答问题。在这里鼓励大家积极发表主题，提问，从而促进整个知识社群的良性循环。每个月小编会针对活跃用户进行打赏。

最重要的是在这里，能够借助这个知识社群，短期内实现年薪百万的梦想！不管你信不信，反正已经进来的朋友肯定是相信的！相遇是一种缘分，相识更是一种难能可贵的情分！如若有缘你我一定会相遇相识！知识星球二维码如下，可以扫描或者长按识别二维码进入。目前已经有697位星球成员，感谢这697童鞋的支持！欢迎各位渴望进步，期望高薪的铁杆粉丝加入！终极目标是打造实现本知识星球**全员年薪百万的宏伟目标 **。

欢迎关注 “吾爱 IC 社区”

微信号：ic-backend2018

https://mp.weixin.qq.com/s/RUUed1g8X9ul-ST-cZIfuA