本节书摘来自华章社区《uvm实战》一书中的第2章，第2.2节只有driver的验证平台，作者 张 强，更多章节内容可以访问云栖社区“华章社区”公众号查看
2.2 只有driver的验证平台
driver是验证平台最基本的组件，是整个验证平台数据流的源泉。本节以一个简单的dut为例，说明一个只有driver的uvm验证平台是如何搭建的。
2.2.1 最简单的验证平台
在本章中，假设有如下的dut定义：
代码清单 2-1
这个dut的功能非常简单，通过rxd接收数据，再通过txd发送出去。其中rx_dv是接收的数据有效指示，tx_en是发送的数据有效指示。本章中所有例子都是基于这个dut。
uvm中的driver应该如何搭建？uvm是一个库，在这个库中，几乎所有的东西都是使用类（class）来实现的。driver、monitor、reference model、scoreboard等组成部分都是类。类是像systemverilog这些面向对象编程语言中最伟大的发明之一，是面向对象的精髓所在。类有函数（function），另外还可以有任务（task），通过这些函数和任务可以完成driver的输出激励功能，完成monitor的监测功能，完成参考模型的计算功能，完成scoreboard的比较功能。类中可以有成员变量，这些成员变量可以控制类的行为，如控制driver的行为等。当要实现一个功能时，首先应该想到的是从uvm的某个类派生出一个新的类，在这个新的类中实现所期望的功能。所以，使用uvm的第一条原则是：验证平台中所有的组件应该派生自uvm中的类。
uvm验证平台中的driver应该派生自uvm_driver，一个简单的driver如下例所示：
代码清单 2-2
这个driver的功能非常简单，只是向rxd上发送256个随机数据，并将rx_dv信号置为高电平。当数据发送完毕后，将rx_dv信号置为低电平。在这个driver中，有两点应该引起注意：
所有派生自uvm_driver的类的new函数有两个参数，一个是string类型的name，一个是uvm_component类型的parent。关于name参数，比较好理解，就是名字而已；至于parent则比较难以理解，读者可暂且放在一边，下文会有介绍。事实上，这两个参数是由uvm_component要求的，每一个派生自uvm_component或其派生类的类在其new函数中要指明两个参数：name和parent，这是uvm_component类的一大特征。而uvm_driver是一个派生自uvm_component的类，所以也会有这两个参数。
driver所做的事情几乎都在main_phase中完成。uvm由phase来管理验证平台的运行，这些phase统一以xxxx_phase来命名，且都有一个类型为uvm_phase、名字为phase的参数。main_phase是uvm_driver中预先定义好的一个任务。因此几乎可以简单地认为，实现一个driver等于实现其main_phase。
上述代码中还出现了uvm_info宏。这个宏的功能与verilog中display语句的功能类似，但是它比display语句更加强大。它有三个参数，第一个参数是字符串，用于把打印的信息归类；第二个参数也是字符串，是具体需要打印的信息；第三个参数则是冗余级别。在验证平台中，某些信息是非常关键的，这样的信息可以设置为uvm_low，而有些信息可有可无，就可以设置为uvm_high，介于两者之间的就是uvm_medium。uvm默认只显示uvm_medium或者uvm_low的信息，本书3.4.1节会讲述如何显示uvm_high的信息。本节中uvm_info宏打印的结果如下：
uvm_info my_driver.sv(20) @ 48500000: drv [my_driver] data is drived
在uvm_info宏打印的结果中有如下几项：
uvm_info关键字：表明这是一个uvm_info宏打印的结果。除了uvm_info宏外，还有uvm_error宏、uvm_warning宏，后文中将会介绍。
my_driver.sv(20)：指明此条打印信息的来源，其中括号里的数字表示原始的uvm_info打印语句在my_driver.sv中的行号。
48500000：表明此条信息的打印时间。
drv：这是driver在uvm树中的路径索引。uvm采用树形结构，对于树中任何一个结点，都有一个与其相应的字符串类型的路径索引。路径索引可以通过get_full_name函数来获取，把下列代码加入任何uvm树的结点中就可以得知当前结点的路径索引：
代码清单 2-3
类的定义类似于在纸上写下一纸条文，然后把这些条文通知给systemverilog的仿真器：验证平台可能会用到这样的一个类，请做好准备工作。而类的实例化在于通过new()来通知systemverilog的仿真器：请创建一个a的实例。仿真器接到new的指令后，就会在内存中划分一块空间，在划分前，会首先检查是否已经预先定义过这个类，在已经定义过的情况下，按照定义中所指定的“条文”分配空间，并且把这块空间的指针返回给a_inst，之后就可以通过a_inst来查看类中的各个成员变量，调用成员函数/任务等。对大部分的类来说，如果只定义而不实例化，是没有任何意义的；而如果不定义就直接实例化，仿真器将会报错。
对my_driver实例化并且最终搭建的验证平台如下：
代码清单 2-6
第2行把uvm_macros.svh文件通过include语句包含进来。这是uvm中的一个文件，里面包含了众多的宏定义，只需要包含一次。
第4行通过import语句将整个uvm_pkg导入验证平台中。只有导入了这个库，编译器在编译my_driver.sv文件时才会认识其中的uvm_driver等类名。
第24和25行定义一个my_driver的实例并将其实例化。注意这里调用new函数时，其传入的名字参数为drv，前文介绍uvm_info宏的打印信息时出现的代表路径索引的drv就是在这里传入的参数drv。另外传入的parent参数为null，在真正的验证平台中，这个参数一般不是null，这里暂且使用null。
第26行显式地调用my_driver的main_phase。在main_phase的声明中，有一个uvm_phase类型的参数phase，在真正的验证平台中，这个参数是不需要用户理会的。本节的验证平台还算不上一个完整的uvm验证平台，所以暂且传入null。
第27行调用finish函数结束整个仿真，这是一个verilog中提供的函数。
运行这个例子，可以看到“data is drived”被输出了256次。
2.2.2 加入factory机制
上一节给出了一个只有driver、使用uvm搭建的验证平台。严格来说这根本就不算是uvm验证平台，因为uvm的特性几乎一点都没有用到。像上节中my_driver的实例化及drv.main_phase的显式调用，即使不使用uvm，只使用简单的systemverilog也可以完成。本节将会为读者展示在初学者看来感觉最神奇的一点：自动创建一个类的实例并调用其中的函数（function）和任务（task）。
要使用这个功能，需要引入uvm的factory机制：
代码清单 2-7
factory机制的实现被集成在了一个宏中：uvm_component_utils。这个宏所做的事情非常多，其中之一就是将my_driver登记在uvm内部的一张表中，这张表是factory功能实现的基础。只要在定义一个新的类时使用这个宏，就相当于把这个类注册到了这张表中。那么factory机制到底是什么？这个宏还做了哪些事情呢？这些属于uvm中的高级问题，本书会在后文一一展开。
在给driver中加入factory机制后，还需要对top_tb做一些改动：
代码清单 2-8
一个run_test语句会创建一个my_driver的实例，并且会自动调用my_driver的main_phase。仔细观察run_test语句，会发现传递给它的是一个字符串。uvm根据这个字符串创建了其所代表类的一个实例。如果没有uvm，读者自己能够实现同样的功能吗？
根据类名创建一个类的实例，这是uvm_component_utils宏所带来的效果，同时也是factory机制给读者的最初印象。只有在类定义时声明了这个宏，才能使用这个功能。所以从某种程度上来说，这个宏起到了注册的作用。只有经过注册的类，才能使用这个功能，否则根本不能使用。请记住一点：所有派生自uvm_component及其派生类的类都应该使用uvm_component_utils宏注册。
除了根据一个字符串创建类的实例外，上述代码中另外一个神奇的地方是main_phase被自动调用了。在uvm验证平台中，只要一个类使用uvm_component_utils注册且此类被实例化了，那么这个类的main_phase就会自动被调用。这也就是为什么上一节中会强调实现一个driver等于实现其main_phase。所以，在driver中，最重要的就是实现main_phase。
上面的例子中，只输出到“main_phase is called”。令人沮丧的是，根本没有输出“data is drived”，而按照预期，它应该输出256次。关于这个问题，牵涉uvm的objection机制。
2.2.3 加入objection机制
在上一节中，虽然输出了“main_phase is called”，但是“data is drived”并没有输出。而main_phase是一个完整的任务，没有理由只执行第一句，而后面的代码不执行。看上去似乎main_phase在执行的过程中被外力“杀死”了，事实上也确实如此。
uvm中通过objection机制来控制验证平台的关闭。细心的读者可能发现，在上节的例子中，并没有如2.2.1节所示显式地调用finish语句来结束仿真。但是在运行上节例子时，仿真平台确实关闭了。在每个phase中，uvm会检查是否有objection被提起（raise_objection），如果有，那么等待这个objection被撤销（drop_objection）后停止仿真；如果没有，则马上结束当前phase。
加入了objection机制的driver如下所示：
代码清单 2-9
2.2.4 加入virtual interface
在前几节的例子中，driver中等待时钟事件（@posedge top.clk）、给dut中输入端口赋值（top.rx_dv <= 1' b1）都是使用绝对路径，绝对路径的使用大大减弱了验证平台的可移植性。一个最简单的例子就是假如clk信号的层次从top.clk变成了top.clk_inst.clk，那么就需要对driver中的相关代码做大量修改。因此，从根本上来说，应该尽量杜绝在验证平台中使用绝对路径。
避免绝对路径的一个方法是使用宏：
代码清单 2-11
可以清楚看到，代码中的绝对路径已经消除了，大大提高了代码的可移植性和可重用性。
剩下的最后一个问题就是，如何把top_tb中的input_if和my_driver中的vif对应起来呢？最简单的方法莫过于直接赋值。此时一个新的问题又摆在了面前：在top_tb中，通过run_test语句建立了一个my_driver的实例，但是应该如何引用这个实例呢？不可能像引用my_dut那样直接引用my_driver中的变量：top_tb.my_dut.xxx是可以的，但是top_tb.my_driver.xxx是不可以的。这个问题的终极原因在于uvm通过run_test语句实例化了一个脱离了top_tb层次结构的实例，建立了一个新的层次结构。
对于这种脱离了top_tb层次结构，同时又期望在top_tb中对其进行某些操作的实例，uvm引进了config_db机制。在config_db机制中，分为set和get两步操作。所谓set操作，读者可以简单地理解成是“寄信”，而get则相当于是“收信”。在top_tb中执行set操作：
代码清单 2-17
这里引入了build_phase。与main_phase一样，build_phase也是uvm中内建的一个phase。当uvm启动后，会自动执行build_phase。build_phase在new函数之后main_phase之前执行。在build_phase中主要通过config_db的set和get操作来传递一些数据，以及实例化成员变量等。需要注意的是，这里需要加入super.build_phase语句，因为在其父类的build_phase中执行了一些必要的操作，这里必须显式地调用并执行它。build_phase与main_phase不同的一点在于，build_phase是一个函数phase，而main_phase是一个任务phase，build_phase是不消耗仿真时间的。build_phase总是在仿真时间（$time函数打印出的时间）为0时执行。
在build_phase中出现了uvm_fatal宏，uvm_fatal宏是一个类似于uvm_info的宏，但是它只有两个参数，这两个参数与uvm_info宏的前两个参数的意义完全一样。与uvm_info宏不同的是，当它打印第二个参数所示的信息后，会直接调用verilog的finish函数来结束仿真。uvm_fatal的出现表示验证平台出现了重大问题而无法继续下去，必须停止仿真并做相应的检查。所以对于uvm_fatal来说，uvm_info中出现的第三个参数的冗余度级别是完全没有意义的，只要是uvm_fatal打印的信息，就一定是非常关键的，所以无需设置第三个参数。
config_db的set和get函数都有四个参数，这两个函数的第三个参数必须完全一致。set函数的第四个参数表示要将哪个interface通过config_db传递给my_driver，get函数的第四个参数表示把得到的interface传递给哪个my_driver的成员变量。set函数的第二个参数表示的是路径索引，即在2.2.1节介绍uvm_info宏时提及的路径索引。在top_tb中通过run_test创建了一个my_driver的实例，那么这个实例的名字是什么呢？答案是uvm_test_top：uvm通过run_test语句创建一个名字为uvm_test_top的实例。读者可以通过把代码清单2-3中的语句插入my_driver（build_phase或者main_phase）中来验证。
无论传递给run_test的参数是什么，创建的实例的名字都为uvm_test_top。由于set操作的目标是my_driver，所以set函数的第二个参数就是uvm_test_top。set函数的第一个参数null以及get函数的第一和第二个参数可以暂时放在一边，后文会详细说明。
set函数与get函数让人疑惑的另外一点是其古怪的写法。使用双冒号是因为这两个函数都是静态函数，而uvm_config_db#(virtual my_if)则是一个参数化的类，其参数就是要寄信的类型，这里是virtual my_if。假如要向my_driver的var变量传递一个int类型的数据，那么可以使用如下方式：
代码清单 2-19