第1章 验证的基本概念与功能正确性目标

1.1 问题背景：为什么验证是数字IC的第一道关口？

数字芯片从规格定义到流片，主要经历架构设计、RTL实现、功能验证、逻辑综合、物理实现等环节。其中，功能验证是唯一系统性发现设计缺陷的环节。一颗芯片在流片前未能发现的功能bug，一旦进入晶圆厂，就意味着数百万到数千万的改版成本，以及数周的上市时间损失。

• 规模压力：一个SoC常包含数十个IP、百亿级晶体管，微小的逻辑错误可能触发系统性失效。
• 时序风险：RTL功能正确只是起点，协议时序、跨时钟域、异常路径均需验证覆盖。
• 成本杠杆：越早发现bug，修复成本越低。验证的核心价值就是把错误消灭在流片之前。

1.2 核心概念：验证到底是什么？

验证是确认设计实现与设计规格一致的系统工程。它不只是“跑仿真”，而是围绕功能正确性展开的闭环证据链。一个设计是否“功能正确”，应从以下维度回答：

• 逻辑功能：运算、跳转、数据通路是否按规格工作。
• 协议正确性：总线握手、时序窗口、信号间相对关系是否合规。
• 异常处理：复位、中断、超时、越界等异常路径是否安全。
• 系统集成：多个模块互联后是否保持一致性，不产生死锁或数据损坏。

验证工程师的核心任务，就是构造足够信任的证据，说明“设计在这些维度上满足规格目标”。

1.3 原理机制：验证为什么能发现bug

功能验证的本质是一个激励-响应-检查-覆盖率的闭环。测试平台向DUT施加激励；DUT与参考模型同时响应；计分板自动比较二者的输出；断言实时监视信号级行为；功能覆盖率记录关键功能点的命中情况。

• 动态仿真：通过事件驱动仿真器执行RTL模型，是功能验证的主要引擎。
• 参考模型：用SystemVerilog、C/C++或高级语言构建的高层规格模型，与DUT独立实现，用于比对。
• 断言SVA：将时序、协议和内部条件写成可执行的属性，出现违规时精确报告周期与位置。
• 功能覆盖率：将规格功能点映射为覆盖率模型，量化“测了哪些、还差哪些”。

1.4 流程步骤：从验证计划到收敛签收

1. 提取功能点：从设计规格中拆分出可观测、可判定通过/失败的验证功能点。
2. 搭建验证环境：构建驱动器、监测器、参考模型、计分板、断言和覆盖率模型。
3. 开发测试用例：编写定向用例覆盖边界与异常，编写约束随机用例覆盖大规模空间。
4. 仿真与调试：运行用例、收集失败波形、定位设计或环境bug、修复后重跑。
5. 覆盖率分析：合并代码覆盖率、功能覆盖率和断言覆盖率，标记未覆盖项并补充用例。
6. 回归与签收：全部用例通过且覆盖率达标，输出验证报告，确认功能正确性证据完整。

1.5 案例说明：一个ALU功能验证场景

设有一个8位ALU，规格要求支持加、减、与、或、按位异或、逻辑左移、逻辑右移共7种操作，并输出zero和carry标志。验证计划可以这样拆解：

• 操作数A和B覆盖边界值：0、1、127、128、255。
• 操作码op覆盖全部7种功能。
• 加法需检查进位产生与标志位更新；减法需检查借位。
• zero标志在结果为0时置位，其余情况清零。

针对边界约束，可以构造如下随机事务类：

class AluTrans;
  rand bit [7:0] a;
  rand bit [7:0] b;
  rand bit [2:0] op;

  constraint c_operand_bound {
    a inside {0, 1, 127, 128, 255};
    b inside {0, 1, 127, 128, 255};
  }
endclass

在验证环境中，参考模型计算预期结果；计分板比较DUT输出与参考模型输出；断言检查carry和zero的更新时序。这样的闭环能自动发现“某条指令结果错误”或“标志位晚一拍更新”等典型功能bug。

1.6 核心概念速查

1.7 常见误区提醒

1.8 本章实践清单

• 从当前设计规格中提取至少3个可观测功能点，并说明每个功能点如何判定通过/失败。
• 检查验证环境是否有独立参考模型和自动计分板；如果目前只靠波形目测，立即建立自动比对机制。
• 为关键时序、总线协议或内部状态设计至少5条SVA断言，并纳入回归。
• 建立冒烟回归集，确保每天合入代码后能在15分钟内完成基本功能检查。
• 为每个新增测试用例标注其覆盖的功能点，从第一天开始维护“功能点到用例”的追溯关系。