1. 流片签核交付工程总览

在先进工艺节点下,一颗芯片从设计收敛到真正进入晶圆厂投片,中间隔着一道极其严格的“签核闸门”。Calibre 正是这道闸门上的核心工具链:它不参与功能设计,也不负责时序优化,而是以物理验证与可靠性检查的“裁判”身份,回答一个决定性的问题——这版 GDS 能不能交给 Foundry 去流片。理解 Calibre 在 IC 设计流程中的签核定位,是建立整套交付工程认知的起点。

Calibre 在流程中的签核定位

从设计流程看,前端 RTL 综合、后端布局布线、时序签核(STA)解决的是“电路逻辑是否正确、时序是否收敛”;而 Calibre 所在的物理验证环节解决的是“版图是否可制造、是否满足 Foundry 的工艺规则”。两者是正交的:时序全绿不代表 DRC 干净,DRC 干净也不代表 LVS 通过。因此 Calibre 签核通常被安排在物理实现基本收敛之后、GDS 交付之前,作为流片前的最后一道自动化关卡。

Calibre 的签核内容并非单一检查,而是一组并行且相互独立的验证任务,常见包括:

  • DRC(Design Rule Check):检查版图几何是否满足工艺最小线宽、间距、包围、密度等规则。
  • LVS(Layout Versus Schematic):比对版图提取网表与原理图网表,确认器件、连接、参数一致。
  • ERC(Electrical Rule Check):检查浮空栅、衬底连接、电源短路等电气规则。
  • 天线检查(Antenna):检查金属与多晶硅在制造过程中积累电荷是否超过栅氧击穿阈值。
  • DFM / 密度 / 填充检查:保证化学机械抛光(CMP)均匀性与良率相关规则。
  • PERC(可靠性检查):如 ESD 路径、闩锁(Latch-up)等可靠性规则。

这些任务共享同一套工艺规则文件(Rule Deck),但运行相互独立,任何一项未通过,GDS 都不能被视为可签核状态。

交付物清单

流片签核交付不是“跑完 Calibre 就结束”,而是向 Foundry 提交一整套可追溯的证据包。典型交付物包括:

交付物内容说明责任方
GDSII / OASIS最终版图数据,含所有层次与填充版图/后端
Calibre 运行脚本各检查项的 runset 与命令行物理验证工程师
DRC/LVS 报告汇总结果、违例数、waiver 说明物理验证工程师
LVS 提取网表由版图提取的 SPICE 网表物理验证工程师
天线/ERC/PERC 报告各专项检查结论物理验证工程师
签核检查表(Checklist)逐项确认与签署记录项目负责人

其中“签核检查表”是工程管理的核心,它把每一项检查、版本号、运行日期、结果状态、豁免理由固定下来,形成可审计的交付记录。

责任矩阵与里程碑

签核交付涉及多个角色协同。用 RACI 思路可以清晰划分:版图工程师负责修改违例(R),物理验证工程师负责运行与判定(R/A),后端负责人对整体收敛负责(A),Foundry 接口人负责规则版本确认(C),项目经理负责里程碑推进(I)。

里程碑通常按“规则冻结 → 首次全量签核 → 违例收敛 → 最终签核 → GDS 交付”推进。每个里程碑都有明确的准出条件,例如首次全量签核要求所有检查项至少跑通一次并输出基线违例数。

Calibre 流片签核交付工程总览 规则冻结 Rule Deck 版本确认 首次全量签核 建立违例基线 违例收敛 修复与豁免 最终签核 全项通过 GDS 交付 Calibre 签核检查项 DRC 几何规则 LVS 网表比对 ERC 电气规则 Antenna 天线 PERC 可靠性 DFM/密度 交付物证据包 • GDSII/OASIS 最终版图 • Calibre runset 与运行日志 • DRC/LVS/ERC/Antenna/PERC 报告 • LVS 提取网表 • Waiver 与豁免说明 • 签核检查表(Checklist) 责任矩阵(RACI) 版图工程师 R:修复违例 物理验证工程师 R/A:运行与判定 后端负责人 A:整体收敛 Foundry 接口人 C:规则版本确认

从“跑通”到“可签核”的关键判断

初学者容易把“Calibre 无报错”等同于“可以流片”,这是危险的误解。真正的签核判断包含三层:第一层是工具层面,检查是否正常结束、是否有 license 中断、是否读取了正确的 GDS 与 Rule Deck 版本;第二层是结果层面,违例数是否为零,或所有非零违例是否都有经 Foundry 认可的 waiver;第三层是工程层面,检查表是否完整签署、交付物版本是否与最终 GDS 一致。

注意:Rule Deck 版本必须与 Foundry 当前发布的工艺版本严格对应。使用过期规则文件跑出的“全绿”结果不具备签核效力,这是流片交付中最常见也最致命的错误之一。

因此,交付工程的核心不是“会跑 Calibre 命令”,而是建立一套可重复、可追溯、可审计的签核体系:固定规则版本、固定运行脚本、固定报告格式、固定检查表,让每一次签核结果都能被复现和验证。这正是本课程后续各章节要逐步展开的工程能力。