今天,小编将手把手教你如何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越长越好,请问这样做的好处是什么呢?(面试必问!此处划重点!)
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?
联系客服