PDK 与签核基线：给「同一颗芯片」下一个可复现的定义（F10）
前面每一站都在说「同版本」「锁基线」，本篇把这套贯穿全流程的纪律讲透：当我们说时序/功耗/物理验证 clean 了，这个 clean 是相对于哪一套工艺数据、哪一组角、哪一版规则和哪个工具版本说的？ 四者只要有一项在流程中途漂移，前面攒下的所有「已签收」都会失去意义。这也是 S5 签核枢纽 四元组的来源。
一、签核基线四元组
- 角（corners）：签核覆盖哪些 PVT 角（如 SS/TT/FF × 电压 × 温度）与 RC 角（cbest/cworst/ccworst），角清单本身也要版本化（组织方式见 X2 MMMC）。
- 库与工艺文件：Liberty（F3）、LEF/DEF 技术文件（F4）、单元 GDS（F8）、寄生工艺表 tlu+/itf——它们是同一颗单元的不同视图，必须同 PDK 版次。
- 规则套件（rule deck）：代工认证的 DRC/LVS/ANT/PERC 命令文件，版本与 PDK 绑定。
- 工具版本：签核工具（STA/RCX/物理验证）的具体版本与补丁——同一 deck 换个工具版本结果可能不同。
二、为什么「同一颗单元三视图」必须同源
标准单元在库里有三张脸：LIB 描述时序/功耗、LEF 描述抽象边界与引脚、GDS 描述真实硅几何。若 LIB 与 GDS 来自不同 PDK 版次，单元时序按旧尺寸算、硅上却印新尺寸；LEF 引脚位置和 GDS 不一致会直接 LVS/DRC 失败。三视图必须共享同一个库版本号，硬宏还要加版本与认证状态。
三、manifest：让 run 目录自证身世
严肃项目要求每个关键 run 目录带一份 manifest / 数据清单，记录每个输入文件的 provenance：
| 字段 | 作用 |
|---|---|
| 逻辑路径 + checksum | 防同名旧文件被误用，可逐字节复算 |
| 来源 release 标签 | 指向 PDK/IP/设计的具体发布版 |
| 视图/角/模式标识 | 标明 lib 角、SPEF 角、对应 scenario |
| 生产者与生成命令 | 哪个工具版本、什么命令、何时产出 |
| 原子版本归属 | 网表/DEF/SPEF 是否同一组发布（见 S4） |
有 manifest，半年后审计「这个签收基于哪套数据」才能秒答；靠软链和目录约定口头相传，迟早混版。
四、版本变更的作废规则（不是全重跑，但要声明影响面）
| 变更 | 必须作废重跑的下游 |
|---|---|
| Liberty 换版 | 综合/STA/功耗，受影响角全重签 |
| tech LEF/tlu+ 换版 | P&R、寄生提取、STA |
| DRC/LVS deck 换版 | 物理验证重跑，可能触发版图改 |
| RC corner 定义更新 | SPEF 重提 + STA/IR 重签 |
| 工具大版本升级 | 对应签核项重认证（correlate 后才采信） |
原则：基线是一个整体，任何一元变更都要显式评估影响面并重新会签，而不是「只悄悄换掉那个文件」。
五、典型交接事故
| 事故 | 根因 | 拦截 |
|---|---|---|
| clean 但对错工艺 | 中途换库未重签 | 四元组锁定 + 变更作废规则 |
| 单元三视图打架 | LIB/LEF/GDS 不同版 | 同库版本号，发布前互校 |
| deck 过期违规 | 用旧 rule deck 自检 | deck 版本入 manifest，代工认证号核对 |
| 结果无法复现 | 无 provenance 记录 | run 目录强制 manifest+checksum |
| 工具升级引偏差 | 升级后直接采信 | 版本 correlate 后再切换基线 |
相关与延伸
总结
签核基线是「工艺角 + 库视图 + rule deck + 工具版本」锁定在同一认证 PDK 版次上的四元组，再用 manifest 给每个文件留下 provenance；任何一元变更都要声明作废范围并重新会签——clean 的可信度，永远只相对于它背后那套被锁定的基线。