inn之CTS debug小技巧（1）

CTS是后端工程师需要掌握的核心技能之一，网上可以搜到各路大神的分享介绍，理论方面菜鸟就不班门弄斧了，接下来就把自己在工作学习中遇到的一些debug CTS的小技巧分享给大家，一起进步！

在做tree的时候，我们有很多评价指标，比如latency，skew，信号完整性等，基于这些，菜鸟今天想和大家分享两个经验：

1 report_ccopt_skew_groups
这条command报出的skew和latency是从tree的角度，不会考虑si这些影响。比如菜鸟某次发现CTS之后的timing变差，报timing发现launch和capture有比较大的skew，但是skew rpt里面这个skew却很小，就是因为report_timing会考虑si的影响，此时的skew可能会相比skew rpt的大。
如果在CTS之后看到很大的violation，但是 report_ccopt_skew_groups报出来的launch和capture skew没有很大，很有可能是SI的影响，这些都会在rpt里面有展示。如果是SI的影响，就考虑调整NDR来减少其影响。

2 debug CTS 有用的command
在inn中输入"get_ccopt"再tab，可以看到很多有趣的command，例如：
get_ccopt_skew_group_path -skew_group -longest ; #报出max clock path的ID
get_ccopt_property ；#获得tree相关的property

这些command怎么帮助我们去debug clock tree呢？在build完tree之后发现有个skew group latency比较长，这时候我们可以报出来latency最长的一条，command如下：

ctd_win ; # 打开clock tree debug window
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；# 高亮指定skew gourp的最长clock path

但是只看到这一条最长path，获得的信息是有限的，我们可以把最长的N条报出来，看看这个时候common path是不是足够长。先看效果：

如图1，最长的clock path已经被highlight，我们再报出最长的十条clock path,如图2