马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？注册
x
本帖最后由 ic_learners 于 2020-12-13 10:40 编辑
今天，小编将手把手教你如何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中时钟树综合的几个步骤，之前这篇文章已经有比较详细的介绍。如果还不是特别清楚的，可以把下面这篇文章再复习下。
主要的步骤分为：
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越长越好，请问这样做的好处是什么呢？（面试必问！此处划重点！）
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的瓶颈。
如果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的情况。
如果分析后发现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
| 
/2 
eetop公众号
创芯大讲堂
创芯人才网
发表于 2020-12-7 09:59:34
不回复看不到隐藏内容吗？
