1. 时序报告里那个让人头大的CRPR到底是什么做数字后端或者静态时序分析STA的朋友大概率都有过这样的经历打开一份PrimeTime或者Tempus吐出来的时序报告看到路径上标注着CRPR这个缩写旁边跟着一个或正或负的数值心里犯嘀咕——这东西到底扣了多少余量它跟SI、OCV、Min Pulse Width之间又是什么关系更让人抓狂的是同一个路径在不同报告里CRPR的值居然不一样有时候甚至符号都反了。CRPR全称Clock Reconvergence Pessimism Removal中文一般叫“时钟重汇聚悲观量消除”。名字听着拗口但它的本质其实很朴素在OCVOn-Chip Variation分析模式下我们给时钟路径上的发射端和捕获端分别加了derate这会导致公共时钟路径上的延迟被重复计算了两次悲观量。CRPR就是把这部分多扣的悲观量加回来。为什么说它跟SI、OCV、Min Pulse Width都有关系因为CRPR不是一个孤立存在的修正项。它依附于OCV分析框架受SISignal Integrity信号完整性引起的时钟抖动影响同时直接决定了Min Pulse Width检查的准确度。你如果不懂CRPR做出来的时序收敛要么过于乐观导致硅后翻车要么过于悲观白白浪费面积和功耗。这篇文章我打算从实战角度出发把CRPR在SI、OCV和Min Pulse Width三个场景下的真实影响讲透。不管你是刚入行的STA新手还是做了几年但一直对CRPR一知半解的工程师看完之后至少能做到拿到一份时序报告看到CRPR相关的数值心里有底知道它从哪来、该不该信、怎么调。1.1 先搞清楚CRPR的数学本质要理解CRPR得先理解OCV分析的基本模型。在传统OCV模式下我们会对时钟路径上的每个单元和互连线施加一个derate因子。比如setup检查时发射时钟路径用late derate比如1.05捕获时钟路径用early derate比如0.95。问题来了如果发射和捕获时钟共享一段公共路径这段路径的延迟在发射端被乘以1.05在捕获端被乘以0.95但实际上它只有一条物理路径延迟只有一个值。这就产生了悲观量。CRPR的计算公式可以简化为CRPR 公共路径延迟 × (late_derate - early_derate)举个例子假设公共路径延迟是200pslate derate是1.05early derate是0.95那么CRPR 200 × (1.05 - 0.95) 20ps。这20ps就是从悲观量里“捞回来”的余量。但实际工具里的计算远比这个复杂因为公共路径的确定本身就是一个难点。工具需要做时钟路径的追溯clock path tracing找到发射和捕获时钟的公共节点common point然后只对公共节点到发射端和公共节点到捕获端分别计算。公共节点之前的路径才是真正共享的。注意CRPR只对时钟路径生效数据路径不涉及CRPR。而且CRPR只在OCV模式下有意义在flat分析或者没有derate的情况下CRPR恒为零。1.2 为什么SI会让CRPR变得更复杂SI对CRPR的影响主要体现在时钟路径上的串扰crosstalk会导致时钟延迟发生变化。在先进工艺节点比如7nm、5nm甚至3nm互连线之间的耦合电容占比越来越高时钟线上的串扰引起的抖动jitter可能达到几十甚至上百皮秒。当SI分析开启后时钟路径的延迟不再是固定值而是一个受相邻信号翻转影响的动态值。这时候CRPR的计算就要考虑公共路径上的串扰影响是否应该被消除答案是应该但工具的处理方式有差异。以PrimeTime的SI分析为例当开启-si选项后工具会对时钟路径做串扰感知的延迟计算。公共路径上的串扰引起的延迟变化在发射和捕获端都会被计算一次如果不做CRPR就会重复计入。但SI引起的抖动有一部分是随机的random jitter这部分不应该被CRPR消除因为它不是系统性的悲观量。实际操作中你会发现开启SI后CRPR的值通常会变大因为公共路径的有效延迟增加了串扰可能让延迟变大或变小取决于串扰的方向。但变大的幅度不一定等于串扰引起的延迟变化量因为工具会区分系统性偏差和随机偏差。我个人的经验是在16nm以下工艺如果时钟树上的串扰比较严重CRPR的值可能比没有SI时大30%到50%。这个差异足以影响时序收敛的结论所以做SI分析时一定要确认CRPR是否被正确计算。1.3 OCV derate策略如何左右CRPR的大小OCV derate的设置直接决定了CRPR的数值。不同的derate策略会导致完全不同的CRPR结果。常见的derate策略有三种第一种是全局统一derate比如所有时钟路径统一用1.05/0.95。这种策略最简单但CRPR也最大因为公共路径的悲观量被放大了。第二种是分单元类型derate比如时钟缓冲器用1.03/0.97时钟线用1.05/0.95。这种策略更精细CRPR会相应减小。第三种是AOCVAdvanced OCV或POCVParametric OCVderate因子跟路径的级数、距离、单元类型都相关。AOCV下CRPR的计算更复杂因为公共路径上每一级的derate可能都不同。在AOCV模式下CRPR的计算需要逐级累加公共路径上每一级的悲观量。假设公共路径上有三级缓冲器每级的late derate和early derate分别是(1.05, 0.95)、(1.04, 0.96)、(1.03, 0.97)那么CRPR D1×0.10 D2×0.08 D3×0.06其中D1、D2、D3分别是三级的标称延迟。这里有个容易踩的坑AOCV的derate因子通常跟路径的“深度”有关而公共路径的深度计算方式在不同工具里可能不一样。有的工具按公共节点到发射/捕获端的级数算有的按整条路径的级数算。如果你发现CRPR的值跟手算对不上先检查工具的AOCV配置。2. CRPR在SI分析中的真实影响与实操要点SI分析是现代STA流程中不可或缺的一环尤其是在高频设计和先进工艺下。CRPR在SI环境下的行为跟传统OCV有很大不同这一章我结合具体场景拆解。2.1 SI开启前后CRPR的数值变化规律先看一个实测案例。某16nm工艺的CPU核时钟频率1.8GHz时钟树上有大约40个缓冲器最长路径的公共节点在时钟树的第二级。在没有开启SI的情况下CRPR的值大约是18ps。开启SI分析后CRPR变成了27ps增加了50%。为什么增加这么多因为公共路径上的串扰导致有效延迟增加了。具体来说公共路径上有一段长约300um的时钟线旁边有高速数据线并行。数据线翻转时通过耦合电容在时钟线上引入了正向串扰让时钟线的延迟增加了约15ps。这段延迟在发射和捕获端都被计入所以CRPR增加了约15ps × (1.05 - 0.95) 1.5ps不对实际增加的是15ps本身因为CRPR消除的是整个悲观量而悲观量的计算基数是实际延迟。更准确地说没有SI时公共路径延迟是200psCRPR 200 × 0.10 20ps。有SI时公共路径延迟变成215psCRPR 215 × 0.10 21.5ps。但实测增加了9ps说明还有别的因素。后来发现是工具在SI模式下对derate因子做了调整因为串扰引起的延迟变化本身也有不确定性工具会额外加一个SI derate。这个案例告诉我们SI对CRPR的影响不是简单的线性关系工具内部有复杂的建模。你不能只靠手算必须看工具的实际报告。2.2 串扰引起的时钟抖动该不该被CRPR消除这是一个有争议的话题。串扰引起的时钟抖动分为两类一类是确定性的deterministic jitter比如固定模式的串扰另一类是随机性的random jitter比如相邻信号的随机翻转。从理论上讲CRPR应该只消除确定性的悲观量即公共路径上那些“肯定存在”的延迟偏差。随机抖动不应该被消除因为它不是系统性的重复计算。但实际工具的处理方式各不相同。有的工具会把所有公共路径上的SI影响都纳入CRPR计算有的工具只纳入一部分。你需要查看工具的文档确认它的CRPR计算是否包含SI引起的抖动。我个人的做法是在SI分析模式下先跑一次不带CRPR的时序报告再跑一次带CRPR的对比两者的WNSWorst Negative Slack差异。如果差异超过5%就要仔细检查CRPR的计算是否合理。如果差异过大可能是工具把不该消除的随机抖动也消除了导致时序过于乐观。提示在PrimeTime中可以用report_timing -crpr选项来查看CRPR的详细计算过程。在Tempus中对应的命令是report_timing -crpr_detail。2.3 SI模式下CRPR的调试实战调试CRPR问题我通常按以下步骤走第一步确认公共节点。用report_clock_timing -type common_point或者类似的命令找到发射和捕获时钟的公共节点。确认这个节点是否合理。有时候工具找到的公共节点跟你预期的不一样可能是因为时钟树上的某些单元被优化掉了或者时钟定义有问题。第二步检查公共路径上的延迟。用report_clock_timing -type path查看公共节点到发射端和捕获端的延迟。确认这些延迟是否包含了SI影响。第三步手算CRPR。根据公共路径延迟和derate因子手算一个CRPR值跟工具报告的值对比。如果差异超过10%就要查工具的配置。第四步检查SI配置。确认set_clock_uncertainty、set_si_mode等命令是否正确设置。特别是set_si_mode -clock_jitter这个选项它决定了SI引起的时钟抖动是否被计入CRPR。我踩过的一个坑是在某次项目中SI分析开启后CRPR突然变成了负值。后来发现是因为公共路径上的串扰是负向的让延迟变小而工具的derate因子没有相应调整导致CRPR计算出现负值。这种情况需要手动调整derate或者修改SI配置。3. OCV与CRPR的配合从传统OCV到POCV的演进OCV是CRPR存在的土壤没有OCV就没有CRPR。但OCV本身也在演进从传统的全局derate到AOCV再到POCV/LVFCRPR的计算方式也在变化。3.1 传统OCV下CRPR的计算与验证传统OCV最简单也最容易理解。假设时钟路径上所有单元和线都用统一的derate因子比如setup用1.05/0.95hold用0.95/1.05。CRPR的计算就是公共路径延迟乘以derate差值。但这里有个细节公共路径延迟是用标称延迟还是用derate后的延迟答案是标称延迟。因为CRPR消除的是derate引入的悲观量而不是延迟本身。验证方法很简单找一条时钟路径手动计算公共路径的标称延迟乘以derate差值跟工具报告的CRPR对比。如果一致说明工具配置正确。我通常会在项目初期做一次这样的验证确保CRPR的计算符合预期。如果发现不一致优先检查以下几点时钟定义是否有重叠或遗漏公共节点的确定是否正确derate因子是否被正确应用到所有时钟单元是否有例外exception影响了CRPR的计算3.2 AOCV/POCV下CRPR的复杂性与应对AOCV和POCV下derate因子不再是固定值而是跟路径的级数、距离、单元类型相关。这让CRPR的计算变得复杂得多。以AOCV为例derate因子通常存储在一个查找表中输入是路径的级数stage count和距离distance输出是derate值。公共路径上每一级的derate可能都不同所以CRPR需要逐级计算。具体步骤确定公共路径上的所有单元和线对每一级查找对应的AOCV derate因子计算每一级的悲观量D_i × (late_derate_i - early_derate_i)累加所有级的悲观量得到CRPR这个过程手工做很繁琐通常依赖工具自动计算。但你需要理解原理才能在工具报告异常时快速定位问题。POCV也叫LVFLiberty Variation Format更进一步它用统计分布来描述延迟变化而不是简单的derate因子。POCV下CRPR的计算涉及到均值和标准差的操作更加复杂。但核心思想不变消除公共路径上重复计算的悲观量。在POCV模式下CRPR通常表现为一个统计量而不是固定值。工具会报告CRPR的均值和标准差你需要根据这些值来判断时序是否收敛。注意POCV下CRPR的计算对公共路径的确定更加敏感。因为POCV的统计特性跟路径的拓扑结构有关公共节点找错了CRPR的统计量也会错。3.3 OCV derate设置不当引发的CRPR异常案例分享一个真实案例。某28nm项目时钟树上有大约20级缓冲器公共节点在第五级。项目初期用的是全局统一derateCRPR大约是12ps。后来为了更精确改成了分单元类型derate时钟缓冲器用1.04/0.96时钟线用1.06/0.94。改完之后CRPR变成了8ps。但时序报告显示WNS变差了。为什么因为分单元类型derate后公共路径上的缓冲器derate变小了从1.05/0.95变成1.04/0.96但时钟线的derate变大了从1.05/0.95变成1.06/0.94。公共路径上缓冲器多、线少所以整体悲观量变小CRPR也变小。但非公共路径上的线derate变大导致非公共路径的延迟增加WNS变差。这个案例说明CRPR的变化不一定意味着时序变好或变坏要结合整个路径的derate策略来看。调整derate策略时不能只看CRPR要看最终的WNS和TNS。4. Min Pulse Width检查中CRPR的关键作用Min Pulse Width最小脉冲宽度检查是时序分析中容易被忽视但极其重要的一环。CRPR在Min Pulse Width检查中的角色跟setup/hold检查不同但同样关键。4.1 Min Pulse Width检查的基本原理Min Pulse Width检查的是时钟信号的高电平或低电平持续时间是否满足触发器的最小要求。如果脉冲宽度太窄触发器可能无法正确捕获数据导致功能失效。检查的公式大致是脉冲宽度 捕获时钟边沿 - 发射时钟边沿对于高电平脉冲发射边沿是上升沿捕获边沿是下降沿。对于低电平脉冲发射边沿是下降沿捕获边沿是上升沿。在OCV模式下发射边沿和捕获边沿的时钟路径延迟会被分别derate。如果这两条路径有公共部分就会产生悲观量需要CRPR来消除。4.2 CRPR如何影响Min Pulse Width的悲观量Min Pulse Width检查中的CRPR跟setup/hold检查中的CRPR计算方式类似但有一个关键区别Min Pulse Width检查涉及的是同一个时钟的不同边沿而不是发射时钟和捕获时钟。具体来说对于高电平脉冲发射边沿是时钟的上升沿捕获边沿是同一个时钟的下降沿。这两个边沿在时钟树上走的路径可能有一部分是公共的。公共路径上的derate悲观量需要被CRPR消除。举个例子假设时钟周期是1ns高电平脉冲的标称宽度是500ps。上升沿路径的late derate是1.05下降沿路径的early derate是0.95。公共路径延迟是100ps。那么没有CRPR时脉冲宽度 500 100×1.05 - 100×0.95 510ps。有CRPR时脉冲宽度 500 100×1.05 - 100×0.95 - 100×(1.05-0.95) 500ps。可以看到CRPR消除了10ps的悲观量让脉冲宽度的检查结果更接近真实值。在实际项目中Min Pulse Width的违例往往出现在时钟树的末端因为那里的脉冲宽度最窄。如果CRPR没有被正确计算可能会误报违例导致不必要的时钟树优化。4.3 Min Pulse Width中CRPR的调试与优化调试Min Pulse Width中的CRPR问题我通常关注以下几点第一确认时钟边沿的定义。Min Pulse Width检查涉及的是同一个时钟的不同边沿所以时钟的占空比定义必须准确。如果时钟定义有问题CRPR的计算也会出错。第二检查公共路径的确定。对于同一个时钟的不同边沿公共路径通常是从时钟源到分叉点的路径。分叉点之后上升沿和下降沿走不同的路径。确认工具找到的分叉点是否正确。第三验证CRPR的数值。手算公共路径的悲观量跟工具报告的值对比。如果差异较大检查derate因子和公共路径的确定。第四优化时钟树。如果Min Pulse Width违例严重可以考虑优化时钟树减少公共路径上的缓冲器级数或者调整时钟树的拓扑结构让脉冲宽度更宽。我遇到过一个案例某设计的Min Pulse Width违例在时钟树的末端违例值大约是30ps。检查CRPR后发现工具计算的CRPR只有5ps而手算应该是15ps。后来发现是时钟定义中占空比设置错了导致公共路径的确定出现偏差。修正时钟定义后CRPR变成15ps违例从30ps降到10ps再稍微优化一下时钟树就收敛了。5. 常见问题与排查技巧实录这一章我整理了一些实际项目中遇到的CRPR相关问题以及排查思路和解决方法。5.1 CRPR常见异常速查表问题现象可能原因排查方法解决方法CRPR为零未开启OCV模式检查是否有set_timing_derate开启OCV并设置derateCRPR为负值公共路径串扰为负向检查SI分析配置调整derate或SI配置CRPR过大derate因子过于悲观手算对比调整derate策略CRPR过小公共节点确定错误检查时钟定义修正时钟定义CRPR在SI开启后突变SI derate未正确设置检查set_si_mode调整SI配置Min Pulse Width中CRPR异常时钟占空比定义错误检查create_clock修正占空比5.2 独家避坑技巧第一个技巧在项目初期就建立CRPR的基准值。找几条典型的时钟路径手算CRPR跟工具报告的值对比。建立基准后后续任何配置变更导致的CRPR异常都能快速发现。第二个技巧CRPR的调试要结合WNS一起看。不要孤立地看CRPR的值要看它对最终时序的影响。有时候CRPR变了但WNS没变说明CRPR的变化被其他因素抵消了。第三个技巧在SI分析中如果CRPR的值波动很大可以尝试关闭SI的时钟抖动分析看看CRPR是否稳定。如果稳定说明波动是SI引起的需要调整SI配置。第四个技巧Min Pulse Width检查中如果CRPR的值跟预期不符先检查时钟的占空比定义。占空比错了公共路径的确定就会错CRPR也会错。第五个技巧在AOCV/POCV模式下CRPR的计算依赖查找表。如果查找表的配置有问题CRPR会异常。定期检查AOCV/POCV的配置文件确保跟工艺库匹配。5.3 工具间的CRPR差异与应对不同工具对CRPR的计算可能有差异。比如PrimeTime和Tempus在SI模式下的CRPR计算方式就不完全一样。这种差异在先进工艺下可能达到10%到20%。应对方法在项目初期做工具间的交叉验证。用两种工具跑同一组时序路径对比CRPR的值。如果差异较大查清楚原因必要时调整工具配置让两者的结果趋于一致。我个人的经验是不要盲目相信某一个工具的结果。在关键路径上手工验证CRPR的计算确保工具的结果合理。如果工具的结果跟手算差异较大优先相信手算然后查工具的配置。6. 从实战出发的CRPR优化建议最后分享一些我在实际项目中总结的CRPR优化建议。第一合理设置derate因子。不要盲目用1.05/0.95这种保守值。根据工艺库的实际变化范围设置合理的derate。derate越精确CRPR越准确时序收敛越高效。第二重视公共路径的优化。公共路径越长CRPR越大悲观量越多。在时钟树综合时尽量减少公共路径的长度或者让公共路径上的单元延迟尽量小。第三SI分析要适度。SI分析能提高精度但也会增加CRPR的复杂性。在项目初期可以先不开SI快速收敛时序。在项目后期再开启SI做最终签核。第四Min Pulse Width检查要尽早做。不要等到项目后期才发现脉冲宽度违例。在时钟树综合完成后就做一次Min Pulse Width检查确认CRPR的计算是否合理。第五建立CRPR的监控机制。在时序签核流程中加入CRPR的检查项。如果CRPR的值超出预期范围自动报警避免有问题的时序报告流入下一环节。我个人在实际操作中的体会是CRPR不是一个孤立的数值它是OCV分析框架下的一个修正项跟SI、Min Pulse Width紧密相关。理解CRPR的关键不在于记住公式而在于理解它背后的悲观量消除逻辑。当你能手算CRPR并跟工具报告对比时你就真正掌握了它。