Innovus时序收敛：path group策略配置与自定义分组实战

1. 从时序报告到路径分组为什么path group值得单独拿出来讲数字后端做到时序收敛阶段很多人会陷入一个误区盯着report_timing的slack数字反复调却忽略了这些路径到底被归到了哪个组里。我在带新人的时候发现十有八九的人第一次打开Innovus的时序报告看到path group那一列是懵的——明明只关心setup和hold怎么冒出来reg2reg、reg2cgate、in2reg、reg2out、feedthru一堆分类。更麻烦的是当你试图用setPathGroupOptions去调某个组的effort时发现命令执行了但报告里毫无变化原因往往是你调的那个组根本不是这条路径实际归属的组。这就是path group这个机制的核心价值所在它不是一个可有可无的报告分类标签而是Innovus做时序优化时的调度单元。工具在决定先修哪条路径、给多少优化资源、用什么策略去修的时候依据的就是路径所属的group以及这个group上配置的选项。换句话说path group是你和优化引擎之间的一个控制接口你通过它告诉工具“哪类路径更重要、哪类可以放一放”工具则据此分配算力和策略。上篇我们聊了path group的基本概念和默认分组逻辑这篇重点落在策略配置和实际应用上。具体来说会覆盖几个实操中绕不开的问题setPathGroupOptions里那些参数到底怎么选、weight和effort之间是什么关系、什么时候该自定义path group、以及path group和useful skew、MMMC这些机制怎么配合。适合已经能跑通基本流程、开始追求时序收敛质量的后端工程师参考刚入门的同学也能从中理解工具优化决策的底层逻辑。2. path group策略配置的核心参数拆解2.1 setPathGroupOptions的参数体系与作用机制setPathGroupOptions是控制path group行为的核心命令它的参数大致可以分成三类资源分配类、优化策略类和约束覆盖类。资源分配类包括-effort和-weight前者决定工具在这个组上投入多少优化力度后者决定多个组竞争资源时的优先级排序。优化策略类主要是-targetSlack和-slackAdjustment用来设定该组的收敛目标和松弛调整量。约束覆盖类则涉及-earlyLaunch、-lateCapture这类对launch和capture时钟路径的干预。先说说-effort。它有三个档位low、medium、high。默认情况下大多数组是medium。这个参数的本质是告诉优化引擎“在这个组上愿意花多少迭代次数和优化动作”。设成high之后工具会尝试更多的size up、更多的buffer插入、更激进的restructure代价是运行时间上升而且可能对相邻路径产生副作用。我实测下来high effort用在关键组上效果明显但如果所有组都设high等于没设——资源被摊薄整体收敛反而变慢。-weight是一个相对值默认是1。它的作用场景是当多个组的路径在同一个优化窗口里竞争时工具按weight比例分配优化机会。比如reg2reg设weight 3reg2out设weight 1那么在资源紧张时工具会优先保证reg2reg的优化质量。这里有个容易踩的坑weight不是越大越好。设得太悬殊会导致低weight组长期得不到优化最后那些组的违例积累到无法收拾。我的经验是weight比例控制在1:3以内比较稳妥极端情况不超过1:5。-targetSlack这个参数值得单独说。它允许你给某个组设定一个比全局约束更紧或更松的目标。比如全局setup约束是0你可以给某个关键组设targetSlack 0.05让工具往正slack方向多推一点留出余量。反过来对于一些非关键组设一个负的targetSlack可以让工具不要在那上面浪费资源。这个参数在时序紧张、需要精细分配优化预算的时候特别好用。2.2 effort与weight的配合逻辑资源分配的底层原理很多人搞不清effort和weight的区别觉得两个都是“加大力度”的意思。实际上它们的作用层面完全不同。effort是组内的优化深度weight是组间的资源竞争权重。打个比方effort像是给一个部门拨的预算weight像是这个部门在公司整体资源分配中的话语权。预算多但话语权低可能钱还没花出去就被别的部门抢走了资源话语权高但预算少抢到了资源也干不了太多事。实际配置的时候我通常的套路是先给所有组设统一的medium effort和weight 1作为基线跑一轮看报告找出违例最严重、对整体WNS影响最大的组把这个组的effort提到highweight提到2到3。然后再跑一轮观察其他组有没有因为资源被抢而恶化。如果出现恶化要么适当回调weight要么给恶化的组也提一点effort。这个迭代过程一般两到三轮就能找到平衡点。有一个细节容易被忽略effort的提升是有边际递减的。从low到medium的提升幅度通常很明显从medium到high的提升幅度取决于设计本身的可优化空间。如果一轮high effort跑下来WNS只改善了几个ps那说明这个组的瓶颈不在优化力度上而可能在约束设置、floorplan或者时钟结构上继续加effort是浪费机时。2.3 targetSlack与slackAdjustment的精细调控-slackAdjustment这个参数用得少但很关键。它是在计算组内路径优先级时对slack做一个偏移。举个例子某个组里有两条路径slack分别是-0.1和-0.15正常情况工具会优先修-0.15那条。但如果你给这个组设了slackAdjustment -0.05那么工具看到的有效slack就变成-0.15和-0.2优先级排序会变化。这个参数的典型用途是让工具更关注某些特定类型的路径或者在多corner分析时对齐不同corner的优化重点。targetSlack和slackAdjustment经常配合使用。一个常见的组合是给关键组设targetSlack 0或略正同时设一个小的负slackAdjustment让工具在满足目标的前提下仍然优先处理最差的路径。这种组合在时序余量紧张、需要“保底线”的项目里很实用。注意targetSlack设得比实际可达值紧太多会导致工具在这个组上反复迭代却无法收敛白白消耗运行时间。设之前最好先看一轮报告了解这个组的slack分布目标定在比当前WNS好10%到20%的位置比较合理。3. 自定义path group的划分策略与实操3.1 什么时候需要自定义path group默认的path group划分reg2reg、reg2cgate、in2reg、reg2out、feedthru等是按路径端点类型自动分的大多数情况下够用。但有几类场景默认分组不够精细需要手动切分。第一类是跨时钟域路径。默认分组不区分时钟域所有reg2reg路径混在一个组里。如果设计里有多个异步或半同步时钟域某个域的路径特别难收敛你没法单独给它加effort。这时候可以按时钟域自定义group把难收敛的域单独拎出来。第二类是特定功能模块的内部路径。比如某个高速接口模块的内部reg2reg路径时序很紧而其他模块相对宽松。默认分组下它们混在一起你调effort是全局生效的没法精准打击。自定义group可以按instance范围或者按clock定义来切。第三类是特殊约束路径比如需要做useful skew的路径、需要特殊NDR的路径。把这些路径单独成组配合setPathGroupOptions的特定参数可以实现更精细的控制。自定义path group的命令是createPathGroup或者用group_path取决于你用的命令集核心是指定group name和成员条件。成员条件可以基于from/to的点、时钟、instance层次等。我一般习惯用-from和-to配合-through来精确定义避免误伤。3.2 按时钟域切分的实操步骤与参数假设设计里有两个时钟域clk_core和clk_ddrclk_ddr的路径收敛困难想单独成组。操作步骤如下。第一步确认现有分组情况。跑report_path_group或者看时序报告里的path group列确认clk_ddr的路径当前落在哪个组。通常它们混在reg2reg里。第二步创建自定义组。用类似这样的命令group_path -name ddr_reg2reg -from [get_clocks clk_ddr] -to [get_clocks clk_ddr]这条命令把launch和capture都在clk_ddr域内的reg2reg路径归到ddr_reg2reg组。注意-from和to用clock而不是pin这样覆盖面更全不会漏掉某些instance。第三步给新组配置选项setPathGroupOptions ddr_reg2reg -effort high -weight 3 -targetSlack 0.02第四步确认原reg2reg组里不再包含clk_ddr的路径。有时候group_path的优先级和默认分组有交互需要跑一轮report确认。如果发现路径同时出现在两个组里检查是不是-from/-to的条件写得不够精确或者有路径的launch和capture跨了域。第五步跑一轮优化对比自定义分组前后的WNS和TNS变化。我遇到过一种情况单独给ddr组加effort后ddr的WNS改善了但core组的WNS恶化了原因是总优化资源被重新分配。这时候要么给core组也适当加weight要么回调ddr的weight找到平衡。3.3 自定义分组的粒度控制与常见误区自定义path group最容易犯的错是切得太细。有人恨不得每个模块、每个时钟域、每种路径类型都单独成组结果组数量膨胀到几十个每个组的路径数很少。这样做的问题在于优化引擎在组间调度是有开销的组太多会导致调度效率下降而且每个组路径少统计意义弱effort和weight的调整效果不明显反而增加了调参的盲目性。我的经验是自定义组控制在5到8个以内加上默认组总共不超过15个。切分的依据应该是“优化策略确实需要不同”而不是“想看得更清楚”。如果只是想看清楚某类路径的情况用report的filter就够了不必动分组。另一个误区是自定义组和默认组的覆盖关系没理清。group_path创建的组和默认组之间可能存在路径重叠一条路径可能同时满足两个组的条件。Innovus的处理是有优先级的但具体行为取决于版本和命令顺序。稳妥的做法是创建自定义组后用report确认路径归属唯一必要时用-exclude参数把某些路径从默认组里排除。4. path group与其他时序收敛机制的配合4.1 path group与useful skew的联动useful skew是时序收敛的利器但它的效果高度依赖path group的划分。useful skew的本质是借用相邻路径的时序余量来改善关键路径而“相邻”的判断依据就是path group内的路径关系。如果关键路径和它想借余量的路径不在同一个组里useful skew就借不到。实操中我通常会把需要做useful skew的路径和它潜在的“供体”路径放在同一个自定义组里然后在这个组上开启useful skew相关的选项。具体来说setPathGroupOptions配合setUsefulSkewMode使用前者定义组后者定义skew策略。需要注意的是useful skew会改变时钟树的latency分布对hold时序有影响所以做完之后必须重新检查hold必要时在hold组上补buffer。还有一个细节useful skew的优化是在组内路径之间做平衡如果组内路径的slack分布很均匀都差不多skew的空间就很小如果分布悬殊有的很紧有的很松skew的收益就大。所以自定义分组的时候把slack分布相近的路径放在一起useful skew的效果会更好。4.2 多corner多模式下的path group策略MMMC环境下path group的配置需要按scenario分别考虑。同一个组在不同corner下的表现可能完全不同在ff corner下setup很松在ss corner下setup很紧。如果你只按一个corner的感受去设effort和weight另一个corner可能就吃亏了。我的做法是先跑一轮所有scenario的时序报告统计每个组在每个corner下的WNS和违例路径数做成一张表。然后按“最差corner优先”的原则配置。比如reg2reg组在ss corner下WNS -0.2在ff corner下WNS 0.1那effort和weight就按ss corner的需求来设ff corner那边松一点没关系。组名ss corner WNSff corner WNS违例路径数effortweightreg2reg-0.200.101250high3reg2out-0.08-0.02320medium2in2reg-0.150.05680high2reg2cgate-0.050.0890low1这张表是我实际项目里常用的格式一目了然。配置的时候按最差corner的需求来同时留意其他corner有没有因为资源倾斜而恶化。如果某个组在某个corner下本来很松但因为别的组抢资源导致它恶化了那就需要重新平衡。提示MMMC下path group的选项是按scenario生效的同一个组在不同scenario下可以有不同的effort和weight。用setPathGroupOptions的时候记得带上-scenario参数否则可能只对当前active scenario生效其他scenario没吃到配置。4.3 path group与optMode、drv优化的交互path group的优化不是孤立的它和optMode优化模式以及DRVdesign rule violation优化有交互。optMode决定了工具整体的优化策略倾向比如是偏向WNS还是偏向TNS是激进还是保守。path group的effort是在optMode的大框架下起作用的如果optMode本身设得很保守你把某个组设成high effort效果也会打折扣。DRV优化和path group的关系更微妙。DRV违例比如max transition、max capacitance的修复会消耗优化资源而这些资源是从path group的预算里出的。如果某个组的路径上DRV违例很多工具会先花资源修DRV留给时序优化的就少了。这种情况下要么先单独跑一轮DRV修复把违例清掉要么给这个组更高的effort来覆盖DRV的开销。我踩过的一个坑是某个组设了high effort但WNS纹丝不动查了半天发现是那个组的路径上max transition违例太多工具一直在修DRV没空修时序。后来先把DRV清干净再跑effort的效果就出来了。所以看path group效果之前先确认DRV是否干净这是个容易被忽略的前置条件。5. 常见问题排查与实操避坑指南5.1 path group配置不生效的排查思路配置了setPathGroupOptions但报告没变化这是最高频的问题。排查顺序我一般是这样走的。先确认组名拼写和路径归属。跑report_path_group -summary看所有组的列表和每组路径数确认你配置的组确实存在且有路径。有时候组名大小写或者下划线写错了命令不报错但配置落到了不存在的组上自然不生效。再确认配置是否被后续命令覆盖。Innovus的配置是有顺序的如果后面又跑了一次setPathGroupOptions或者某个脚本重新初始化了分组前面的配置可能被冲掉。检查脚本执行顺序确保配置命令在分组确定之后、优化开始之前。然后确认scenario。MMMC下如果没带-scenario配置可能只落在active scenario上。用report_path_group -scenario name逐个确认。最后确认优化是否真的跑了。有时候配置生效了但优化阶段因为某种原因跳过了这个组比如组内路径都被设了dont_touch那也看不到变化。检查路径的dont_touch属性。5.2 组间资源争夺导致此消彼长的处理给一个组加weight或effort之后另一个组恶化了这是资源争夺的典型表现。处理思路不是简单回调而是先判断哪个组的恶化是可以接受的。如果恶化的是非关键组且恶化幅度在可接受范围内比如WNS从0.05变成-0.02但整体还有余量那可以接受不必调整。如果恶化的是关键组或者恶化幅度大到影响整体收敛那就需要重新平衡。平衡的手段有三个一是回调高优先级组的weight二是给恶化组也加effort三是用targetSlack给恶化组设一个保底目标。我一般优先用第三个因为targetSlack是“保底线”性质的不会像weight那样剧烈改变资源分配副作用小。还有一个进阶手段是分阶段优化先集中资源修最难的组修到一定程度后再放开资源给其他组。这需要手动控制优化阶段用optDesign的分步执行配合path group配置的切换来实现。操作上稍微繁琐但在时序极度紧张的项目里很有效。5.3 path group相关的典型报错与速查表现象可能原因排查动作解决方式setPathGroupOptions报错组不存在组名拼写错误或组未创建report_path_group确认组列表修正组名或先创建组配置后报告无变化配置被覆盖或scenario不对检查脚本顺序确认scenario调整顺序补-scenario参数某组路径数为0分组条件写错或路径被排除检查group_path的from/to条件修正条件确认路径归属加effort后WNS不变DRV违例占用资源或无可优化空间检查DRV报告和路径结构先清DRV或换优化策略组间此消彼长严重资源争夺对比各组WNS变化调weight或加targetSlack保底useful skew无效果组内slack分布均匀看组内slack分布重新分组让分布有梯度这张表是我自己整理的问题速查表实际项目里遇到问题先对一遍大部分情况能快速定位。表里没覆盖的情况多半是设计本身的结构问题需要回到floorplan或时钟树层面去查。5.4 几个只有踩过才知道的实操心得第一个心得path group的配置要在优化前定好优化中途频繁改配置效果很差。工具在优化过程中会基于当前配置做一系列决策中途改配置会让之前的优化成果部分失效而且工具需要重新评估路径优先级反而拖慢收敛。我的习惯是在optDesign之前把分组和选项定下来跑完一轮再看要不要微调而不是边跑边调。第二个心得report_path_group的summary比detail更有用。detail报告路径太多看不过来summary给出每组的路径数、WNS、TNS一眼就能看出哪个组是瓶颈。我一般先看summary定位问题组再针对性地看detail。第三个心得自定义组的命名要有规律。我见过有人用group1、group2这种命名过两天自己都忘了哪个组是什么。我的命名习惯是“时钟域_路径类型”或者“模块名_路径类型”比如ddr_reg2reg、core_in2reg一看就知道是什么。第四个心得path group的调整要和整体时序收敛策略对齐。如果项目整体策略是保WNS那path group的配置就围绕最差路径所在的组来做如果策略是保TNS那就要关注违例路径多的组哪怕单条路径不是最差的。这两个策略下path group的配置重点完全不同搞混了会事倍功半。第五个心得别忘了hold的path group。大家注意力都在setup上hold的path group配置经常被忽略。hold违例虽然单条影响小但数量多的时候修复成本很高。给hold组适当设effort和weight在setup收敛之后专门跑一轮hold优化比事后补buffer效率高得多。6. 从策略到落地一套可复用的path group配置流程把前面聊的内容串起来形成一套我实际项目里反复用的流程。这套流程不是死板的步骤而是一个迭代框架根据项目情况调整。第一步基线跑一轮拿到所有组的时序summary。不做任何path group配置用默认设置跑optDesign然后report_path_group -summary记录每组的路径数、WNS、TNS。这一步的目的是建立参照系知道默认配置下各组的表现。第二步识别瓶颈组。按WNS排序最差的几个组是重点按TNS排序违例路径最多的组也要关注。两者可能有重叠也可能不同都要看。同时检查这些组的路径是否适合用path group来优化——如果瓶颈是DRV或者结构问题调path group没用。第三步决定是否自定义分组。如果瓶颈组在默认分组下已经能单独控制比如就是reg2reg组那不需要自定义如果瓶颈路径混在某个大组里没法单独调就按第3章的方法切分。第四步配置effort和weight。按第2章的逻辑瓶颈组提effort到highweight提到2到3其他组保持基线。targetSlack按需设置一般给瓶颈组设一个略紧的目标。第五步跑优化对比结果。重点看三件事瓶颈组改善了没有、其他组恶化了没有、整体WNS和TNS变化如何。如果瓶颈组改善明显且其他组没大恶化配置有效如果瓶颈组没改善回到第5章排查如果其他组恶化严重按5.2的方法平衡。第六步微调迭代。根据第五步的结果调整配置再跑一轮。一般两到三轮就能收敛到比较理想的配置。迭代过程中记录每轮的配置和结果形成配置-效果的对应关系方便后续项目复用。这套流程的核心逻辑是“先看后调、小步迭代、关注副作用”。path group的配置没有放之四海而皆准的最优解每个设计的瓶颈分布不同最优配置也不同。但有了这套框架至少能保证调整是有依据的、效果是可衡量的而不是凭感觉瞎调。最后分享一个我在多个项目里验证过的小技巧把path group的配置和时序结果做成一张对照表项目结束后归档。下次遇到类似结构的设计直接拿这张表做起点能省掉大量试错时间。这张表积累得越多path group的配置就越有章可循从“调参玄学”变成“工程方法”。