CTS（下篇）

原来的Clock Tree Synthesis这几个单词去掉了。请谅解~

拖了很久才写了CTS系列的最后一篇，很是抱歉。前段时间项目问题多，想抽出点时间确实比较困难。有时间我也会把出现的问题分享出来，供大家一起学习。

之前我们通过两篇文章大致说了如何制定CTS的策略，以及如何将自己的策略反映到工具中。今天我们主要谈谈如何调用工具执行CTS、时钟树综合过程中工具的行为以及如何debug常见的问题。首先还是回忆以下CTS的基本流程：

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

简言之，工具在CTS时的基本行为是：读取clock的定义以及在何种scenario/view下进行时钟树综合 -> Fix Clock Line DRV(从sink开始) -> 优化每个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的问题以及基本的解决思路。在实际中其实还有很多问题，但是限于篇幅，我们不在这里一一讨论。如果大家有什么问题可以加入后端设计讨论群一起讨论。

原文链接：https://zhuanlan.zhihu.com/p/41075732