不知道为什么用原来系列的标题突然提示字数超出，可能最近知乎更新了标题字数限制。所以我把原来的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的问题以及基本的解决思路。在实际中其实还有很多问题，但是限于篇幅，我们不在这里一一讨论。如果大家有什么问题可以加入后端设计讨论群一起讨论。
至此，CTS系列的三篇文章就都完成了。虽然感觉有不少内容，但是仍然感觉有太多的东西还没有涉及，可能限于本人经验有很多东西也没有讲的很深，毕竟CTS是一个非常耗费心力也是非常容易出问题的一个步骤。
相关文章
如果大家有任何后端技术与职业发展方面的问题，抑或关于数字后端感兴趣的技术话题想要了解和探讨，欢迎关注我的知乎专栏： 数字IC后端设计工程师修炼之路同时欢迎关注微信公众号：数字后端芯讲堂，一起探讨技术，共同提升!
本极术专栏也会同步更新芯片设计后端的技术干货，也请关注数字IC后端设计工程师修炼之路。
