3. Synopsys ECO工具链与数据准备
ECO（Engineering Change Order）不是单一工具能完成的任务，而是一条由多个 Synopsys 工具串联起来的数据加工链。理解每个工具在链上的位置和输入输出，是保证 ECO 一次收敛的前提。本节先建立工具链的整体视图，再聚焦到最容易出问题的环节——数据一致性检查与版本管理。
工具链的角色分工
在典型的后期时序修复流程中，各工具承担的角色可以这样划分：
- PrimeTime / PrimeTime SI：时序签核的黄金参考。ECO 前用它定位违例路径、生成修复目标；ECO 后用它验证修复效果。PrimeTime SI 额外处理串扰引起的延迟与噪声影响，在先进工艺节点上，SI 分析结果往往决定 ECO 是否真正收敛。
- Formality：形式验证工具。ECO 会改动网表，必须证明改动后的网表与 RTL 功能等价（或与参考网表等价）。Formality 通过 compare point 匹配来判定，是 ECO 后签核的必过关卡。
- IC Compiler II / Fusion Compiler：物理实现工具。ECO 的物理落地在这里完成——插入缓冲器、调整单元尺寸、修改布线。Fusion Compiler 进一步把 RTL 综合与物理实现融合，支持更早期的 ECO 介入。
- StarRC：寄生参数提取工具。ECO 改动金属层或单元后，局部寄生参数会变化，需要重新提取 SPEF 供 PrimeTime 做增量时序分析。
这些工具之间的数据流不是单向的，而是形成闭环：PrimeTime 给出修复方向 → ICC2/FC 执行物理改动 → StarRC 提取新寄生 → PrimeTime 复验 → Formality 确认等价性。任何一环的数据版本错位，都会让整个闭环失效。
数据一致性检查：ECO 前必须过的五道关
ECO 失败最常见的原因不是修复算法不够强，而是输入数据彼此不匹配。以下五类检查应在每次 ECO 前固定执行。
第一关：网表版本对齐。PrimeTime 读入的网表必须与 ICC2/FC 中当前布局的网表完全一致。检查方法是比对两者的模块层次、实例总数和端口列表。一个实用做法是在 PrimeTime 中执行 report_design -hierarchy，与 ICC2 的 report_design -physical 输出做交叉核对。若网表来自不同综合批次，即使功能相同，实例命名也可能不同，导致 ECO 脚本找不到目标单元。
第二关：SDC 约束一致性。SDC 中的时钟定义、输入输出延迟、false path、multicycle path 必须与物理实现阶段使用的约束一致。重点检查单位：PrimeTime 默认时间单位与库文件一致，但若 SDC 中显式写了 set_units，需确认与 ICC2 的读入设置相同。此外，ECO 后新增的缓冲器不应改变原有约束的语义，若 SDC 中有基于实例名的例外，需确认新实例不会意外落入例外范围。
第三关：SPEF 与 corner 对应。StarRC 提取的 SPEF 文件必须与 PrimeTime 当前分析的 PVT corner 一一对应。典型项目会有多个 corner（如 ss_0p72v_125c、ff_0p88v_m40c），每个 corner 对应一个 SPEF。若把 ss corner 的 SPEF 误用于 ff 分析，时序结果会严重失真。检查方法是查看 SPEF 文件头部的 *DESIGN、*DATE 和提取条件注释，并与 PrimeTime 的 report_analysis_coverage 中的 corner 名称比对。
第四关：库文件 PVT 匹配。PrimeTime 链接的 .db 库必须与 SPEF 的提取条件、SDC 的约束条件处于同一 PVT 组合。例如，若时序分析使用 ss_0p72v_125c，则库应为该条件下的 .db，SPEF 也应为该条件下提取。混用不同 PVT 的库和寄生参数，等价于在错误的物理条件下做判断。
第五关：物理数据完整性。ICC2/FC 执行 ECO 需要完整的 DEF 和 LEF。DEF 应包含当前布局、布线、电源网络信息；LEF 应包含所有用到的标准单元、宏单元和 I/O 的物理抽象。若 ECO 需要插入某个缓冲器，而该缓冲器的 LEF 不在库中，工具会报 missing physical cell 错误。检查方法是执行 check_physical_design 或等效命令，确认无 missing cell、无未布线网络。
版本管理：让每次 ECO 可追溯
ECO 往往要迭代多轮，每轮都会产生新的网表、SPEF 和时序报告。没有版本管理，很快就会出现“不知道当前用的是哪一版”的混乱。建议采用以下命名与记录规范。
| 数据类型 | 命名示例 | 关键记录字段 |
|---|---|---|
| 网表 | chip_top_eco_r3.v | ECO 轮次、综合批次、端口数 |
| SDC | chip_top_ss0p72v125c_r3.sdc | corner、约束版本、修改日期 |
| SPEF | chip_top_ss0p72v125c_r3.spef | 提取工具版本、corner、提取日期 |
| 库 | sc9mc_ss_0p72v_125c.db | 库版本、PVT、来源 |
| DEF | chip_top_eco_r3.def | 布局版本、布线状态、单元数 |
每轮 ECO 应生成一份简短的变更记录，至少包含：本轮修改了哪些路径、插入了多少缓冲器、修改了多少单元尺寸、对应的时序改善量（WNS/TNS 前后对比）、Formality 是否通过。这份记录不需要复杂模板，用文本文件或表格维护即可，但必须与文件版本号绑定。
write_changes 导出本轮 ECO 的变更清单，在 ICC2 中用 report_eco_changes 查看物理改动。两者交叉核对，能快速发现“时序工具认为改了、物理工具没执行”或反之的错位。
一个典型的数据准备检查流程
假设当前项目处于 ss_0p72v_125c corner，准备执行第 3 轮 ECO。推荐的操作顺序是：
- 确认 ICC2 中当前设计版本为 eco_r2，导出 DEF 和网表，命名为 eco_r3 的输入基线。
- 在 PrimeTime 中读入 eco_r2 网表、ss corner 的 .db、对应 SPEF 和 SDC，执行
update_timing，确认违例路径与上一轮报告一致。 - 检查 SPEF 头部提取条件与当前 corner 是否匹配，检查 SDC 中时钟周期与项目约束表是否一致。
- 生成 ECO 修复脚本，在 ICC2 中执行物理改动，导出新 DEF 和新网表。
- 用 StarRC 对改动区域做增量提取，生成 eco_r3 的 SPEF。
- PrimeTime 读入 eco_r3 网表和新 SPEF，复验时序，确认 WNS/TNS 改善。
- Formality 读入参考网表（eco_r2）和实现网表（eco_r3），执行 verify，确认等价。
这个顺序的核心逻辑是：先锁定基线，再确认输入一致，然后执行改动，最后用独立工具交叉验证。任何一步发现数据不匹配，都应停下来修正，而不是带着错位数据继续往下走——后期 ECO 的返工成本远高于前期检查成本。