UVM学习之简单的验证平台(1)

学习参考：UVM实战白皮书-第二章

2.1 & 2.2
 

验证平台的组成

UVM是一种基于System Verilog的验证方法学。

验证平台有哪些组件？组件间是如何通信的？如何保证代码的可重用性？

验证平台的基本组成：driver、monitor、reference model、checker(scoreboard)。

在UVM中，引入了agent和sequence的概念。

搭建验证平台

把UVM添加到验证环境

把下面两行代码添加至tb的module前：

`include "uvm_macros.svh"  //包含很多宏定义

import uvm_pkg::*;  //导入uvm库

driver

可以把UVM当作一个库，driver等组件都用类(class)来实现。

所以，使用UVM的第一条原则：所有组件都应该派生自UVM中的类。

定义的my_driver类派生自uvm_driver，而uvm_driver类派生自uvm_component。

uvm_component类要求new函数有两个参数：name，parent。

UVM由phase来管理验证平台的运行，需要有一个类型为uvm_phase，名称为phase的参数。

UVM采用 树形结构 ，对于树中任何一个结点，都有一个与其相应的字符串类型的路径索引。路径索引可以通过get_full_name函数来获取。

---

testbench中代码：

在new函数中传入参数名“drv”，显式调用了main_phase函数。

factory机制

功能：自动创建一个类的实例并调用其中的function、task。

实现factory机制需要使用`uvm_component_utils宏。

在这里，`uvm_component_utils宏将my_driver类登记在UVM内部的一张表中，以便后续使用。

同时，testbench代码也需要改动：

run_test() 创建了传入的字符串所代表的my_driver类的实例，并且自动调用main_phase。

---

所有派生自uvm_component类（包括它派生类的类）都应该使用uvm_component_utils宏注册。

objection机制

UVM通过objection机制来控制验证平台的关闭。

需要使用raise_objection和drop_objection（成对出现）。

raise_objection必须在main_phase中第一个消耗仿真时间的语句前。

virtual interface

优点：避免绝对路径（另一个方式是使用宏定义，如下图）

定义interface，在testbench中可直接实例化使用，但在my_driver中不能直接使用：my_driver是一个类，不能调用interface。

1.定义interface：

2.在testbench中实例化：

3.在类中使用virtual interface。

---

config_db机制

那么如何将testbench中的interface与my_driver中的virtual interface对应呢？

因为run_test()实例化了一个脱离testbench层次结构的实例，建立了一个新的层次结构。

对于这种脱离了testbench层次结构，同时又期望可以在testbench中对其进行某些操作的实例，可使用config_db机制。

config_db机制分为set(寄信)和get(收信)。

在testbench中执行set操作，在my_driver中执行get操作：

build_phase

build_phase与main_phase一样，都是UVM内建的一个phase，会自动执行。

build_phase在new函数之后、在main_phase之前执行。

在build_phase中主要通过config_db的set和get操作来传递数据、实例化成员变量等。

这里需要加入super.build_phase语句，因为在父类的build_phase中执行了一些必要的操作，这里必须显式调用并执行它。

build_phase是一个函数phase，而main_phase是一个任务phase。因此build_phase不消耗仿真时间，且总在仿真时间为0时执行。