7.1 签核判据：谁说了算零违例

7.1 签核判据：谁说了算零违例

本节摘要：签核判据不是一句"零违例"，而是一套分层的验收标准：在哪些场景查、用什么库与 derate 查、零违例之上再留多少寿命与制造护栏、谁对每一层负责。本节给出判据的完整构成与一份可复用的裕量政策模板。

所谓签核（signoff），是项目把"时序正确"从工程判断升格为责任承诺的仪式。仪式的核心是一份判据文档：它把"多干净算干净"写成可验收的条款，让设计、后端、代工与市场对同一组数字负责。判据写不清楚的项目，会在流片前夜反复上演"这个违例要不要紧"的争论——那不是技术问题，是判据缺位。

一、判据的四层构成

第一层是场景清单：列出全部签核场景（模式与角的组合，7.4 展开）及每个场景的检查类型。第二层是工具与数据配置：每个场景用哪套库、哪套 RC、derate 与不确定度取值、串扰是否打开——同一份网表在不同配置下的结论天差地别，配置本身就是判据的一部分。第三层是验收阈值：建立与保持的 slack 上限（通常为零，留有政策余量的写成正数）、WNS 与 TNS 的双重门槛、违例端点数为零。第四层是例外与豁免清单：全部伪路径与多周期声明的清单与理由，评审通过才生效（4.3 的审计证据附后）。

四层里最容易被轻视的是第二层。工具版本升级会改变优化与计算细节，签核前明确"以哪个版本、哪套配置的输出为准"，并在流片前冻结配置——不少项目的"最后一夜惊魂"来自有人用新版本工具重跑了一遍，数字变了，判据却没定义以谁为准。

图：签核裕量的三层护栏

验收阈值的两种口径之争

阈值看似只有"零违例"一个选项，工程上却有口径之争。第一种是逐路径零违例：每个端点在所有场景 slack 不小于零——最严格，代价是尾部路径的修复成本指数上升。第二种是统计验收：允许极小比例的端点带浅违例，但要求整体违例概率低于良率目标（5.3 的语言）——更经济，但需要良率模型与商业侧的背书。多数项目采用折中：功能与测试模式逐路径零违例，仅对少数有数据支撑的浅违例（如重复冗余路径）做个案豁免。争论的价值不在选哪种，而在"选了哪种必须写进判据文档"——验收口径漂移的签核，等于没有签核。

二、裕量政策：数字从哪里来

护栏数值不是经验玄学，每层都有推导路径。第二层的 derate 来自片上变异的表征数据（库厂提供或自测），POCV 的 sigma 直接来自库文件；第三层的老化护栏来自可靠性仿真——以 BTI 老化模型为例，十万小时漂移折算成延迟增量，典型在 3% 到 8% 之间，电压温度越激进数值越大；压降余量来自电源网络分析与动态压降仿真，常见做法是把最坏 IR drop 加进签核电压（5.1 的联动）。政策文档的形态可以很薄——一张表写清每个场景的每层取值与出处：

场景            库角           derate(late/early)   老化护栏   压降折算
setup_slow      SS 0.72V 125C  1.05 / 0.95          5%         Vmin=0.72 已含 IR
hold_fast       FF 0.99V −40C  1.05 / 0.95          0%(hold)   Vmax=0.99
setup_slow_lowT SS 0.72V −40C  1.05 / 0.95          5%         温度反转场景
（出处栏：derate＝片内变异报告 v3；老化＝BTI 模型 100k 小时；压降＝PI 仿真 revB）
​

这张表就是签核的"宪法"：所有报告、所有修复决策都引用它。它也是审计对象——评审时每个数字问一句出处，表里答不上的数字就是隐患。

三、谁签字、签什么

签核的责任分配通常按层级走：单元库与存储签核由库团队对代工承诺；IP 级签核由 IP 供应商对集成方承诺；全芯片签核由时序签核负责人对项目承诺。签字的实质是"以上述四层判据为准，验收阈值全部满足"。因此判据文档的第一页应当是责任矩阵——每一层谁写、谁审、谁批准——这比任何技术细节都更能决定签核流程的质量：责任清楚的签核快，责任含糊的签核永远在扯皮。

对修复团队（第六章）的直接影响是：判据给修复划定了终点。修到"看起来干净"没有意义，修到"判据文档定义的全部场景、按冻结配置、零违例且护栏足额"才是终点。7.4 的矩阵就是把这个终点变成一张可勾选的表。

签核报告的固定目录

一份能通过审计的签核报告有固定目录，缺页即退回：第一页是判据引用（政策表版本、工具与库版本、配置冻结声明）；第二部分是场景矩阵总表（每场景的 WNS、TNS、违例端点数、运行时间与日志哈希）；第三部分是最差路径集（每场景若干条，含完整展开的时序报告）；第四部分是例外清单与命中审计；第五部分是护栏证据（derate 出处、老化标定、压降地图版本）；最后一页是责任矩阵签字。把目录模板化带来的效率提升惊人：签核会议从"到处找证据"变成"按页核对"，新项目的签核周期平均能压缩两到三成——这不是提速工具，是提速信任。

判据文档的最小骨架

给想落地的团队一份判据文档的目录骨架：第一章范围与引用（覆盖哪些设计、引用的政策版本）；第二章场景定义（矩阵表＋裁剪留痕）；第三章工具与数据配置（版本、库、RC、SI 开关、冻结声明）；第四章验收阈值（两本账的口径、豁免规则）；第五章护栏与出处（derate、老化、压降三栏出处表）；第六章责任矩阵（谁写谁审谁批准，逐层签字）；第七章附录（check_timing 输出、例外审计、全矩阵对比表）。这份骨架可以直接当模板抄——判据文档写得好不好，从目录就能看出来。

本节要点回顾

• 签核判据四层：场景清单、工具配置、验收阈值、例外清单，缺任何一层签核都站不住。
• 配置冻结是前提：工具版本与数据配置在流片前锁定，签核以冻结配置的输出为准。
• 护栏有推导：derate 出自变异表征、老化出自 BTI 模型、压降出自 PI 仿真，政策表每个数字要有出处栏。
• 裕量贵在精确：每皮秒护栏都兑换成面积功耗，慷慨的政策是另一种浪费。
• 责任矩阵先行：谁写谁审谁批准，签核速度的上限由责任清晰度决定。

判据就位之后，还有一层护栏值得单开一节：时间维度。芯片老化、金属迁移、电压跌落都在悄悄改写延迟——下一节把这些"慢变量"算进签核。