通用验证方法学

通用验证方法学（英语：Universal Verification Methodology, UVM）是一个以SystemVerilog类库为主体的验证平台开发框架，验证工程师可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境。它是第一个由电子设计自动化领域三巨头（Cadence、Synopsys和Mentor Graphics）联合支持的验证方法学，其最新版本为1.2版。

概述

最原始、最简陋的Verilog测试平台通常会做以下几件事情：第一，在测试平台模块中例化被测设计；第二，创建若干变量（通常是reg类型），将它们连接到被测设计的输入端口，并在过程代码块（通常是initial块）中的不同时间点对它们进行赋值，使这些变量充当被测设计的输入激励；第三，采集被测设计输出端口的信号，或者直接采集被测设计的内部信号；第四，在测试平台模块内建立一些功能模块，将采集到的信号与根据之前设计规范预测的参考数值进行对比，然后输出一些信息以方便故障的排除。
这样的验证模式对于简单的被测设计尚可，但是如果被测设计的复杂程度较高，这样的测试平台将会变得十分臃肿，而且不利于工程师维护和重用。例如，如果验证人员想在原有输入激励基础上添加一系列新的测试序列，则很可能会牵一发而动全身，影响测试平台的其他部分。工程师需要将验证平台的不同组分，例如输入激励、输出采集、记分板对比等不同部分相互隔离。在超大规模集成电路已经是主流的今天，Verilog结构化的编程方式使代码的复用成为了一个严重的难题。
虽然SystemVerilog的面向对象编程特性提供了解决了上述问题的可能，但是仍然存在一些问题。工程师有了更灵活的语言，但是怎么用这种语言来搭建验证平台却是没有明确规范的，因而不同人搭建的验证平台在结构上会有差异。最明显的是，不同工程师对于验证平台功能的划分可能不一样，即使采用同样的划分，其中同类模块对外的接口（方法和数据成员）也没有统一的标准。这在一定程度上阻碍了大型验证平台之间的协作性、扩展性（假设某公司的两个团队分别负责验证平台的输入激励部分和输出信号比较部分，却各自使用了非标准化的事务接口，其结果是他们将耗费大量的时间对各自的代码进行修改，这将大大延缓芯片的上市时间）。验证方法学提供了一套基于SystemVerilog的类库，验证工程师以其中预定义的类作为起点，就可以建立起具有标准结构的验证平台。
由于行业竞争的关系，历史上不同厂商曾推出了数种略有差异的验证方法学。使用不同验证方法学的验证平台之间的互操作性仍有一定的障碍。为了进行实现验证方法学的标准化，早在2009年12月，Accellera（电子设计自动化行业的一个致力于标准化的组织）内部就通过投票，决定以之前的开放验证方法学2.1.1版为基础，构建一个新的功能验证方法学。在此之前，不同的电子设计自动化厂商相继推出了自己的验证方法学，例如开放验证方法学就是Cadence和Mentor Graphics合作推出的。这种情况就造成了不同验证方法学之间的协同工作需要工程师额外的精力。2011年2月21日，Accelera通过了通用验证方法学的1.0版，并得到了三大厂商的共同支持。目前最新版本为1.2版。

顶层模块和测试类之间的关联

上面简历的这个顶层模块（非面向对象部分）不属于测试类所在的类、对象层次结构之中，一般使用常规的Verilog或SystemVerilog模块（module）来构建。这种结构不具备面向对象特性，它和测试类（面向对象部分）的联系是通过以下两步建立的。

run_test()方法

首先，当顶层模块执行run_test()方法（这是个类库自带的方法，调用者无需关心其具体定义）时，通用验证方法学引擎会在后台执行一系列操作来建立测试环境。验证人员在启动类似Synopsys VCS之类的仿真工具之前需要制定测试名称，仿真工具执行到run_test()方法时会去查找名称与之相同的测试类（由uvm_test类继承），找到之后会创建这个测试类的一个对象（在整个面向对象部分，这个对象的实例化由通用验证方法学引擎而非用户完成，且该实例名称为uvm_test_top），然后根据人为的实例化语句来逐层创建测试类中的环境类、代理类、驱动器类等的对象层次结构）。这些对象所属的类都是从通用验证方法学预定义的基类继承而来，验证人员需要覆盖一些特定名称的方法，通用验证方法学的引擎在执行仿真时会自动调用这些方法，来达到驱动被测设计、采样所需信号的目的

接口

接口（interface）是连接验证平台顶层模块（非面向对象部分）和测试类（面向对象部分）的桥梁（参见总线功能模型）。
顶层模块还必须将所用的接口在工厂，即配置数据库（uvm_config_db，详见本条目后面相关章节）里注册（执行set静态方法），然后测试所在的面向对象部分可以在工厂里将其取出（执行get静态方法）。这是因为，顶层模块并不在测试部分的类属层次关系之中，因此顶层模块与测试之间的关联必须使用这样的特殊的方式建立起来。在配置数据库中注册的接口相当于一个大的全局变量，联系着整个验证平台的非面向对象硬件描述语言部分（被测设计实例）和面向对象硬件验证语言部分（真正测试部分各种类的实例，具有面向对象编程的若干层次）。
测试类获得这个接口之后，会负责将它在测试类这一端连接到测试类内部的相关组件（如驱动器、监视器等）。顶层模块的被测设计和测试类不直接通过信号名称匹配相连（类似Verilog中的端口连接），而是分别只对接口内的信号进行读写。

虚接口

接口是在顶层模块被实例化，并与被测设计实例进行连接的。理论上，测试类部分的成分，例如驱动器、监视器，也需要实例化一个接口，并通过配置数据库与顶层模块中的接口实例进行匹配。测试类中的这个接口在实例化时，必须使用关键字virtual关键字进行声明。将配置数据库中的接口取出，并赋值给此虚接口，就可以将测试类和顶层模块联系起来。

测试类

由测试基类uvm_test继承。
整个验证平台中除去顶层模块、被测设计之外的面向对象部分，其顶级类被称为测试类。测试类通常负责实例化一个环境、一个序列，并调用序列实例的start(sequencer)方法来启动一个环境实例的代理实例的序列产生器。

环境类

由环境基类uvm_env继承。
记分板实例、订阅者实例（如功能覆盖统计模块）也在环境中被创建，它们通常不直接读写那个与顶层模块直接相连的接口。与那个接口发生直接关系的驱动器、监视器都由环境实例内的代理实例包裹。通过使用通信接口，事务包由代理生成，传输给记分板和覆盖统计模块。

代理类

由代理基类uvm_agent继承。

序列发生器类

由序列发生器基类uvm_sequencer继承。这一继承是参数化继承，需要指定与其相关的序列项目类的名称。
序列发生器不需要定义数据成员和方法。一旦高层次的测试中创建了一个序列实例，然后在测试类实例中执行了类似sequence.start(env.agent.sequencer)这样的开启方法，序列发生器实例就在后台将连串的数据包发送出去（开发人员无需关注数据包是怎么发送出去的，这些操作由uvm_sequencer这个基类中定义的方法来完成）。开发人员只需要在驱动器类中调用其基类成员之一的seq_item_port通讯端口的get_next_item(sequence)方法，驱动器就能获得数据包。

驱动器类

由驱动器基类uvm_driver继承。这一继承是参数化继承，需要指定与其相关的序列项目类的名称。
驱动器是代理中直接与被测设计发生作用的部分。它本身并不知道如何产生激励信号，它只是调用get_next_item(sequence)方法，从序列发生器接收的一系列数据包，然后将包中对应的信号通过赋值施加到整个测试平台的公共总线接口上，从而间接地给被测设计提供了所需的输入激励。

监视器类

由监视器基类uvm_monitor继承。
监视器是一个被动的模块，通过接口和被测设计中的信号相连。获得要监测的数据包（或者单独的信号）之后，监视器只负责将这些信息通过通讯端口发送出去，至于谁来接收这些信息则由其他模块类关心。通常的做法是，在监视器类里声明分析端口uvm_analysis_port类的实例，调用该实例的write方法将获取的信息放置到分析端口上。这相当于监视器向外界“广播”内容，然后由对此感兴趣的模块（订阅者）负责接收。

记分板类

由记分板基类uvm_scoreboard继承。
记分板不直接与被测设计发生互动，而是通过通讯端口，从监视器那里获取后者提供的事务（数据包）。记分板的run_phase()方法（任务）通常会提取出数据包中的信号，然后将它们与预设的参考模型进行对比，从而验证被测设计的功能是否与预期相同。如果不同，验证人员可以选择在屏幕上显示提示或警告，或者直接中断仿真的运行。

订阅者类

由订阅者基类uvm_subscriber继承。这一继承是参数化继承，需要指定与其相关的序列项目类的名称。
覆盖统计模块通常是一个订阅者。

序列类

由序列基类uvm_sequence继承。。这一继承是参数化继承，需要指定与其相关的序列项目类的名称。
序列类不需要定义任何与phase有关的方法，开发人员只需要覆写task body()方法（任务）。此方法内部一般会调用`uvm_do(sequence)方法宏，其结果是使用定义好的序列项目来输出一系列事务序列（一连串事务包，或数据包），这些事务序列将有驱动器接收，进而施加给被测设计。如果序列项目类的数据成员被声明为随机变量（例如使用rand），随机化方法randomize()会在调用`uvm_do生成数据包时被隐式地调用。

序列项目类

由序列项目基类uvm_sequence_item继承。
序列项目定义了了数据包每一帧包含哪些数据成员，这些数据成员可以被声明为SystemVerilog的随机变量类型（rand或randc）。通常不需要在这个类中定义任何方法。这个类的实例会作为序列类的`uvm_do(sequence_item)方法的参数，自动进行数据的随机化（前面这个方法宏内嵌了randomize()这样的随机化方法，这些都在后台由验证方法学引擎控制运行），进一步产生连串的数据包。

配置数据库

前面提到了在顶层模块中实例化和使用的接口可以通过配置数据库（uvm_config_db）传递给测试类。配置数据库本身是个参数化的类。配置数据库的使用方法通常为调用其静态方法而非实例化，最常用的两个静态方法分别为set()（存）和get()（取）。和实例方法使用.（点号）来连接实例名和实例方法名来调用不同，静态方法使用::（双冒号），类的作用域操作符）来连接类名和静态方法名来调用。