1. 验证签核工程导论

在先进工艺节点下，一颗面向移动、汽车或数据中心的复杂SoC往往集成数十亿门逻辑、上百个IP核、多个时钟域与电源域，并同时运行固件、驱动与操作系统。设计团队可以完成RTL编码、综合与物理实现，但真正决定芯片能否量产、能否按期交付的，是验证签核（Verification Sign-off）这一环节。它不是一个孤立的仿真步骤，而是一套以证据为基础、以风险为边界、以可追溯为要求的工程决策体系。

一、什么是验证签核

验证签核是指：在芯片流片（Tapeout）之前，由验证团队依据预先定义的功能覆盖率、断言覆盖率、代码覆盖率、形式化证明结果、低功耗检查结果以及回归测试状态，对设计是否满足规格（Spec）做出可量化、可审计、可复现的判定，并形成签核报告的过程。它与“验证”有本质区别：验证是持续发现缺陷的活动，签核是在给定时间点对“剩余风险是否可接受”做出结论。

签核的核心产出通常包括：签核检查清单（Sign-off Checklist）、覆盖率收敛报告、未覆盖项豁免说明（Waiver）、已知缺陷与规避方案列表，以及最终由验证负责人、设计负责人与项目负责人共同确认的签核结论。没有这些证据，任何“仿真已通过”的口头结论都不构成签核。

二、签核的目标与判定维度

签核目标可以概括为三句话：功能正确、场景完备、风险可知。落到工程上，通常从以下维度判定：

• 功能覆盖率：规格中定义的功能点是否全部被激励命中，例如AXI突发长度、乱序深度、缓存一致性状态迁移。
• 代码覆盖率：行覆盖率、分支覆盖率、条件覆盖率、翻转覆盖率是否达到项目阈值，通常复杂SoC要求行覆盖率≥95%、条件覆盖率≥90%。
• 断言覆盖率：SVA断言是否全部被激活且无失败，是否存在未被触发的“死断言”。
• 形式化验证：对仲裁器、FIFO、协议转换等模块是否完成等价性证明或属性证明。
• 低功耗签核：UPF/CPF描述的电源域、隔离单元、电平转换器是否通过静态与动态检查。
• 回归稳定性：连续多轮回归是否零失败，失败用例是否已定位并修复或豁免。

这些维度不是并列的“打分项”，而是相互约束的证据链。例如功能覆盖率达到100%但断言存在未触发项，说明激励可能绕过了某些保护逻辑，签核不能通过。

三、复杂SoC验证签核的典型挑战

第一是状态空间爆炸。多核一致性、乱序执行、缓存回填与中断嵌套组合出的场景数量远超仿真能力，必须依靠约束随机、形式化与覆盖率驱动收敛。第二是软硬件协同。SoC上电流程、固件加载、驱动初始化往往在RTL仿真中难以完整复现，需要Emulation或FPGA原型参与签核。第三是低功耗与功能交织。电源关断后的状态保持、隔离使能与唤醒序列，必须在带UPF的仿真中验证，普通RTL仿真无法覆盖。第四是签核标准不统一。不同项目对覆盖率阈值、豁免规则、回归轮次定义不同，导致签核结论难以横向比较。第五是时间压力。流片窗口固定，验证团队必须在有限时间内证明“足够好”，而不是“绝对正确”。

四、Synopsys工具链全景

Synopsys为验证签核提供了覆盖仿真、形式化、原型验证、低功耗与覆盖率管理的完整工具链。理解各工具在签核流程中的位置，比记住工具名称更重要。下图给出工具链与签核证据之间的对应关系。

在动态仿真侧，VCS承担约束随机激励生成、编译与仿真执行，Verdi用于波形调试与覆盖率分析；VC Formal与HECTOR用于属性证明与结构分析；ZeBu与HAPS用于软硬件协同与长序列场景；VC LP结合UPF完成低功耗静态与动态检查；覆盖率数据最终汇总到统一的签核数据库中，供回归收敛与豁免评审使用。

五、一个可执行的签核检查表示例

下面给出一份简化但结构完整的签核检查表，字段与判定依据均来自真实工程实践，可作为项目启动时定义签核标准的参考。表中数值为示例阈值，实际项目需根据芯片规模、安全等级与进度协商确定。

使用这张表时，关键不是填满，而是每一条“未达标”都必须有对应的处理路径：要么补充激励、要么补充断言、要么走豁免评审。签核会议上看的是“未达标项是否都有结论”，而不是“达标项有多少”。

六、从本章出发的学习路径

后续章节将围绕这条证据链展开：如何编写可收敛的覆盖率模型，如何用形式化补足仿真盲区，如何用Emulation覆盖软硬件协同场景，如何用UPF完成低功耗签核，以及如何组织回归与签核评审。本章需要建立的核心认知是：签核不是最后一个动作，而是从验证计划制定时就应被定义的目标。验证计划中的每一条测试、每一个覆盖点、每一条断言，最终都要能回答“它为签核提供了什么证据”。

当团队能够用统一的证据语言描述“我们验证了什么、没验证什么、为什么可以接受”，验证签核才真正从个人经验判断转变为可复现的工程能力。