数字后端知识点扫盲——CTS（下）

今天要讲的是，如何调用工具执行CTS，时钟树综合过程中工具的行为以及如何debug常见的问题，首先还是回忆一下CTS的基本流程。

在ICC/ICC2中，工具CTS中的基本行为和命令的对应关系如下：

简言之，工具在CTS时的基本行为是：读取clock的定义以及在何种scenario/view下进行时钟树综合 —> FIix clock Line DRV —>优化每个clock内部的skew/latency —>balance 已经定义的clock group的latency —> 对clock上的nets进行绕线。

请大家牢记上面的流程，因为在debug CTS的时候可能会用到上述流程，那么，一般在CTS后经常出现的问题是什么呢？下面我们将分别谈谈。

有些clock line 没有被时钟树综合

检查是否所有的clock line都被综合的常用方法是查看clock line上的DRV。如果某些sink或者clock逻辑上的cell有非常大的max_transition violation，那么很有可能有它们根本就没有被时钟树综合。因为上面我们讲过，工具在CTS过程中的第一步就是fix clock line的DRV。对于出现这种情况的原因，可能是CTS的SDC定义有遗漏，也有可能是设置了错误的clock exception或dont_touch，还有可能是工具因为某些cell的库有问题而没有被正确识别。不管是什么原因，解决的办法就是找出design中CTS是在哪里停下的，并对照自己的SDC和各种设置，同时注意log中的CTS信息，一般都能找到一些线索。

有些clock在CTS后latency 特别长

此种情况的原因一般有两个：自己的latency本身就很长或者由于clock之间的balance导致插入了过多的balance cell。区别这两种情况的方法是，工具在CTS阶段插入的不同用途的cell都有不同的命名规则。比如对于ICC2来说，修DRV的cell名字就是cts_inv或者cts_buf之类的；balance clock内的latency的就是cts_dlydt；balance clock之间的cell名字就带ICDB。所有的命名规则可以参考下图。通过这些命名规则，我们可以很方便地得知是什么原因导致clock的latency过长。对于clock内部来说，我们需要分析clock的sink是否有分布在太远的地方、工具的CTS路径是否合理，有没有迂回、线上delay是否过大、有没有cell/net没有被综合等；对于clock之间，我们需要找到是哪一个或几个clock导致整个group的latency变长，分辨的主要方法就是通过下面的命名规则。

Latency不够短

在CTS中我们永远希望latency能够一短再短，但是有的时候明明距离不远却很难做短。造成这种现象的原因可能有以下几种：CTS中使用的cell不合理，使用了过多太小或驱动能力太弱的cell；CTS的routing rule设置不合理，导致线上delay较大或者cross talk比较严重；target skew/target transition设置太严，导致工具为了获得更小的skew或者transition而插入了过多的cell导致clock级数增加。不管是什么原因，分析的根本方法都在于对照clock源头和sink分布，预估CTS的级数和delay，如果有较大出入都需要引起注意。

以上就是常见的一些CTS的问题以及基本的解决思路。在实际中其实还有很多问题，但是限于篇幅，我们不在这里一一讨论。如果大家有什么问题可以加入后端设计讨论群一起讨论。

至此，CTS系列的三篇文章就都完成了。虽然感觉有不少内容，但是仍然感觉有太多的东西还没有涉及，可能限于本人经验有很多东西也没有讲的很深，毕竟CTS是一个非常耗费心力也是非常容易出问题的一个步骤。如果大家有其他想要了解的内容欢迎留言或者加群讨论。