uvm 形式验证_UVM入门学习笔记（二）

INTRO

本节内容主要来自《UVM实战》的第三章的前半部分，详细介绍了一些UVM中的基础知识点，如UVM类继承关系，UVM的树型结构和field automation机制。

UVM类继承关系

在前一篇文章的简单的UVM框架Testbench中，我们曾提到继承自uvm_component的类可以作为UVM树的节点，有与验证平台一样的生命周期；继承自uvm_object的类生命周期短于验证平台，通常作为一些临时部件类或传递的信息类等。其实，uvm_component本身也是继承自uvm_object的，其具体的继承关系如下图所示。

从图上给可以看出，除了driver, monitor, agent, model, scoreboard, env, test之外的几乎所有类本质都是uvm_object。uvm_component相比uvm_object多出来的功能有两点：一是增加了new函数的parent参数，使其可以构成UVM树的结构；二是有phase的自动执行的特点。

需要注意的是，UVM中并没有特别针对reference model的基类，因此通常来说，reference model直接派生自uvm_component。由于不要求可综合性，reference model可以直接使用SystemVerilog，或通过DPI接口调用其他高级语言。

有了继承自uvm_object类或uvm_component类的子类后，还可以通过UVM强大的预定义的宏来实现丰富的功能，如实现factory机制等。与uvm_object相关的factory宏有：

• uvm_object_utils：用于将一个直接或间接派生自uvm_object的类注册到factory中。
• uvm_object_utils_begin：使用这个宏来开启field_automation机制。
• uvm_object_utils_end：与uvm_object_*_begin成对出现，作为factory注册的结束标志。

与uvm_component相关的factory宏有：

• uvm_component_utils：用于将一个直接或间接派生自uvm_component的类注册到factory中。
• uvm_component_utils_begin/uvm_component_utils_end：同上。

值得一提的是，uvm_component_utils_begin用于同时需要使用factory机制和field_automation机制注册的类。也许在前一篇文章中提到的my_transaction类中使用field_automation比较好理解，field_automation对于uvm_component类还有自动地使用config_db来得到某些变量的值的意义。

由于uvm_component相比uvm_object增加了新的特性，其必定有一定的损失。相比uvm_object，uvm_component主要有两个限制。一个是uvm_component无法使用clone函数，因为clone函数是开辟一块内存空间，将某个实例的内容复制到这块新的空间中；然而由于clone时无法指定parent函数，因此uvm_component无法使用clone。虽然uvm_component无法使用clone函数，但是可以使用copy函数。因为在调用copy之前，目标实例已经完成了实例化，其parent参数已经制定了。

uvm_component另一个限制是，位于同一个父节点下的不同的component不能用相同的名字实例化。这点很好理解，是为了避免混淆。

UVM的树型结构

从上一篇文章中我们可以看出，UVM的不同uvm_component类及其派生类构成了树型结构，方便得到清晰的层次结构。这种树型结构是通过类的new函数的parent参数实现的，如my_drv的new函数如下：

function new (string name, uvm_component parent);
    super.new(name,parent);
endfunction

而在my_agt中实例化my_drv时的代码如下：

my_driver drv;

function void my_agent::build_pahse(uvm_phase phase);
    drv = my_driver::type_id::create("drv",this);
endfunction

其中，诸如my_driver::type_id::create()这样子的函数可以暂且认定为UVM的特殊规定，我们只需关注其参数，前者“drv”代表了实例化节点的名字，而后者this是一个指向当前类的指针，赋给了parent，因此my_drv的父节点就是my_agt。

在上一篇文章中的例子来看，UVM树的树根在uvm_test_top，但其实其真正的树根是uvm_top，它是一个全局变量，是uvm_root的一个，也是唯一一个实例。uvm_top的parent是null，因此其才是UVM树的真正树根。并且，如果一个component在实例化时，其parent被设置为null，那么这个component的parent会被系统设置为唯一的uvm_root的实例uvm_top。通过这种机制，确保了整个验证平台中只有一棵树，所有节点都是uvm_top的子节点。（这一部分在第一篇文章中讲错了，已改正）。

在UVM中，可以使用get_parent，get_child，get_first_child/get_next_child等等函数获得关于UVM树层次结构的信息。

field automation机制

在第二章的代码中曾引入了field automation机制，个人理解是通过将指定的“散装”变量打包成一个类似数据包的结构，从而实现UVM内部的copy，print等函数，可以简化验证平台的搭建，提高效率。

使用uvm_field宏时以`uvm_object_utils_begin开头，以`uvm_object_utils_end结尾，以实现当前类的factor注册，在其中使用uvm_field系列宏注册不同类型的变量。根据变量类型不同而需要选择不同的uvm_field系列的宏，如以下几种：

`define uvm_field_int(ARG, FLAG)
`define uvm_field_real(ARG, FLAG)
`define uvm_field_string(ARG, FLAG)

分别对应int，real和string类型的变量。其中ARG参数为需要注册的变量名字，FLAG参数实际为一个17bit的数字，如果某个bit设置为1，则代表打开那个bit对应的功能，如copy，compare等等，若设置为UVM_ALL_ON，则其实是设置为17'b0000_0010_1010_101，代表打开copy，compare，print，record和pack功能。若对某个注册的字段不想执行pack/unpack功能，则可将它的FLAG设置为UVM_ALL_ON | UVM_NOPACK，则该参数变为17'b0000_0110_1010_101，这样UVM在执行pack操作时，首先检查第9位bit no_pack，发现其为1，则直接忽略第8位bit代表的UVM_PACK。uvm_field宏的标志位具体情况如下图所示：

除了以上普通类型的uvm_field宏，还有针对动态数组，静态变量，队列，联合数组的uvm_field宏。其中联合数组由于有两部分构成，一是索引，二是存储的数据，因此其对应的uvm_field宏一般为如下形式：

`define uvm_field_aa_int_string(ARG,FLAG)

前者int代表存储数据类型，后者string代表索引类型。

field automation功能提供了许多预定义函数，如copy, compare, pack_bytes/unpack_bytes, pack/unpack, print, clone等等。此外，field_automation机制还提供自动得到使用config_db::set设置的参数的功能，具体内容在涉及config_db时再阐述。

在使用uvm_field宏进行注册的时候还可以结合if/else等判定语句，例如如果is_a==1，则注册a~d字段，else注册e~h字段等等，这样可以实现更加灵活的控制。

*以上所有内容参考自《UVM实战》张强编著。