本章从芯片设计流程入手，讨论功能验证在整个流程中的位置及其所涵盖的内容，并介绍目前流行的各种验证技术和验证方法学，最后介绍常用的验证语言SystemVerilog、E、PSL、SystemC、Vera。

1.1 功能验证与验证平台

  验证主要包括功能验证、物理验证、时序验证等，本书主要讲解功能验证，针对芯片设计对象的行为功能进行验证，确保设计能够按照实现预期的效果。通过验证语言。硬件描述语言或C语言等可搭建验证平台（testbench）。
  验证平台需要提高足够的自动化机制来提高每一个测试用例（test case）的功能覆盖率和减少创建测试用例的时间。但是这可能会增加测试平台的复杂度和投入的时间。

1.1.1 专用芯片设计流程

  在图1-1中，功能测试被看做一个独立的模块，实际中包含了定义测试用例、创建测试环境、运行测试用例、保证所有要求的用例被覆盖到等复杂的过程。
  从图中可以看出，验证从设定规范完成后就可以开始了，一种持续到版图完成，甚至很多情况下超出版图完成阶段。

1.1.2 什么是验证

验证是确保设计和预期设计期望一致的过程，设计通常是通过一个或多个设计规范来定义的。对于专用芯片设计，在不同阶段有不同的验证形式：
（1）寄存器传输级（register transfer level，RTL）的功能验证。
（2）门级的仿真，为了验证综合后的网表是否和期望的功能一致。
（3）形式验证（等价性检查）来确保门级网表和RTL代码的一致性。
（4）时序验证，为了验证设计能否在特定的频率上运行，通常采用静态验证工具。
  文中提到的验证（verification）均为寄存器传输级（RTL）的功能验证。功能验证在专用集成芯片设计流程中关注设计的行为，几乎所有的功能都可以在 RTL层次被验证。
  图 １２展示了一个高层次的功能验证视图。一个专用集成芯片设计可以被看成拥有一 系列输入和输出的集合，设计的输出是基于设计的输入和当前的状态。在功能验证的过程 中，工程师在被测设计（design under test，DUT）外搭建验证平台。验证平台被用来应用 一个或者多个测试激励，并将激励发送到设计的输入中。激励可以通过验证平台产生，或者通过手动创建。最后，输出将进行比较，看结果是否正确。结果检查可以通过验证平台、 脚本或者手工来实现。

1.1.3 验证平台可以做些什么

  验证平台的主要功能如下：
（１）产生激励。
（２）把激励应用到被测设计中。
（３）检查结果和验证测试是否通过，也就是确保被测设计的输出和期望一致。

1. 激励产生的途径
   
     如何区分二进制激励和用户激励很重要。二进制激励是驱动到被测设计的引脚中的1 和1序列，如图1-3所示；用户激励是一个来自用户的指令（对信号赋值驱动或者通过对函数或者任务的调用）让验证平台可以运行某些操作。在传统的验证平台中，二进制激励和用户激励可以是一致的。
   
     产生用户激励的途径有很多种，可以是直接的，也可以是随机的。如果激励是从用户 提供的确定输入，这就是所谓的直接测试（direct test）。如果激励是根据种子随机生成，这就是所谓的随机测试（random test）。
     传统验证平台激励过程：按照一定时间顺序把二进制序列送入到被测设计中。
     高级验证平台激励过程：激励在更高层次被用户抽象建模并封装。
     下面以一个存储器的读写来解释直接测试和事务级激励产生。
   ①直接测试
     传统手工创建直接测试，是通过驱动每个信号的数值来实现。
   ②事务级激励产生
     通过对激励和验证架构进行分层和高层 抽象建模，也就是所谓的事务级的验证（transaction based verification），如 本 例 中 的rd_mem，wr_mem这种封装好的任务后，激励生成器可以将其生成的高层激励（可以是一组数据的集合）传递给它，如图 1-4所示，这样可以大大提高激励产生的效率。
     在一个更加高级的验证平台中，激励可以根据用户指定的约束，完全通过验证平台自 动产生，这就所谓的约束随机激励产生（constrained random stimulus generation），如图 1-5所示。例如，用户要把包的大小约束在64比特和1522比特之间，并且在两者之间做一个权重配置方案。验证平台将可以自动生成和将随机包注入被测设计中。
   

2. 应用二进制激励
     最终，验证平台将把一个或者多个激励序列注入被测设计中。验证平台通过高层次的 操作应用高层次的用户激励，二进制激励由验证平台生成并且通过对应的接口发送到被测 设计中。在验证平台中，实现这种功能的验证组件（verification component，VC） 被称为事务处理器（transactor）或者总线功能模型（Bus Function Model，BFM）。在本书中，我们采 用事务处理器作为表述。

3. 结果检查
     生成和应用二进制激励到被测设计中是验证平台的主要任务。此外，验证的目的是检查输出是否与预期一致，也就是结果检查。检查结果的方法有：
   （1）**波形窗口检查：**适用于简单设计，可能出现人为错误，而且不精准。如果这个设计需要回归测试，那么一定程度上的自动化结果检查是必要的。
   （2）**通过自动化的后处理比较：**记录被测设计的输出，通过运行脚本来比对结果。结果后处理是常用的一种手段，既不需要添加太多代码，又不会影响仿真效果（过多的打印信息可能会导致仿真速度下降，因为对文件I/O操作过多）。复杂的设计中，必须考虑要打印的信息，以免太多造成过大的日志文件。可以考虑通过高层抽象来记录信息，以减少日志文件。
     结果后处理的因一个好处就是，结果可以由其他语言来实现后处理，如C/C++、perl。但是只能在测试结束之后才能进行，出错的话需要重新进行仿真，浪费很多时间。
   （3）**做一个实时的监察器可以及时自动检查：**实时的监控器需要投入额外的开发，然而 它们相当有用，特别是对于调试，一旦发生比对错误，它们可以通过设置错误标志或者打 印信息提醒用户；在任何时刻，仿真器和验证平台的状态对用户完全可见，而且在发生错 误的时刻，通过停止仿真可以缩短调试周期。
   目前较多应用后处理和实时两种处理方法，这取决于设计的复杂度和 接口的数目以及验证平台的应用层次。

1.1.4 功能验证流程

  图1-6显示了功能验证流程。这个验证过程可以被分解成三个主要阶段：（1）制定验证策略和验证计划；（2）创建验证平台，运行和调试；（3）覆盖率分析和回归测试。
1.制定验证策略和验证计划阶段
制定验证策略和验证计划阶段主要处理以下三个问题。
(1)主要功能点和测试用例
  复杂设计需要的测试点非常多（即测试空间很大），可达上亿个，因此需要将测试空间缩小到一个可以管理的范围，并且不会损害其期望；针对这些功能点，我们将根据具体情 况拟定验证策略和测试用例，最后具体化到一个详细的、可执行的验证计划中，作为整个 验证工作的指导。
（２）验证平台的抽象层次
  验证平台的抽象层次将决定它主要的处理对象：比特、包或者更高层次的数据类型。 高层次的抽象建模可以让验证平台中低层次的功能自动化。
（３）激励生成和结果检查原则 这些原则定义了输入到验证平台的激励是如何提供的，结果是如何检查的，并判断测 试是通过还是失败。
２. 验证平台搭建阶段
  这是第二个阶段，也就是验证平台的搭建，书写测试用例和调试阶段。在这个阶段， 书写验证平台代码和测试用例。验证平台持续被扩展，因为测试用例不断被添加进来。其 中，验证平台的搭建要以可重用为基本原则，而且能够方便设计工程师和验证工程师添加 测试用例。
３. 回归测试和覆盖率收敛阶段
  一旦几乎全部测试用例被成功运行，验证就进入了回归测试 （ｒｅｇｒｅｓｓｉｏｎｔｅｓｔ）和覆盖率 收敛阶段。回归测试要求能够周期的批处理运行，二是激励必须能够容易得到重现，成功 或者失败能够自动检查。覆盖率显示出该设计被测试的程度，是验证收敛的重要标准。
  在这个阶段，所有的测试应该在每天或者每周做回归而且周期性的运行。设计或者验 证工程师应该查看覆盖率，从而修改或者添加更多的测试用例。目标是达到 100％，或者尽 可能达到 100％。
  不同的设计有不同的验证流程。不存在一个对任何设计都为最好的验证流程。每个设 计都有其不同的地方，而且有自身的验证流程。例如简单的设计，激励产生和结果检查策略可能将不会被显示的定义。它们可能运行在总线层次的事务交易中，验证平台使用传统的直接测试，但是它也可能不做检查。对于复杂的设计，所有的激励生成方法或者结果检查规则都是预先定义好的。一般来说，对于这些设计的验证平台都 是在一个较高的抽象层次上操作。
  验证流程同样也可能取决于被验证设计的层次，也就是它将验证多大规模的代码。例 如，一个芯片可以分解为几个模块。为此，可以为每个模块搭建一个独立的验证平台，同 时可以有一个验证平台在芯片级做验证。某些设计，芯片可能是一个系统，可能存在几个 芯片级或者系统级的验证平台。
  每个模块级的验证平台主要的目的是帮助调试各个模块中的实现，使集成到芯片中更 加容易，然而芯片级的验证平台主要测试的是各个模块之间的交互功能。

参考书籍：SystemVerilog与功能验证