2. Calibre验证流程与性能剖析

在上一节中我们已经明确，Calibre 物理验证的性能瓶颈往往并不在“算法本身”，而在于整条验证链路中资源分配与数据流动的失衡。本节将沿着一次完整的 Calibre 运行，从规则文件读入、版图数据加载、几何运算、结果输出四个阶段，逐段拆解 CPU、内存、I/O 与磁盘各自的耗时分布，并给出可操作的观测手段。

一、完整链路的四个阶段

一次典型的 Calibre DRC/LVS 运行，可以抽象为四个串行阶段：

1. 规则编译阶段：Calibre 读取 SVRF 规则文件，解析语法、展开宏、构建内部规则树。此阶段主要消耗 CPU 单核性能，耗时通常与规则复杂度成正比，与版图规模无关。
2. 版图加载阶段：读取 GDSII/OASIS 版图，解压、展开层次、构建几何数据库。这是 I/O 与磁盘最密集的阶段，尤其当版图以 OASIS 压缩格式存储、或跨 NFS 读取时，磁盘吞吐会成为主导。
3. 几何运算阶段：执行 DRC 的布尔运算、LVS 的器件提取与网表比对。这是 CPU 与内存的核心战场，Calibre 会启动多进程/多线程并行处理，内存占用随版图层次展开而快速增长。
4. 结果输出阶段：写出 RDB 结果数据库、生成报告、可选地输出 GDS 标记层。此阶段以磁盘写入为主，结果文件体积可达数 GB。

下图给出这四个阶段与 CPU、内存、I/O、磁盘四类资源的对应关系，以及各阶段最典型的观测指标。

二、规则编译阶段：被低估的“小头”

规则编译通常只占整条链路 1%～5% 的时间，但在规则文件庞大（例如包含数万行 SVRF、大量 #DEFINE 宏和 INCLUDE 嵌套）时，也可能达到数十秒。此阶段是纯单核 CPU 行为，无法通过增加进程数加速。判断方法很简单：在 Calibre 日志中查找 Reading rule file 到 Compiling rules 之间的时间戳差值。若该差值异常大，应优先检查规则文件是否存在深层嵌套的 INCLUDE 或未展开的宏。

三、版图加载阶段：I/O 与磁盘的主战场

版图加载是整条链路中 I/O 最密集的环节。Calibre 需要顺序读取 GDSII 或 OASIS 文件，解压并展开层次。这里有两个关键变量：

• 文件格式：OASIS 通常比 GDSII 小 5～10 倍，但解压需要额外 CPU。若磁盘带宽充足而 CPU 空闲，OASIS 更优；若 CPU 已是瓶颈，GDSII 反而可能更快。
• 存储位置：从 NFS 读取版图时，网络延迟和服务器磁盘吞吐会直接叠加到加载时间上。将版图复制到本地 scratch 盘，往往能缩短 30%～60% 的加载时间。

观测手段：在 Linux 下用 iostat -x 1 观察 %util 与 await，若加载阶段 %util 持续接近 100%，说明磁盘已饱和；用 pidstat -d 1 可看到 Calibre 进程的读写速率。若读写速率远低于磁盘标称带宽，则瓶颈可能在 NFS 或文件系统元数据操作。

四、几何运算阶段：CPU 与内存的核心战场

几何运算是 Calibre 耗时最长的阶段，通常占整条链路的 60%～85%。Calibre 通过 -turbo 或 -hier 等选项启动多进程并行，每个进程处理版图的一个区域。此阶段的性能取决于三个因素：

1. 并行度：进程数并非越多越好。当进程数超过物理核心数时，上下文切换和内存带宽争用会导致收益递减。经验上，进程数设为物理核心数的 1～1.5 倍较为合理。
2. 内存峰值：层次展开后的几何数据库可能达到原始 GDS 的 10～20 倍。若物理内存不足，系统会触发 swap，性能断崖式下跌。用 free -h 和 vmstat 1 观察 si/so 是否非零，是判断 swap 发生的直接依据。
3. 规则复杂度：密集的布尔运算、大量的 AND/OR/NOT 层操作会显著增加单区域计算量。可通过 Calibre 的 -timing 选项输出各规则段的耗时，定位最耗时的规则。

五、结果输出阶段：磁盘写入的收尾

结果输出阶段包括 RDB 数据库写入、报告生成和可选的 GDS 标记层输出。RDB 文件体积与违例数量成正比，在先进工艺节点上可达数 GB。此阶段主要消耗磁盘写入带宽，若与几何运算阶段的临时文件写入竞争同一块盘，会拖慢整体进度。建议将 RDB 输出目录与 scratch 目录分离到不同物理磁盘。

六、一次示例运行的耗时分布

以下是一组用于教学说明的示例数据（非实测，仅用于展示量级关系）：某 28nm SoC 顶层 DRC 运行，版图 GDS 约 12GB，规则文件约 8000 行，使用 32 进程。

从这组示例可以看出，几何运算阶段是绝对大头，但版图加载与结果输出合计也接近 27%，在优化时不应只盯着 CPU。一个常见的误区是盲目增加进程数，结果内存溢出触发 swap，反而使几何运算阶段耗时翻倍。

# 观察 CPU 与内存整体压力
vmstat 1 10

# 观察磁盘吞吐与饱和度
iostat -x 1

# 观察 Calibre 进程的读写与 CPU 占用
pidstat -d -u -p $(pgrep calibre) 1

七、从链路视角看优化优先级