OpenROAD项目中的Resizer模块崩溃问题分析与修复

问题背景

在OpenROAD项目的全局布局优化(GPL)阶段，发现了一个导致Resizer模块崩溃的严重问题。这个问题出现在2025年6月27日被报告，经过分析发现该问题与c742efd6ef942f8b12c6a8ca3b5160c82b7974d8这个提交相关。

问题现象

当运行全局布局优化时，程序会在Resizer模块处理过程中突然崩溃，并产生段错误(Segmentation fault)。从堆栈跟踪信息可以看出，崩溃发生在Rebuffer类的annotateLoadSlacks方法中，这是一个与缓冲器插入和负载松弛度标注相关的功能。

技术分析

深入分析后发现，问题的根本原因与时钟源缓冲器的处理有关。具体来说：

1. 当设计中有被约束为时钟源的缓冲器时，Resizer模块在尝试对这些缓冲器进行重新缓冲(rebuffer)操作时会导致崩溃。

2. 崩溃发生在递归遍历缓冲网络(BufferedNet)并标注负载松弛度的过程中，表明在特定条件下，递归深度可能超过了预期或处理逻辑存在缺陷。

3. 从日志中可以看到，在崩溃前Resizer已经处理了315个实例的尺寸调整，并插入了7个缓冲器。

影响范围

这个问题不仅导致程序崩溃，还观察到在某些工作设计中引起了质量(QoR)的退化。具体表现为：

1. 原本能够顺利通过的设计开始报告拥塞问题
2. 即使设置了-keep_resize_below_overflow 0.0参数也无法避免崩溃
3. 布局密度在全局布局结束时没有出现异常峰值，这与类似问题的表现不同

解决方案

开发团队迅速定位了问题根源并提供了修复方案：

1. 修复了处理时钟源缓冲器时的边界条件检查
2. 优化了缓冲网络遍历逻辑，防止无限递归或深度过大
3. 增加了对特殊约束缓冲器的处理保护机制

经验总结

这个案例为EDA工具开发提供了几个重要启示：

1. 在进行大规模重构(如Rebuffer类的重写)时，需要特别关注边界条件和特殊约束的处理
2. 时钟网络相关功能需要格外谨慎，因为它们在时序收敛中扮演关键角色
3. 质量退化有时比直接崩溃更难诊断，需要建立更完善的回归测试机制

该问题的及时修复保证了OpenROAD工具链在物理实现流程中的稳定性，特别是对于包含复杂时钟网络的设计。这也提醒开发者在优化算法性能的同时，必须确保功能的正确性和鲁棒性。