在上一节中，**《IC验证"UVM验证平台加入factory机制"（六）》**虽然输出了“main_phase is called”，但是“data is drived”并没有输出。而main_phase是一个完整的任务，没有理由 只执行第一句，而后面的代码不执行。看上去似乎main_phase在执行的过程中被外力“杀死”了，事实上也确实如此。
UVM中通过objection机制来控制验证平台的关闭。细心的读者可能发现，在上节的例子中，并没有如**《IC验证"一个简单的UVM验证平台"是如何搭建的（五）》**所示显式地调用 finish语句来结束仿真。但是在运行上节例子时，仿真平台确实关闭了。在每个phase中，UVM会检查是否有objection被提起 （raise_objection），如果有，那么等待这个objection被撤销（drop_objection）后停止仿真；如果没有，则马上结束当前phase。
**加入了objection机制的driver如下所示：**
<p>
</p><p>```</p><p> 文件：src/ch2/section2.2/2.2.3/my_driver.sv </p><p>13 task my_driver::main_phase(uvm_phase phase); </p><p>14 phase.raise_objection(this); </p><p>15 `uvm_info("my_driver", "main_phase is called", UVM_LOW); </p><p>16 top_tb.rxd <= 8'b0; </p><p>17 top_tb.rx_dv <= 1'b0; </p><p>18 while(!top_tb.rst_n) </p><p>19 @(posedge top_tb.clk); </p><p>20 for(int i = 0; i < 256; i++)begin </p><p>21 @(posedge top_tb.clk); </p><p>22 top_tb.rxd <= $urandom_range(0, 255); </p><p>23 top_tb.rx_dv <= 1'b1; </p><p>24 `uvm_info("my_driver", "data is drived", UVM_LOW); </p><p>5225 end </p><p>26 @(posedge top_tb.clk); </p><p>27 top_tb.rx_dv <= 1'b0; </p><p>28 phase.drop_objection(this); </p><p>29 endtask</p><p>```</p>
在开始学习时，读者可以简单地将drop_objection语句当成是finish函数的替代者，只是在drop_objection语句之前必须先调用 raise_objection语句，raise_objection和drop_objection总是成对出现。加入objection机制后再运行验证平台，可以发现“data is drived”按照预期输出了256次。
raise_objection语句必须在main_phase中第一个消耗仿真时间 [1]的语句之前。如$display语句是不消耗仿真时间的，这些语句可 以放在raise_objection之前，但是类似@（posedge top.clk）等语句是要消耗仿真时间的。按照如下的方式使用raise_objection是无法 起到作用的：
```
<p> task my_driver::main_phase(uvm_phase phase); </p><p>@(posedge top_tb.clk); </p><p>phase.raise_objection(this); </p><p>`uvm_info("my_driver", "main_phase is called", UVM_LOW); </p><p>top_tb.rxd <= 8'b0; </p><p>top_tb.rx_dv <= 1'b0; </p><p>while(!top_tb.rst_n) </p><p>@(posedge top_tb.clk); </p><p>for(int i = 0; i < 256; i++)begin </p><p>@(posedge top_tb.clk); </p><p>53top_tb.rxd <= $urandom_range(0, 255); </p><p>top_tb.rx_dv <= 1'b1; </p><p>`uvm_info("my_driver", "data is drived", UVM_LOW); </p><p>end </p><p>@(posedge top_tb.clk); </p><p>top_tb.rx_dv <= 1'b0; </p><p>phase.drop_objection(this); </p><p>endtask </p><p>```</p>
## 加入virtual interface
在前几节的例子中，driver中等待时钟事件（@posedge top.clk）、给DUT中输入端口赋值（top.rx_dv<=1‘b1）都是使用绝对路 径，绝对路径的使用大大减弱了验证平台的可移植性。一个最简单的例子就是假如clk信号的层次从top.clk变成了top.clk_inst.clk， 那么就需要对driver中的相关代码做大量修改。因此，从根本上来说，应该尽量杜绝在验证平台中使用绝对路径。
**避免绝对路径的一个方法是使用宏：**
<p>```</p><p>`define TOP top_tb </p><p>task my_driver::main_phase(uvm_phase phase); </p><p>phase.raise_objection(this); </p><p>`uvm_info("my_driver", "main_phase is called", UVM_LOW); </p><p>`TOP.rxd <= 8'b0; </p><p>`TOP.rx_dv <= 1'b0; </p><p>while(!`TOP.rst_n) </p><p>@(posedge `TOP.clk); </p><p>for(int i = 0; i < 256; i++)begin </p><p>@(posedge `TOP.clk); </p><p>`TOP.rxd <= $urandom_range(0, 255); </p><p>`TOP.rx_dv <= 1'b1; </p><p>`uvm_info("my_driver", "data is drived", UVM_LOW); </p><p>end </p><p>@(posedge `TOP.clk); </p><p>`TOP.rx_dv <= 1'b0; </p><p>phase.drop_objection(this); </p><p>endtask </p><p>```</p><p></p>
这样，当路径修改时，只需要修改宏的定义即可。但是假如clk的路径变为了top_tb.clk_inst.clk，而rst_n的路径变为了 top_tb.rst_inst.rst_n，那么单纯地修改宏定义是无法起到作用的。
避免绝对路径的另外一种方式是使用interface。在SystemVerilog中使用interface来连接验证平台与DUT的端口。interface的定义 比较简单：
<p>
</p><p>```</p><p>文件：src/ch2/section2.2/2.2.4/my_if.sv </p><p>4 interface my_if(input clk, input rst_n); </p><p>5</p><p>6 logic [7:0] data; </p><p>7 logic valid; </p><p>8 endinterface </p><p>```</p>
定义了interface后，在top_tb中实例化DUT时，就可以直接使用：
<p>
</p><p>```</p><p>文件：src/ch2/section2.2/2.2.4/top_tb.sv </p><p>17 my_if input_if(clk, rst_n); </p><p>18 my_if output_if(clk, rst_n); </p><p>5619</p><p>20 dut my_dut(.clk(clk), </p><p>21 .rst_n(rst_n), </p><p>22 .rxd(input_if.data), </p><p>23 .rx_dv(input_if.valid), </p><p>24 .txd(output_if.data), </p><p>25 .tx_en(output_if.valid)); </p><p>```</p>
那么如何在driver中使用interface呢？一种想法是在driver中声明如下语句，然后再通过赋值的形式将top_tb中的input_if传递给 它：
<p>```</p><p>class my_driver extends uvm_driver; </p><p>my_if drv_if; </p><p>…</p><p>endclass </p><p>```</p>
读者可以试一下，这样的使用方式是会报语法错误的，因为my_driver是一个类，在类中不能使用上述方式声明一个 interface，只有在类似top_tb这样的模块（module）中才可以。在类中使用的是virtual interface：
<p>```</p><p>文件：src/ch2/section2.2/2.2.4/my_driver.sv </p><p>3 class my_driver extends uvm_driver; </p><p>574</p><p>5 virtual my_if vif; </p><p>```</p>
在声明了vif后，就可以在main_phase中使用如下方式驱动其中的信号：
<p>
</p><p>```</p><p>文件：src/ch2/section2.2/2.2.4/my_driver.sv </p><p>23 task my_driver::main_phase(uvm_phase phase); </p><p>24 phase.raise_objection(this); </p><p>25 `uvm_info("my_driver", "main_phase is called", UVM_LOW); </p><p>26 vif.data <= 8'b0; </p><p>27 vif.valid <= 1'b0; </p><p>28 while(!vif.rst_n) </p><p>29 @(posedge vif.clk); </p><p>30 for(int i = 0; i < 256; i++)begin </p><p>31 @(posedge vif.clk); </p><p>32 vif.data <= $urandom_range(0, 255); </p><p>33 vif.valid <= 1'b1; </p><p>34 `uvm_info("my_driver", "data is drived", UVM_LOW); </p><p>35 end </p><p>36 @(posedge vif.clk); </p><p>37 vif.valid <= 1'b0; </p><p>38 phase.drop_objection(this); </p><p>39 endtask </p><p>```</p>
可以清楚看到，代码中的绝对路径已经消除了，大大提高了代码的可移植性和可重用性。
58剩下的最后一个问题就是，如何把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操作：
<p>```</p><p>文件：src/ch2/section2.2/2.2.4/top_tb.sv </p><p>44 initial begin </p><p>45 uvm_config_db#(virtual my_if)::set(null, "uvm_test_top", "vif", input_if); </p><p>46 end </p><p>```</p>
在my_driver中，执行get操作：
<p>```</p><p>文件：src/ch2/section2.2/2.2.4/my_driver.sv </p><p>13 virtual function void build_phase(uvm_phase phase); </p><p>14 super.build_phase(phase); </p><p>15 `uvm_info("my_driver", "build_phase is called", UVM_LOW); </p><p>5916 if(!uvm_config_db#(virtual my_if)::get(this, "", "vif", vif)) </p><p>17 `uvm_fatal("my_driver", "virtual interface must be set for vif!!!") </p><p>18 endfunction </p><p>```</p>
这里引入了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的实例。读者可以通过把代码
`$display("the full name of current component is: %s", get_full_name());中的语句插入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类型的数据，那么可以使用如下方式：
<p>
</p><p>```</p><p>initial begin </p><p>uvm_config_db#(int)::set(null, "uvm_test_top", "var", 100); </p><p>end </p><p>```</p>
而在my_driver中应该使用如下方式：
<p>
</p><p>```</p><p>class my_driver extends uvm_driver; </p><p>int var; </p><p>virtual function void build_phase(uvm_phase phase); </p><p>super.build_phase(phase); </p><p>`uvm_info("my_driver", "build_phase is called", UVM_LOW); </p><p>61if(!uvm_config_db#(virtual my_if)::get(this, "", "vif", vif)) </p><p>`uvm_fatal("my_driver", "virtual interface must be set for vif!!!") </p><p>if(!uvm_config_db#(int)::get(this, "", "var", var)) </p><p>`uvm_fatal("my_driver", "var must be set!!!") </p><p>endfunction </p><p>```</p>
从这里可以看出，可以向my_driver中“寄”许多信。上文列举的两个例子是top_tb向my_driver传递了两个不同类型的数据，其 实也可以传递相同类型的不同数据。假如my_driver中需要两个my_if，那么可以在top_tb中这么做：
<p>
</p><p>```</p><p>initial begin </p><p>uvm_config_db#(virtual my_if)::set(null, "uvm_test_top", "vif", input_if); </p><p>uvm_config_db#(virtual my_if)::set(null, "uvm_test_top", "vif2", output_if); </p><p>end </p><p>```</p><p></p>
在my_driver中这么做：
<p>
</p><p>```</p><p>virtual my_if vif; </p><p>virtual my_if vif2; </p><p>virtual function void build_phase(uvm_phase phase); </p><p>super.build_phase(phase); </p><p>`uvm_info("my_driver", "build_phase is called", UVM_LOW); </p><p>if(!uvm_config_db#(virtual my_if)::get(this, "", "vif", vif)) </p><p>62`uvm_fatal("my_driver", "virtual interface must be set for vif!!!") </p><p>if(!uvm_config_db#(virtual my_if)::get(this, "", "vif2", vif2)) </p><p>`uvm_fatal("my_driver", "virtual interface must be set for vif2!!!") </p><p>endfunction </p><p>```</p>
| 
楼主
标题置顶
标题高亮
