数字芯片设计实现中修复setup违例的方法汇总

setup的分析与优化贯穿数字芯片设计的整个过程，也是每位数字IC设计工程师必须掌握的基本技能之一。最好在开始后端实现之前就获得一个没有Setup违反的网表（Gate level Netlist），小编今天将从前端设计到后端实现的流程逐一讲解每个阶段建立时间（setup time)的分析与优化方法。

还有需要注意的是，Setup违例的修复和Hold违例的修复有很大的不同，Setup的违反随着布局到布线阶段的推进，它是越来越恶化的。而Hold违例，线延迟反而有益于Hold的修复的（为何修hold violations之前做leakage优化？），因此存在少量的违反是没有问题的。因此，在开始下一阶段的setup修复之前，最好将本阶段的Setup违反都清掉。

1.逻辑综合阶段就有Setup违例

在DC中用Retime或者Pipeline的方法修复。这种情况一般是数字后端设计实现工程师在实现过程中，发现最critical path上的逻辑很复杂，而且几乎没有用来修transition的buffer或者inverter（通俗点讲就是没有走路的buffer）。这说明本条最critical path不是由于floorplan导致的，而是design本身要实现某个功能所需要的逻辑运算比较复杂导致的setup 违例。这个时候后端工程师不应该在那么硬着头皮调时序，而是反馈给前端工程师，并提出是否可以加寄存器，用pipeline的方式来从根源上解决时序上的违例。其实在做综合的时候，有可能能看到这种时序违例的（如果是DCT综合肯定可以看到）。如果你是一个比较资深的工程师，你应该提前就能预料到，并与前端设计进行沟通解决。

综合阶段利用auto-ungroup和boundary timing优化修复。大部分情况下我们是不打开这两个选项的，但是它确实能够得到一个相对较好的timing结果。如果采用auto-ungroup和boundary timing优化，design中的层次可能会被打散，不保留原来的hierarchical。cell的层次被打散后，一方面后端实现时不好分析模块的逻辑关系，另外一方面是最重要的，也是最致命的，就是万一将来要在某个地方做功能上的ECO（不幸边界被优化了），那个时候就特别郁闷了，eco难度会很大。所以对于比较成熟的模块，其实完全可以打开这两个选项的。

细分group_path。将某些重要的逻辑单独拎出来，设为一个group_path，并给与一个相对高的权重weight。另外就是细分group path后，timing优化力度会比较好。

Base DCT flow。默认情况下DC综合是基于zero-wire-load model来估算delay的，而且是没有physical的信息，比如没有memory的摆放。所以往往DC综合出来的timing 可能很好，一到ICC做place，发现timing 差的一塌糊涂。所以很多时候建议还是做DCT的综合，综合的效果与ICC/ICC2的一致性会比较好（写到这里，有发现一个topic可以写，“如何tune DCT和ICC的timing一致性”，这个近期就会开始写）。

2.布局布线阶段的setup违例

Place之后有较大setup violations。这个阶段出现较大violation普遍只有三种可能性。第一，floorplan不合理（本身block的形状，port位置，memory以及IP的位置不合理），解决办法显然是改floorplan。第二，设计上的问题，需要做retiming或者Pipeline。第三，可能模块利用率太高，congestion比较严重，从而影响setup。

如果setup violation比较小，则可以跳过（violation多少才叫合适，必须做到心里有数），或者通过useful skew（ICC/ICC2支持CCD的功能，自动帮你借timing），设group_path并设置一个相对较大的weigh，设置layer optimization，用高层来走线等方法来解决（方法实在是太多了，这里就不一一列举）。

CTO之后存在较大setup违例。如果place timing 是OK的（关于如何看icc中的timing是否可以接受，最近会推送一篇文章关于“如何调ICC和Primetime的一致性，加速timing closure”），cto之后结果与place存在较大偏差，那么你的clock tree很有可能是有问题的。首先需要对比这两个阶段的timing，分析setup为何变差？其次，找到原因后，对症下药，然后就可以收工，继续接下跑route。

Route后存在较大setup违例。如果cto timing是可以接受的，route后timing完全废掉，则很有可能是出现route detour，如下图所示。

解放方法：比如解决局部congestion问题，添加guide buffer等方法。当然每个情况都不太一样，具体case具体分析，因此，小编后面会写个如何解决各种route detour的专题。

如果route后setup violation不大，但是比cto之后的大，则需要进行debug。主要分析是否是crosstalk大了还是ocv（On Chip Varation）的影响，抑或是两个阶段timing drc的setting不同导致多插了若干个buffer?总之，建议采用对比分析法来debug。

3.Primetime timing signoff阶段的setup违例

很多人对这个阶段修setup，可能会比较困惑。这个阶段主要有以下两方面：

为了降低leakage，我们拿到Post-layout后的数据后，首先要做leakage的优化（通过size成HVT或者RVT，sizedown）。工具做完leakage优化后，经常会把某些path的setup修废掉了，不要问我为什么，很明显是“工具太强大了呗”。此时，就需要我们再把某些cell size成低阈值的cell，或者sizeup来解决setup的问题。这种情况我相信每个人都做过。但是下面要介绍的情况，你未必干过，不信请往下看。

另外一种情况则是：当项目schedule比较紧，ICC已经做完route，而且timing还不错，且可能比较难重现（费了好大功夫调到这个程度）。但是Primetime中check到有一组寄存器存在较小的违例，比如40ps，且path上的组合逻辑已经最优。碰到这种情况，怎么办呢？重新跑PR flow可能来不及，而且可能不能重现结果，此时的你，是不是愁死了，愁的睡不着觉？小编告诉你，遇到这种情况一定要沉住气。解决问题才是唯一出路。唯一快速的办法就是PT中对clock tree进行ECO，并验证时序（其实就是利用useful skew的概念，人工来调整时钟树）。唯一需要注意的是分析清楚了再动手，看好前后级的timing margin。

举个简单的例子：比如经常碰到clock gating ICG的使能端有setup violation。如果前期没有解决好，PT中将ICG的clock tree人工插入若干对inverter pair（请注意ICG 控制的寄存器的setup maring）。有了方案后就返回到ICC中做eco即可。其他情景希望各位举一反三。

好了，今天的码字就到这里了，原创不容易，喜欢的可以帮忙转发和赞赏，你的转发和赞赏是我不断更新文章的动力。小编在此先谢过！与此同时，吾爱IC社区（52-ic.com）也正式上线了。吾爱IC社区（52-ic.com）是一个专业交流和分享数字IC设计与实现技术与经验的IC社区。如果大家在学习和工作中有碰到技术问题，欢迎在微信公众号给小编留言或者添加以下几种联系方式进行提问交流。