我们在跑 INNOVUS globalRoute 时，偶尔会遇到如下崩溃：

1
2
3
4
5
6
7
8

#Start globalRoute on Sun Jun  7 10:10:32 2026
#
#Generating timing data, please wait...
#1761354 total nets, 1760691 already routed, 1760691 will ignore in trialRoute
**WARN: (IMPPTN-1250):  Pin placement has been enabled on metal layer 1.
No more memory.  Current memory consumption: 19078MB.
  Requested 83886080 bytes, errno=12.
Program name not specified.  Can't dump stack trace.Abnormal exit.

本文总结该问题根因分析与解决思路，参考了 Cadence ASK 官方文档。

1. 错误解读

1.1 errno=12 是什么？

errno=12 对应 Linux 标准错误码 ENOMEM（Out of Memory），含义是操作系统无法满足进程的内存申请请求。
触发条件：物理内存 + Swap 空间全部耗尽，内核拒绝再分配。

1.2 关键数据解析

字段 数值 说明
已消耗内存 19078 MB (~19 GB) 进程崩溃前的驻留内存
申请失败大小 83,886,080 bytes (~80 MB) 最后一次 malloc 失败的请求量
已布线 net 数 1,760,691 / 1,761,354 占总 net 数的 99.96%
Can't dump stack trace — 进程被 OOM 杀死前来不及写 stacktrace

1.3 关键观察：崩溃发生在 99.96% 完成时

日志显示仅剩 663 条 net 未处理，globalRoute 几乎已经完成，却在最后的 trialRoute 收尾阶段内存越界。
这说明根因不是算法逻辑错误，而是内存在长时间积累后耗尽，工具本身无法继续申请哪怕 80MB 的增量内存。

1.4 为什么没有 stack trace？

Cadence ASK 文章 Debugging crash, stack trace, and hang in Innovus/Tempus（文章编号 20159140）将此类崩溃归类为 Scenario 2：

The crash could be due to low stack space or swap size at your end. This could lead to “no stack trace” been written into the log. Without the stack trace, it will be difficult to debug the reason for the crash.

OOM 导致进程被强制终止，信号处理函数没有机会执行，因此无法写出 stack trace。

2. 根因总结

1
2
3
4

物理内存 + Swap 耗尽
  └─ Linux 内核返回 ENOMEM (errno=12)
       └─ Innovus NanoRoute 申请内存失败
            └─ "No more memory. Abnormal exit."

该设计规模约 176 万条 net，属于超大规模设计，globalRoute 在内存中维护完整的布线树、时序视图和 RC 数据，累计消耗超过 19 GB 是正常现象，但若服务器可用内存不足则会崩溃。

3. 解决方案

3.1 首要：检查服务器资源

在 Linux shell 上确认内存和 Swap 状态：

1
2
3

free -g          # 查看物理内存和 Swap 剩余
vmstat -s        # 查看详细内存统计
df -h /tmp       # Innovus 使用 /tmp 写临时文件，需确保有足够磁盘空间

建议：对于百万级 net 的设计，运行 globalRoute 的服务器至少需要 32 GB 可用内存（物理 RAM + Swap 合计）。

3.2 解除进程资源限制

在启动 Innovus 的 shell 中执行（tcsh 语法）：

limit stacksize  unlimited
limit memoryuse  unlimited

或 bash 语法：

1
2

ulimit -s unlimited
ulimit -v unlimited

这可以防止因 shell 默认限制导致进程提前被截断。

3.3 精简 analysis_view 数量

Cadence ASK 文章（文章编号 20468170）指出，analysis_view 数量是内存峰值的最大贡献项。在 routing 阶段仅保留必要的视图：

1

set_analysis_view -setup {setup_wc} -hold {hold_bc}

在 log 中搜索 Optimization is working on the following views，确认哪些 view 被实际使用，将未使用的从命令中移除。

3.4 减少并发线程数

多线程路由每个线程都会占用独立的内存缓冲区，适当降低线程数可有效减少峰值内存：

1
2

setMultiCpuUsage -localCpu 4   ;# 根据机器实际 RAM 调整
globalRoute

3.5 降低 globalRoute effort

使用较低的 effort 可减少 NanoRoute 内部数据结构的内存占用：

1

globalRoute -effort medium

默认 effort 为 high，适当降低在超大设计上能节省可观的内存。

3.6 处理 IMPPTN-1250 警告

日志中出现：

1

**WARN: (IMPPTN-1250): Pin placement has been enabled on metal layer 1.

Metal 1 上允许 pin placement 会显著增加 globalRoute 的搜索空间和 trialRoute 的复杂度，建议在 floorplan 阶段评估是否能避免将 pin 放在 Metal 1 上。

3.7 分段保存，从检查点恢复

如果以上方法仍无法避免 OOM，可以尝试分段运行：在 globalRoute 前先保存一次数据库，崩溃后直接从检查点恢复，避免从头重跑：

1
2
3

write_db pre_globalRoute.db
globalRoute -effort medium
write_db post_globalRoute.db

4. 排查流程图

1
2
3
4
5
6
7
8
9
10
11
12
13

globalRoute OOM 崩溃
       │
       ├─ 检查 free -g ──► 内存不足 ──► 换更大内存机器 / 加 Swap
       │
       ├─ 检查 limit ──► 有资源限制 ──► limit stacksize/memoryuse unlimited
       │
       ├─ 精简 analysis_view ──► 移除未使用的 view
       │
       ├─ 降低 CPU 线程数 ──► setMultiCpuUsage -localCpu N
       │
       ├─ 降低 effort ──► globalRoute -effort medium
       │
       └─ 仍复现 ──► 开 Cadence Support Case（提供 log + pstack 输出）

5. 向外部支持开 Case 时需准备的信息

若以上措施均无效，需要向 Cadence 开 Support Case。根据 Cadence ASK 文档，需提供：

  1. 完整的 innovus.logv 文件
  2. 运行机器的 OS 版本（uname -a）
  3. 内存和 Swap 配置（free -g）
  4. 若工具还在运行（hang 场景），提供 pstack <pid> 输出

参考资料