3. 定位工具链与数据准备

复杂后端问题的定位效率，往往不取决于工程师对单个命令的熟悉程度，而取决于是否建立了一条“问题→工具→数据→证据”的稳定链路。Cadence 后端工具链中，Innovus、Tempus、Voltus、Pegasus 各自承担不同的诊断职责，它们输出的日志、报告、数据库和波形，构成了问题定位的原始证据。本节的重点不是罗列命令，而是讲清每个工具“能回答什么问题”、数据“从哪里来、怎么预处理、如何交叉验证”。

一、四个工具的诊断能力边界

先建立能力边界，才能避免“拿错工具查错问题”。

• Innovus：实现阶段的“现场记录仪”。它掌握布局、时钟树、布线、DRC 修复的全过程，能回答“某条路径在哪个阶段被改动了”“某个 cell 为什么被移动”“congestion 在哪个区域恶化”。核心证据是 innovus.log、时序报告、congestion map、以及保存的 .enc 数据库。
• Tempus：独立的签核级时序分析引擎。它回答“真实签核条件下这条路径到底违例多少”“OCV/AOCV/POCV 设置差异带来多大影响”。核心证据是 report_timing 输出、.timing 数据库和 SPEF/SDC 组合。
• Voltus：电源完整性与 IR-drop 分析工具。它回答“哪条电源网络压降超标”“哪个 instance 因 IR-drop 导致时序退化”。核心证据是 voltus.log、IR-drop map、.ptia/.vow 波形与电源报告。
• Pegasus：物理验证与 DFM 检查工具。它回答“DRC/LVS/ERC 违例的几何位置和规则编号是什么”“是否由某条金属线间距不足引起”。核心证据是 pegasus.log、.sum 汇总、RDB 数据库和版图标记。

四者关系可以概括为：Innovus 提供“实现上下文”，Tempus 提供“时序结论”，Voltus 提供“电源约束”，Pegasus 提供“物理合法性”。一个复杂问题通常需要至少两个工具的证据才能闭环。

二、日志采集：先固定“时间锚点”

日志是最廉价也最容易被浪费的数据。Innovus 的 innovus.log 会记录每条命令的执行时间、CPU 耗时和内存峰值；Voltus 的 voltus.log 会记录电源网络求解的迭代收敛过程。采集时不要只保存最终文件，而应保留完整日志并做三件事：

1. 记录工具版本与启动参数。例如 innovus -version 与 set_db 关键设置，版本差异会直接改变时序结果。
2. 标注关键阶段时间戳。用 grep -n "place_opt\|cts\|route" innovus.log 找到阶段边界，后续任何异常都能定位到“发生在哪个阶段之后”。
3. 提取错误与警告上下文。不要只抓 ERROR 行，前后各 20 行往往包含触发条件，例如某个 cell 缺失、某个 layer 被禁用。

一个实用的预处理命令示例：

# 提取 Innovus 日志中的阶段时间线与错误上下文
grep -nE "Begin|End|ERROR|WARN" innovus.log > stage_timeline.txt
awk '/ERROR/{for(i=NR-20;i<=NR+20;i++) print i": "a[i]} {a[NR]=$0}' innovus.log > error_context.txt

这样得到的 stage_timeline.txt 可以直接回答“问题出现在 CTS 之后还是 route 之后”，而 error_context.txt 则保留了错误发生的现场。

三、报告与数据库：从“结论”回到“路径”

Tempus 的 report_timing 输出的是结论，但定位需要回到路径。建议采集时同时保存三种粒度：

• 汇总报告：report_timing -max_paths 100 -nworst 10，用于判断违例是集中还是分散。
• 单路径详情：对关键路径加 -path_type full_clock_expanded，展开时钟树与数据路径，看清是哪一级 cell 或 net 贡献了主要延迟。
• 数据库快照：保存 .timing 或 .enc，便于后续用 report_timing -from/-to 反复查询，而不必重跑实现。

Voltus 的 IR-drop 报告则要区分静态与动态：静态 IR 看平均压降，动态 IR 看瞬态峰值。采集时应同时保存 power_grid 报告和 .vow 波形，后者能定位到具体时间窗口内的电压塌陷。Pegasus 的 .sum 文件给出违例数量与规则编号，RDB 数据库则保留几何坐标，二者配合才能判断“是规则理解问题还是真实版图问题”。

四、波形采集：把“时序违例”翻译成“电压/电流事件”

当 IR-drop 导致时序退化时，单看时序报告无法解释原因。此时需要把 Voltus 的 .vow 波形与 Tempus 的违例路径对齐：在波形上找到违例路径所在 instance 的电源节点，观察其电压在时钟沿附近是否出现超过阈值的塌陷。例如某实例供电电压标称 0.8V，若波形显示时钟沿前 200ps 内跌至 0.72V，即约 10% 压降，就足以解释该路径的额外延迟。采集波形时务必记录采样精度和仿真时间窗口，否则波形只能看趋势、不能做定量判断。

五、交叉验证：让四个工具互相“作证”

单一工具的证据往往有歧义。例如 Tempus 报告某路径 setup 违例 30ps，但 Innovus 中同一路径却显示满足。此时应检查：两者的 SPEF 是否一致、SDC 是否相同、OCV 设置是否一致。若 Voltus 同时显示该路径附近存在动态 IR-drop，则更合理的结论是“签核条件下电源压降导致时序退化”，而不是工具本身出错。

再如 Pegasus 报出大量金属间距 DRC，而 Innovus 的 congestion map 显示该区域布线密度极高，则问题根源可能是布线资源不足，而非简单的规则误报。四个工具的证据链一旦对齐，定位就从“猜测”变成了“推断”。

总结来说，工具链的价值不在于工具本身，而在于数据能否被正确采集、预处理和交叉验证。Innovus 给出现场，Tempus 给出结论，Voltus 给出电源约束，Pegasus 给出物理合法性；把四者的日志、报告、数据库和波形按统一时间锚点组织起来，才能形成可复现、可追溯的定位证据链。