在整个数字后端实现过程中，有多种验证需要保证芯片最终的正常工作，其中时序收敛是非常重要的一环，它确保的是芯片在特定PVT条件下能够达到产品定义的既定性能指标。
时序收敛工作在整个实现过程中阶段主要分为几个阶段：逻辑综合和优化，Pre-CTS优化，Post-CTS优化，Post-Route优化和Signoff工具验证（STA）。由于不同阶段设计的状态有很大差别，时序的计算方法和精确度也各不相同，因此也就衍生出了不同阶段的时序一致性(timing correlation)问题。鉴于实际工作中基本以timing correlation或者correlation称呼此类问题，故下文中均采用英文而非中文翻译指代此概念。
通常狭义的timing correlation指的是PnR和Signoff之间的correlation，然而更广义上来看从综合开始后的每一步之间基本都涉及timing correlation的问题：
影响correlation的因素方方面面，既有工具和算法层面的原因，也有约束和设置的原因。在工艺越来越先进的今天，timing correlation问题已经成为后端设计中必须重视的课题。我把所有可能影响timing correlation的因素归结为以下12类：
不同的因素肯定需要不同的办法去解决或者降低它对timing的影响。接下来我们将挑选一些重要的因素讨论一下问题产生的原因和可能的解决办法。
1) Library/Tech文件和Constraints(SDC)
很多人一说比较timing的correlation就直接对着WNS/TNS的数字去看，细致一点的也最多就是对照的timing path一级一级地比较delay/cap/transition等参数，如果发现每一级都相差一点导致一条path的slack相差了几十ps，大部分人就卡住不知道如何继续分析和解决。这种做法当时然是一条可行的路径，但是某些时候却属于本末倒置，因为对timing影响最大的library, tech file和sdc也有可能有问题，最典型的问题就是文件版本不一致。比如：dc/icc2用的tluplus文件版本和starrc用的nxtgrd版本不一致；比较新版本的ICC2可以直接用starrc的nxtgrd文件抽取RC而实际却仍然在用tluplus文件；综合使用的lib版本和signoff工具使用的lib/db文件版本不一致；甚至sdc版本不一致等问题都可能导致timing correlation出现问题。因此建议在比较timing结果的时候先要确认所有输入文件和对应的约束文件是否一致。
2) Synthesis/Place/Route/RC抽取引擎
EDA工具中经常会有各种所谓‘引擎’的说法，如综合mapping和优化引擎、place引擎、绕线引擎等，其本质是EDA工具的一些核心算法。即使是针对完全相同的设计输入来说，不同的工具算法给出的最终结果很可能完全不同。因此不同工具之间或者是同一工具在不同设计阶段采用不同算法导致的correlation问题一直是芯片实现过程中的难题。此类问题大多是EDA厂商在不断迭代算法或者工具来解决。典型的例子如多年前开始兴起的physical aware synthesis (DCG/DCNXT/Genus)，即在考虑物理约束的前提下在综合阶段调用place的算法摆放cell，估算绕线和cell delay，从而获得比wire load model更准确的时序信息。而在不同设计阶段如综合和Pre-CTS、Post-CTS、Post-Route与Signoff之间的correlation问题，一方面可以通过调整RC scaling的方式来平衡不同绕线和RC抽取引擎的差别，另一方面近几年提出的'fusion'或'融合'概念则给出了另外一种解决方案。
其根本思路是可以在某些设计阶段调用其他工具或者其他设计阶段的算法来降低不同算法导致的差别，简单来说就是算法的统一。举两个比较典型的例子：place阶段一方面可以选择调用综合工具的逻辑优化引擎来优化逻辑深度和时序，另一方面可以调用CTS的引擎做early clock tree来模拟真实的时钟树；Post-CTS或者place阶段调用类似真实的绕线引擎来减小global route和detail route之间的误差；通过设置rc scaling来尽量统一不同RC抽取工具和算法在计算上的误差；Post-Route阶段调用StarRC引擎和PT计算delay的算法来增强PR工具和Signoff工具的correlation等。这类方案的典型以现在的fusion compiler/icc2，Genus iSpatial和Innovus为代表，在先进工艺下的复杂设计中已经有较为普遍的应用，效果还是不错的。
3) EDA行为和工具变量设置
在不同的工具中可能会有针对某些工具行为的类似设置，如果这些设置没有完全一致，很有可能导致不同工具中看到的时序结果略有差别。这类问题一般出现在同一个EDA公司的不同产品中，典型的如ICC2和PT或者Innovus和Tempus中。以前者为例，举一个简单的例子：下面的两个变量各自在ICC2和PT中存在， 根据名字和解释可以知道它们控制的其实是相同的工具行为，而类似的变量在ICC2和PT中还有不少，如果想要更好的correlation，尽量把所有的变量设置成相同的值是必不可少的一步。
我整理部分ICC2和PT的变量对照表，有兴趣的同学可以参考一下。
链接：https://pan.baidu.com/s/1BuzCjL47aYdKShLvhdixIQ 提取码：lcwh
4) Margin/Derating(OCV)
当上述几个影响最大的方面都统一之后，需要在更精细的方向调整时序路径的约束，此时重点需要关注的就是timing margin(uncertainty), OCV的derating和RC scaling等。uncertainty的影响主要体现在不同阶段的uncertainty是不同的，尤其是对于setup来说，CTS前后、绕线前后的设计状态都有很大差别，对应的uncertainty也有不同。典型的uncertainty策略如下所示，针对不同的设计、不同的工艺如何确定每一部分的具体数值就成了timing correlation的关键因素之一。这一部分暂不详细展开，以后有机会可以单独开篇讨论一下。
除了uncertainty之外，OCV是另一个比较重要的设置。在不同工艺中OCV的策略很可能不同，有的只需要普通的OCV，有的需要AOCV或者POCV/SOCV甚至SOCV+spatial OCV。尽管如此，由于OCV在这个设计过程中基本会保持一致，因此不会导致不同设计阶段的误差。但是因为不同工具中set_timing_derate命令的行为和使用方法略有不同，因此重要的是要保证同一套OCV策略在不同工具中达到相同的效果。
5) Noise (SI问题)
Noise 问题本身可以放在uncertainty这部分来解决，但是单纯地把noise引起的violation通过加margin来解决有时候会造成过约束和过优化，从而消耗无谓的面积和资源。为了尽量降低noise的影响，可以事先选择在timing critial的path上设置NDR或者shileding，也可以插入guide buffer引导place和route避开绕线资源紧张或者aggressor比较密集的区域，同时可以选择在少量特定的path上额外增加一些margin从而降低整体的过约束风险。
6) Dummy Metal (Metal Fill)
Dummy metal的问题在先进工艺下的影响更加明显。其本质原因在于，先进工艺下的net delay占比更大，而对于某些比较长的金属线或者周围绕线比较少的长线，加入dummy后对net本身的capacitance有较大影响，从而导致net delay和cell delay都相对不加dummy时有较大变化。针对此类问题EDA厂商也分别提出了virtual metal fill或者PR阶段调用工具插入dummy进行优化的方法(ICV-in-Design)。核心思路就是带着dummy进行绕线后的优化，从而尽量模拟真实的RC抽取环境来降低dummy metal的影响。
最后介绍一下在实际分析correlation的工作中大家可能会看到的类似这样的图表，一般用它表示correlation的好坏，其背后的数据含义是：取不同工具或者不同设计阶段中的多条(几千或几万)完全相同路径的timing path的slack或者clock/data delay来比较，如果它们的数值完全一样则都二者相除的数值会落在中间的红线上，反之则会落在红线附近，距离红线越近则说明时序的correlation越好。
以上就是调整timing correlation的一些常见思路，如果大家还有其他好的想法欢迎在评论区讨论~
来源：数字后端设计芯讲堂
作者：阎浮提推荐阅读
如果大家有任何后端技术与职业发展方面的问题，抑或关于数字后端感兴趣的技术话题想要了解和探讨，欢迎关注我的知乎专栏： 数字IC后端设计工程师修炼之路
同时欢迎关注微信公众号：数字后端芯讲堂，一起探讨技术，共同提升!
本极术专栏也会同步更新芯片设计后端的技术干货，也请关注数字IC后端设计工程师修炼之路。
