1. 从"分组"到"分治"：path group 到底在解决什么问题

数字后端做到时序收敛阶段，很多人会陷入一个怪圈：明明每条路径单独看余量都还行，可一跑全局优化，工具给出的结果就是差那么一口气。这时候如果还盯着单条 path 死磕，基本是白费力气。真正该动的地方，是 path group 这一层——它决定了优化引擎把算力和迭代预算往哪儿倾斜。

先把概念捋清楚。path group 本质上是时序路径的逻辑集合，工具在优化时以 group 为单位分配权重、计算代价函数、决定优化顺序。你可以把它理解成项目管理里的"优先级队列"：资源有限，谁先做、谁多做，全看分组策略。默认情况下，工具会按时钟域自动切分，比如每个 clock 一个 group，异步接口、输入输出路径各自成组。这套默认逻辑在简单设计里够用，但一旦设计里出现多时钟交织、跨域路径密集、或者某几个模块的时序特别难啃，默认分组就会把优化资源摊薄，导致"该紧的地方没紧起来"。

我在一个中等规模的图像处理芯片项目里就吃过这个亏。设计里有四个主时钟域，其中一个是低速配置时钟，路径数量占了将近四成，但时序余量非常宽裕。默认分组下，工具给这个低速域分配了和高速域差不多的优化权重，结果高速域的关键路径迟迟收不进去，迭代轮次全耗在了那些本来就达标的路径上。后来把低速域单独拎出来降低优先级，高速域的关键路径单独成组并提高权重，同样的迭代次数下 WNS 直接改善了 60 多 ps。这个教训说明一件事：path group 不是给工具看的分类标签，而是你向优化引擎下达的资源调度指令。

所以这一篇要聊的，不是"怎么建 group"这种操作手册级别的内容，而是分组背后的策略思维——什么时候该拆、什么时候该合、权重怎么给、和其它约束怎么配合。这些判断没有标准答案，但有清晰的推理链路，掌握了链路，换个设计你也能自己推。

2. 分组粒度的取舍：拆得太细和合得太粗都会翻车

2.1 过细分组的隐性代价

新手容易走向一个极端：既然分组能提高优先级，那就把每条关键路径都单独成组，岂不是每条都能得到最优对待？实测下来完全不是这么回事。工具在 group 之间做资源仲裁时是有开销的，group 数量一多，优化引擎的调度复杂度上升，反而容易出现"每个组都优化了一点，但每个组都没优化透"的局面。

更麻烦的是，过细分组会破坏路径之间的共享逻辑优化。数字电路里大量路径共享同一段组合逻辑，工具在做 sizing、buffer 插入这些操作时，本来可以一次性惠及多条路径。你把它们拆到不同 group 里，工具为了满足各自 group 的独立目标，可能做出互相打架的优化决策，最后面积涨了、时序没见好。我一般建议单个 clock 域下的 group 数量控制在个位数，除非有非常明确的理由，否则不要为了"看起来精细"而过度拆分。

2.2 过粗分组的资源摊薄

另一个极端是把所有路径塞进一个大 group。这种做法在早期探索阶段偶尔能用，但到了收敛后期就是灾难。原因很简单：group 内部的权重是统一的，工具无法区分组内哪些路径是真正的瓶颈。一个包含上万条路径的大 group，里面可能只有几十条是卡脖子的，但工具会把优化努力平均撒下去，瓶颈路径得不到额外关注。

判断粒度是否合适的土办法：跑完一轮优化后看 group 报告，如果某个 group 里最差路径和平均路径的差距超过两三个数量级，说明这个 group 内部异质性太强，该拆了；反过来，如果两个 group 的路径集合高度重叠、优化目标也一致，那它们就该合并。这个判断不需要多精确的数学，看报告的经验值就够了。

2.3 一个可复用的拆分决策表

下面这张表是我在实际项目里总结的拆分判断依据，遇到拿不准的情况就对照着过一遍：

这张表不是铁律，但它覆盖了八成以上的常见情形。真正做决策时，还要结合当轮迭代的实际报告数据来微调。

3. 权重分配的门道：数字背后的资源博弈

3.1 权重不是"越大越好"

很多人以为把关键 group 的权重调到最大就能解决问题，实际上权重是一个相对值，工具看的是 group 之间的比例关系。你把 A 组权重设成 10、B 组设成 1，和设成 100 与 10，效果是一样的。真正影响结果的是比例，以及这个比例是否和路径的实际紧迫程度匹配。

更关键的是，权重过高会引发"过度优化"。工具为了满足高权重 group 的目标，可能做出一些激进的决策，比如插入大量 buffer、把单元尺寸推到极限，结果这个组是收进去了，但周边路径被拖累，整体反而变差。我见过一个案例，某工程师把最难收的组权重拉到默认值的五倍，那一组确实改善了，但相邻组的 WNS 恶化了将近一倍，最后整体收敛时间反而变长。

3.2 用余量差距反推权重比例

一个比较靠谱的定权思路是：先看各组当前的 WNS 差距，权重比例大致和差距的紧迫程度挂钩。比如高速组 WNS 是 -80ps，低速组是 +200ps，那高速组的权重就应该明显高于低速组，但具体高多少要看路径数量和优化难度。我的经验公式是：权重比例大致等于"余量差距的倒数比"，再根据路径数量做修正。路径多的组适当降权，路径少但全是硬骨头的组适当提权。

这个思路的本质是让工具把有限的优化预算花在"边际收益最高"的地方。一条 -80ps 的路径改善 20ps 的收益，远大于一条 +200ps 的路径再改善 20ps，权重就该体现这个差异。

3.3 权重调整的节奏控制

权重不是一次定死就不管的。收敛过程分阶段，每个阶段的目标不同，权重也该跟着变。早期探索阶段，权重可以相对平均，让工具先把整体布局和结构调顺；中期收敛阶段，开始向瓶颈组倾斜；后期冲刺阶段，权重集中到少数最难收的组上，其它组维持住就行。

这个节奏控制很重要，因为早期就把权重拉得很极端，工具会在还没摸清全局的情况下做出局部激进的决策，后期很难挽回。我习惯把收敛分成三到四轮，每轮结束看报告、调权重、再跑下一轮，而不是一次性把所有参数设到最激进然后干等结果。

4. 分组与其它约束的联动：别让策略互相打架

4.1 和 false path、multicycle 的配合

path group 的划分必须和时序例外约束保持一致，否则会出现"分组目标和实际时序关系矛盾"的情况。举个典型场景：某条跨域路径你设了 false path，但它所在的时钟域被单独成组并提了高权重，工具就会困惑——这条路径到底要不要优化？虽然工具通常会以例外约束为准，但分组带来的权重压力可能让它做出一些不必要的优化动作，浪费资源。

正确的做法是：分组之前先把时序例外理清楚，false path 覆盖的路径不应该出现在任何高权重 group 里，multicycle 路径要根据实际周期数调整其在 group 内的期望值。分组是资源调度，例外约束是时序事实，两者必须对齐，不能各说各话。

4.2 和 region、bound 的协同

如果设计里用了物理区域约束，path group 的策略也要相应调整。被 bound 在特定区域的逻辑，其优化手段受物理边界限制，这时候给它过高的权重意义不大，因为工具能做的操作有限。反过来，如果一个 group 的路径跨越多个区域，优化时需要考虑跨区域的布线延迟，权重和优化目标都要相应调整。

我在一个多电压域项目里遇到过这个问题：某个 group 的路径跨越了电压域边界，需要插入电平转换单元，这类路径的优化逻辑和普通路径完全不同。后来把这个 group 单独拆出来，配合物理约束一起调整，才把时序收住。这说明分组不能孤立地看，要和物理、约束层面的信息一起考虑。

4.3 分组策略的验证方法

调完分组和权重，怎么验证策略是否有效？不能只看最终 WNS 一个数字。我通常看三个指标：各组 WNS 的改善幅度是否均衡、优化后的面积增量是否在预期内、以及关键路径的优化手段是否符合预期（比如该用 sizing 的地方有没有被 buffer 堆砌替代）。如果某个组 WNS 改善了但面积暴涨，说明权重给过头了；如果所有组都没什么变化，说明分组策略根本没起作用，得回头检查约束是否冲突。

5. 收敛后期的分组微调：从"大刀阔斧"到"精准手术"

5.1 后期为什么不能大改分组

到了收敛后期，设计的物理结构基本定型，这时候大改分组会让工具重新做大量决策，之前的优化成果可能被推翻。后期的分组调整应该是微调性质的：合并几个已经收敛的组释放资源、把个别顽固路径单独拎出来做最后一搏、或者调整权重比例做最后的资源再分配。

我一般在这个阶段只做两类操作：一是把已经达标的组降权甚至并入默认组，把算力腾出来；二是把剩余未收敛的路径按优化手段的相似性重新聚类，让工具用同一种策略集中处理。这个阶段的分组数量通常比中期少，因为大部分路径已经收敛，剩下的都是硬骨头，需要的是集中火力而不是广撒网。

5.2 顽固路径的单独处理

总有那么几条路径，怎么调分组都收不进去。这时候要判断它是"优化手段不够"还是"约束本身有问题"。如果是前者，把它单独成组、给足权重、配合手动干预（比如指定特定的优化策略或手动调整单元位置）；如果是后者，比如路径的时序关系本身设错了，那再怎么优化分组都是徒劳，得回头改约束。

判断方法很直接：看这条路径的优化历史，如果工具反复尝试但每次改善都很小，大概率是物理结构限制或约束问题；如果工具根本没怎么动它，说明它没被纳入有效优化范围，检查分组和约束覆盖。

5.3 分组策略的复盘沉淀

每个项目结束后，我会把分组策略和实际效果整理成一份简短的复盘记录：用了什么分组方式、权重怎么给的、遇到了什么问题、最后怎么解决的。这份记录在下个项目遇到类似结构时能直接参考，省去大量试错时间。分组策略这东西，理论讲再多不如自己踩一遍坑记得牢，但别人的坑能帮你少走弯路。

6. 几个容易忽略的实操细节

6.1 分组命名要能自解释

group 的名字别用默认的自动生成名，自己起一个能看懂的名字，比如grp_highspeed_core、grp_crossdomain_ddr这种。收敛后期报告一大堆，名字看不懂就得反复查定义，浪费时间。命名规范这件事看着小，实际能省不少沟通成本，尤其是多人协作的项目。

6.2 报告要看 group 级别的细分数据

只看全局 WNS 会掩盖 group 之间的差异。每轮优化后要看 group 级别的报告，关注每个组的路径数量、WNS、TNS、以及优化前后的变化。如果某个组 TNS 很大但 WNS 还行，说明这个组里有一批路径集体差一点，可能需要整体调整策略而不是单点突破。

6.3 别忽视 group 之间的相互影响

优化一个 group 可能会影响相邻 group 的路径，因为物理资源是共享的。调整分组后要观察周边组的变化，如果出现"按下葫芦浮起瓢"的情况，说明分组策略引发了资源竞争，需要重新平衡权重或者调整物理约束。

6.4 工具版本差异要留意

不同版本的工具在分组调度算法上可能有差异，同样的分组策略在不同版本下效果可能不同。升级工具版本后，原有的分组策略要重新验证一遍，别想当然地沿用。这个坑我在一次版本升级时踩过，原本调好的权重比例在新版本下效果打了折扣，后来重新校准才恢复。

7. 写在最后的个人体会

path group 这个功能，工具文档里讲的是"怎么用"，但真正决定效果的"什么时候用、用到什么程度"，文档不会告诉你。我的体会是：分组策略的本质是资源调度思维，你得清楚每一轮迭代里工具的时间花在了哪里、哪些路径值得多花时间、哪些路径维持住就行。这个判断力没法速成，但每次调完分组后认真看报告、对比前后变化、记录决策依据，几轮下来就能形成自己的直觉。

还有一点，别把分组当成万能药。时序收敛是约束、布局、优化策略共同作用的结果，分组只是其中一环。遇到收不进去的情况，先排查约束是否合理、物理结构是否有瓶颈，再考虑动分组。顺序搞反了，容易在错误的方向上越走越远。