1. 课程导入与签核全景

在先进工艺节点下，数字后端设计早已不是“布局布线完成即结束”的线性过程。当设计规模达到数亿门、时钟频率逼近工艺极限、片上偏差（OCV）与串扰影响不断放大时，时序签核（Timing Signoff）成为决定芯片能否流片的关键闸门。Cadence Tempus 正是这一环节的核心工具：它承担从时序分析、约束验证到 ECO 修复建议的完整职责，是连接“实现”与“交付”的签核中枢。

理解 Tempus 的定位，需要先厘清它与前后环节的关系。前端综合与物理实现（如 Genus、Innovus）负责生成网表、布局与布线结果；静态时序分析工具负责判断这些结果是否满足时序要求；而 Tempus 的独特价值在于，它不仅做分析，还能基于分析结果直接生成可执行的 ECO 修复方案，并保证修复后的时序收敛可验证、可复现。换句话说，Tempus 把“发现问题”和“解决问题”压缩进同一个签核闭环。

从项目阶段看，Tempus 通常出现在三个关键节点。第一是实现后签核：物理实现完成初步布线后，用 Tempus 做全芯片时序分析，确认是否存在 setup/hold 违例、串扰引起的增量延迟、以及约束覆盖是否完整。第二是ECO 修复阶段：针对签核发现的违例，Tempus 生成 ECO 方案，包括门尺寸调整、缓冲器插入、路径重连、VT swap 等，并输出给物理实现工具执行。第三是最终签核确认：ECO 应用后重新分析，确认违例清零或收敛到可接受范围，同时检查修复是否引入新的 DRV 或面积/功耗恶化。

要理解这套流程，最直观的方式是看数据如何流动、工具如何分工。下图展示了 Tempus 在数字后端签核中的全景位置：左侧是实现工具产出的设计数据库与约束，中间是 Tempus 的分析与修复引擎，右侧是 ECO 指令回流到实现工具，最终形成签核通过的收敛结果。

从图中可以清晰看到，Tempus 处于“实现结果”与“ECO 执行”之间的中枢位置。它接收来自物理实现工具的设计数据库、来自约束文件的 SDC、来自工艺库的时序模型与 OCV 降额参数，以及来自寄生提取的 SPEF 文件。经过分析后，它输出两类关键结果：一是时序报告，用于判断设计是否满足签核条件；二是 ECO 指令，用于指导物理实现工具进行增量修复。修复后的数据库再次回到 Tempus 分析，形成迭代收敛回路。

在实际项目中，这个闭环通常不是一次完成的。以一个典型的高性能处理器模块为例：假设模块工作频率 1.2GHz，工艺为 7nm，签核条件包含 ±5% 的 OCV 降额和串扰增量延迟。首次 Tempus 分析可能报告 setup 违例 1200 条、hold 违例 350 条，其中约 40% 的 setup 违例集中在跨时钟域路径和长线互连路径上。此时 Tempus 的 ECO 引擎会优先对关键路径进行门尺寸调整和缓冲器插入，对 hold 违例则采用延迟单元插入或 VT swap 方式修复。ECO 指令以 Tcl 脚本形式输出，物理实现工具执行后更新数据库，再次送入 Tempus 分析。经过 2 到 3 轮迭代，违例数量通常可收敛到零或仅剩少量需要人工确认的边界情况。

需要特别注意的是，Tempus 的签核结果必须与最终物理实现结果保持一致。这意味着在 ECO 执行后，必须重新提取寄生参数、重新生成 SPEF，再送入 Tempus 分析。如果跳过这一步，签核结论就可能与实际流片结果产生偏差。此外，约束的完整性同样关键：SDC 中遗漏的时钟定义、错误的 false path 设置、不完整的输入输出延迟，都会导致 Tempus 给出错误的“通过”结论。因此，签核流程中通常还会包含约束检查环节，确保 SDC 覆盖所有时钟域和接口路径。

总结来说，Tempus 在数字后端流程中的定位可以概括为三点：第一，它是签核权威，其分析结果直接决定设计能否进入流片阶段；第二，它是修复引擎，能够基于分析结果自动生成可执行的 ECO 方案；第三，它是收敛闭环，通过“分析—修复—再分析”的迭代，推动设计从“有违例”走向“签核通过”。理解这个全景，是后续掌握 Tempus 具体命令、约束编写、ECO 策略和调试方法的基础。