极客工场

Appearance

共 4,397 字预计阅读约 15 分钟

签核方法论：Cadence/Synopsys 双工具关联、corner 矩阵与签收标准 ​

更新时间：2026-09-25。单项违例清零不等于可以流片：签核（signoff）要回答的是「在谁认可的数据、工具和标准下，这颗芯片可以交出去」。这一篇把 STA、功耗、物理验证、可靠性各项 signoff 串成一条可审计的方法学主线，工具对应与各专项细节可回看 MMMC 高级 STA、串扰与 SI 签核 和 完整流片签核清单。

本文要回答的问题 ​

  • signoff 与实现阶段的「检查通过」差别在哪，谁为结论背书？
  • STA、功耗、IR drop、DRC/LVS、可靠性各自的黄金签核工具是什么，Cadence 与 Synopsys 两边怎么对应？
  • MMMC（Multi-Mode Multi-Corner，多模多角）矩阵要不要把所有 corner 组合都跑满？
  • 为什么关键设计要拿两家工具交叉跑，结果对不上时先怀疑哪里？
  • 签收阈值、waiver（豁免）和 ECO 收敛迭代怎么管，才能让签核报告可复现、可追溯？

一、signoff 是什么：从「检查通过」到「责任移交」 ​

signoff 字面上是「签字」，工程含义是一次责任移交：设计团队用晶圆厂认证（foundry-qualified）的库、工艺文件和工具版本，按事先约定的标准跑完所有检查，把结论连同数据快照固化下来，此后若因被签核覆盖的问题返工，责任界定以这份记录为准。它和实现阶段的日常检查有三点本质差别。

其一，数据受控。签核用的网表、SDC（Synopsys Design Constraints，时序约束）、UPF（统一功耗格式）、SPEF（寄生参数文件）必须是同一个版本快照，而不是某人目录下「最新的那份」。其二，工具与工艺文件受控。晶圆厂对每个工艺节点会认证特定工具版本和 rule deck（规则卡组），跑错版本的结果晶圆厂不认，DRC/LVS 用的 deck 版本号甚至要写进签收报告。其三，标准前置。WNS/TWS（最差负裕量/负裕量总量）、IR drop 阈值、DRC/LVS 清零这些标准在项目启动时就写进签核手册，而不是跑出违例后再商量。

还要区分签字的「层级」。一颗 SoC 内部通常有多级 signoff：IP 供应商对硬宏（PHY、SerDes、存储器编译器）签核并给出集成约束与使用条件；模块负责人对本模块的时序和功耗签收；顶层团队对整芯片做最终签收；最后晶圆厂对 GDS 和物理验证报告做入厂审查。每一级签字都只覆盖自己的数据范围，IP 的签收报告不能拿来免除顶层的检查义务。反过来说，顶层发现违例时也要能沿这条链回溯：问题出自 IP 内部、集成约束没被遵守，还是顶层布线引入。因此签核方法学首先是一套数据和责任的组织方式，其次才是工具使用问题——没有记录的「口头说没问题」在多团队、多站点项目里等同于没做。

二、签核全景：五大项与两家工具对应 ​

一颗数字芯片的签核不是一条命令，而是一组各自独立、各有黄金工具的检查项。下表给出主流环节与 Cadence、Synopsys 两家工具的对应关系，物理验证环节还常见晶圆厂深度认证的 Siemens Calibre。

签核项检查内容SynopsysCadence关联专题
STA 静态时序setup/hold、CRPR、MMMCPrimeTimeTempusMMMC 高级 STA
功耗签核动态/漏电功耗、波形相关功耗PrimePowerVoltus（功耗分析）功耗签核与 IR drop
电源完整性静态/动态 IR drop、EMPrimePower + Ansys RedHawkVoltus-X功耗签核与 IR drop
SI 信号完整性串扰延迟、glitch、噪声余量PrimeTime-PXTempus（crosstalk）串扰与 SI 签核
物理验证DRC/LVS、天线规则、DFMIC Validator (ICV)PegasusDRC/LVS 物理验证
寄生提取RC 提取产出 SPEFStarRCQuantus寄生 RC 提取
可靠性老化、电迁移、AEC-Q100同厂签核套件同厂签核套件可靠性与 AEC-Q100

注意工具链里寄生提取的位置：StarRC/Quantus 产出的 SPEF 是 STA、功耗、SI 三项签核共同的输入，SPEF 口径不一致，后面所有交叉比对都失去基础。提取时的 corner 设置（典型 RC、cbest、cworst、rcbest、rcworst）必须和 STA 视图一一对应，拿典型角的 SPEF 去跑快角 hold 检查，结论没有意义。

另外两类签核容易被数字团队漏掉。一是形式等价性验证（LEC）：综合后、ECO 后都要用 Conformal 或 Formality 证明网表与 RTL 逻辑等价，否则时序签核的根本不是你以为的那个电路。二是数模混合与封装级签核：模拟 IP 走仿真驱动的工艺角覆盖，封装引入的 RLC 要和片上模型联合做电源完整性分析，先进封装项目这一步单列签收。两类检查的共同点是无法靠 STA 报告附带，必须在签核清单里独立成行。

chip-design/expert/33-signoff-methodology-cadence-synopsys-flow.md D2 示意图

这张数据流图明确两件事：物理验证直接吃 GDS，与时序功耗是并行轨道；而 SPEF 是时序与功耗轨道的共同源头。签核排期时要先保寄生提取的版本冻结，否则 STA 和功耗团队会各自拿到不同的 SPEF，报告拼在一起对不上。

三、MMMC：corner 矩阵的构造与裁剪 ​

MMMC 把两个维度叉乘：mode（功能模式，如典型工作、睡眠、扫描测试、烧录）和 corner（PVT 与互联工艺角，如 SS/0.72V/125°C、TT/0.8V/25°C、FF/0.88V/-40°C）。setup 在慢角查、hold 在快角查是基本原则，但先进节点还要考虑 POCV（参数化片上变化，见 OCV/AOCV/POCV）带来的统计分布。

最容易犯的错是把矩阵无限扩张：8 个 mode 乘 12 个 corner 就是 96 个视图，每个视图都要读一次网表和 SPEF，单次签核回归从小时级变成天级。裁剪依据有三条：统计相关性（两个 corner 的结果高度相关则保留更坏的一个）、模式真实存在性（扫描模式只关心移位频率，不必套功能最高频约束）、晶圆厂必查清单（foundry 点名的 corner 一个不能少）。

chip-design/expert/33-signoff-methodology-cadence-synopsys-flow.md D2 示意图

裁剪不是偷偷减检查，而是把决策显式化：每个被删掉的视图要注明「被哪个视图覆盖、依据是什么」，写进签核手册。worst-case 叠加（最慢晶体管 + 最差互联 + 最高温度同时出现）在统计上本就过度悲观，先进节点用 POCV 而不是继续堆极端角，原因正在于此。

给一个具体的裁剪例子。某 7nm 项目最初列了 6 个模式乘 10 个 corner 共 60 个视图，首轮回归跑了 38 小时。分析后做三件事：烧录模式只在两个功能角查，因为它的工作频率只有峰值的三分之一；扫描移位模式只查 hold 和移位频率，不套功能约束；低温快角下的动态功耗视图与 TT 角结果相关性超过 0.97，删除并保留 TT 为主、快角只跑一次确认。矩阵降到 22 个视图、回归 11 小时，而晶圆厂必查的四个角一个没动。这个比例可以作为直觉来源：实际签收视图通常远少于叉乘总数，关键是每个删减都有覆盖证据。

时序上还有一个反直觉点必须让全团队对齐：先进节点存在温度反转（temperature inversion），低温下某些器件反而更慢，setup 的最坏点不再总是 125°C。签收角清单因此不能照抄老工艺的经验，必须以晶圆厂给该节点的 signoff corner 文档为准。模式侧同理，UPF 描述的电源关断、保持和隔离状态要在时序和功耗两边用同一套电源语义，见 低功耗 UPF 方法，否则睡眠模式的签核结果两边各说各话。

四、工具相关性：为什么要双工具交叉签核 ​

两家 STA 工具的算法、库解析、CRPR（时钟重建悲观消除）口径都有细微差异，单工具全绿在历史上多次被硅后实测打脸。高风险项目（首版工艺、高频设计、车规芯片）的通行做法是双工具关联签核（correlation signoff）：一家工具作为主签核，另一家在关键里程碑独立跑同一快照，比对每条路径的延迟差。

chip-design/expert/33-signoff-methodology-cadence-synopsys-flow.md D2 示意图

结果对不上时，排查顺序比工具本身更重要。九成以上的「工具差异」最终归因于输入不一致：一边读了 signoff 库、另一边读了综合库；一边 SPEF 做了 keep-cap 映射、另一边没做；SDC 的 propagated clock 在一边生效、另一边被 ideal network 覆盖；CRPR 开关和时序减免 derate 表不同。真正由算法造成的残余差异通常在几个百分点内，这个数也要在项目早期用小块已知设计标定出来，作为后续比对的容差基线。工具版本、库版本、命令脚本统一受控管理，做法见 设计数据管理与版本化。

用一个真实尺度的案例说明比对怎么收敛。某高频 SerDes 数字部分，PrimeTime 报 WNS 为 -42ps，Tempus 同视图报 -15ps，差异 27ps，远超项目设定的路径级 15ps 容差。排查按固定顺序走：先核对库与 corner 设置（一致），再核对 SPEF 映射（发现 Tempus 一侧漏了一条 coupling corner 的开关设置，修正后差异缩到 9ps），最后核对 CRPR 口径，统一时钟路径分析方式后差异落到 6ps，落入容差基线，结论才被接受并记录。这个过程产出的不只是一个数字，更是一份「差异归因清单」：哪几皮秒来自 RC、哪几皮秒来自 CRPR、残余多少来自算法。硅后若该路径出问题，这份清单就是判断签核是否失职的直接证据。反过来，如果差异始终无法解释，正确动作是按两个工具中更悲观的结果修，而不是投票选一个好看的。

五、签收标准与 waiver：阈值之外的管理工程 ​

标准分两层：硬阈值和工程余量。硬阈值没有商量空间——WNS/WTS ≥ 0、DRC/LVS 清零、未关闭的 latch-up 风险为零。工程余量则按风险定级，例如 IR drop 要求局部压降不超过标称电压 7%、噪声余量（noise immunity）留 15% 以上，车规项目整体收紧。每条标准要同时写明「在哪个 corner、哪个模式、哪个工具版本下成立」。

签收日的判定不是看一份时序报告，而是看一张标准矩阵：每个签核项在每个必查视图上给出状态列（通过/违例/已豁免），任何一格空白都视为未完成。功耗签核还要区分向量来源——基于典型场景向量、峰值功耗向量（worst-case pattern）和无向量（vectorless）分析三种结果用途不同，峰值向量结果用于电源网格验证，典型向量结果用于封装热设计，不能互相替代。可靠性项如 EM（电迁移）和老化（aging）分析往往要用签核工具在特定角下独立运行，车规客户还会按 AEC-Q100 索要自己的报告格式，这些在立项时就要排进计划，而不是签收前临时补跑。

总有少量违例无法在流片窗口内修掉，这时走 waiver 而非默认放过：

chip-design/expert/33-signoff-methodology-cadence-synopsys-flow.md D2 示意图

waiver 最忌讳两件事：一是口头豁免，流片后没人能回答「这条 hold 违例为什么没人修」；二是永久有效，合理的 waiver 必须绑定失效条件（下一版重检、硅后实测验证、仅本批次 mask）。签收日所有 waiver 汇总成表，未批准项数必须为零，这张表和签核报告一起冻结。

六、收敛迭代：ECO 循环与签核回归 ​

签核不是最后一晚的动作，而是贯穿后端的收敛过程。每轮 ECO（Engineering Change Order，工程变更，见 物理 ECO 与时序收敛）之后必须重跑增量签核，确认修掉的违例没有引入新问题——典型陷阱是为修 setup 插入的 delay 单元在快角打爆 hold，或者补的 filler 触动了密度 DRC。

chip-design/expert/33-signoff-methodology-cadence-synopsys-flow.md D2 示意图

这个循环的纪律是「同一套标准、同一套脚本」：签核回归脚本化、每日定时跑，趋势曲线比单次报告更有价值——违例总量连续三轮不下降，说明修复手段已失效，要升级方案而不是继续加 buffer。增量分析（delta timing、增量 DRC）用于日常快速反馈，但签收轮必须跑全量，避免增量引擎的缓存掩盖问题；二者结论不一致时，以全量为准并复盘增量配置。进入签收冻结周后还要冻结 ECO：任何新改动都要走变更评审，因为此时一个金属跳线都可能同时扰动时序、密度和天线规则。

最终签收时固化的内容包括：数据快照哈希、工具版本与晶圆厂认证证书、各视图报告、waiver 台账、双工具比对归因结论。缺任何一项，签收就不成立；所有产物存入版本库而非个人目录，保证半年后任何人都能按快照原样复现同一组数字。签收之后，这套冻结数据连同报告一起移交给硅后团队，进入 硅后 bring-up 与调试 阶段。

常见坑 ​

  • 各团队拿不同版本的 SDC/SPEF 跑签核，报告拼在一起无法对账。
  • corner 无原则堆叠，回归跑到天级，反而迫使大家跳过部分视图。
  • 双工具比对前没统一输入，把库和 CRPR 设置差异误判成工具算法差异。
  • waiver 只在邮件里存在，没有编号、责任人和失效条件。
  • 只看违例数量不看趋势，收敛后期靠堆 buffer 硬压，埋下 hold 和功耗隐患。
  • 用非晶圆厂认证的工具版本出签收报告，结论不被认可。

这一篇在知识体系里的位置 ​

总结 ​

签核方法论与工具链解决的是「可信与可复现」：用受控的网表/SDC/UPF/SPEF 快照和晶圆厂认证的工具版本，按统计相关性裁剪 MMMC 视图，以 PrimeTime/Tempus、PrimePower/Voltus、ICV/Pegasus 的工具对应覆盖 STA、功耗、物理验证与可靠性各项 signoff，关键设计再以双工具关联比对兜底，最后用前置阈值、带责任人与失效条件的 waiver、脚本化签核回归和固化报告把收敛过程变成可审计的责任移交。