UVM（一）——UVM验证平台

声明：
未经作者允许，禁止转载
推荐一个IC、FPGA新手入门的好网站：快 点 击 进 入 学 习 吧

---

UVM验证平台组成

之前一直在忙比赛的事情，时隔一个月终于又能开始继续学习验证了！
这次刚看完UVM白皮书第二章的内容，大致了解了一下UVM的框架，做个简单的总结。

了解UVM后觉得其本质是一个框架，就像pytorch对于深度学习，以及其他高级语言在特定需求下的一种框架。UVM就是SV在IC验证中的一种框架。不用UVM也能完成验证功能，只是复用性和便捷性不如用UVM的情况。

• 对于UVM来说其强大的复用性决定它必定是面向对象的所以它的封装都很规范。
• 一个验证平台大致分为sequencer、driver、monitor、reference model、scoreboard。
• 又会将不同协议的driver和monitor封装成一个agent。再把各个验证组件封装成一个env。大致结构如下图所示。

• UVM是树形结构的，会在build_phase中构建整个树，而后安装树的结构运行程序。

driver组件

UVM的第一条原则就是：验证平台中所有的组件应该派生自UVM中的类。

driver就应该派生自uvm_driver，这个派生类的new函数有两个参数，第一个是字符串类型，表示派生类的name，第二个则是其父节点的名字。如

function new(string name="my_driver",uvm_component parent=null);

第二点便是UVM中都是由phase来管理平台运行的。(暂时还缺乏都phase的深入理解)

factory机制

factory是UVM中一个非常重要的机制，暂时明白的功能就是run_test();就可以直接创建一个类的实例并调用其函数。但是用factory机制前需要通过uvm_component_utils宏进行注册，例如：

`uvm_component_utils(my_driver);

并且可以直接运行my_driver的main_phase，但是仅仅这样不会运行其main_phase中的事务。

objection机制

这时候就需要objection机制登场啦。
在UVM中每个phase会检查是否有objection被raise，如果有等这个objection被drop后才停止。例如将下列两行代码加在main_phase的开头和结尾，事务就能正常运行。

phase.raise_objection(this);
phase.drop_objection(this);

这里的this就像C++的this指针一样，指的是当前类。（raise要加在所有耗时语句之前）

virtual interface

在SV中会使用interface来简化接口的描述，但是UVM中interface是不能在类中例化的，所以就引入了virtual interface的概念。在类中如下描述：

virtual my_if vif；

声明过这个virtual interface后就可以在main_phase中使用这个接口了。
这样就剩下最后一个问题了，怎么将顶层的input_if和driver的if连接起来。最简单的就是赋值了，但是由于UVM的run_test的实例化其实在顶层之上建立了一个新的层次：uvm_test_top，所以无法使用top.driver…。

• 这时候就需要config_db机制了

config_db机制

• 在我的理解中config_db机制就是为了给不同层次的类进行赋值的，用set表示发送，get表示接受。

uvm_config_db# (virtual my_if)::set(null,"uvm_test_top","vif",input_if);
uvm_config_db# (virtual my_if)::get(this,"","vif",vif);

但是不同的是get要放在build_phase中，build_phase通常是在整个UVM结构树形成前进行操作的。（在new函数后，main_phase之前）

• set和get函数的第三个参数必须一致，表示目标virtual interface，第二个参数表示路径索引。
• set的第四个参数表示要传递哪个interface，get第四个参数表示要把接受到的interface给哪个成员变量。
  #后面括号的内容就是要传递数据的类型。（也可以为int，logic等等）

transaction

在uvm中所有的数据都抽象成transaction，而transaction都由uvm_sequence_item派生出来。

详细内容等后续看完继续补充

env

env就是一个容器，在其中来进行driver、monitor、reference model和scoreboard的实例化。env就成为了根节点。

monitor

monitor组件的功能是检测DUT输入输出的端口数据并转换成transaction并交给后续比对。monitor的类应该全部派生自uvm_monitor类，其内也需要virtual interface

• uvm_monitor也是一个component所以也需要注册

`uvm_component_utils(my_monitor);

agent

有了driver和monitor后可以将他们封装成一个agent，在UVM中不同的agent代表不同的协议。而agent类都要派生自uvm_agent类，也需要注册。

• 如果端口不需要driver只需要monitor那么agent的build_phase的is_active的值可以赋为uvm_passive，那么driver就不会被例化出来。加入agent后UVM树的层次就再次改变了，driver和monitor的根节点就是agent了不是uvm_top_test。

reference model

reference model功能就是以软件的形式完成DUT的功能验证，并将结果给后续的scoreboard比对。

• 除了其中的功能实现外，其另一个重点是，transaction的传递方式。
• 在uvm的transaction级别的通信中可以使用uvm_analysis_port。

可以在monitor中参数化定义一个uvm_analysis_port，然后在build_phase中实例化，在main_phase中用内建函数write将transaction写入。
之后可以在env中定义fifo，两端分别连接monitor的analysis_port和model的blocking_get_port。

此处为什么要用fifo呢，因为analysis_port是非阻塞的，如果blocking_get_port正在忙无法接受monitor的数据，那么没有fifo就会使数据丢失，所以此处需要一个fifo。

scoreboard

开启两个进程，一个处理model出来的数据，放在队列里，一个存DUT出来的数据，用内建函数compare比较两个数据。通常model是高级语言处理，数据产生的比DUT快。
接口机制和上述的monitor和model类似。

field_automation

对变量用uvm_objection_utils进行宏注册，可以让变量使用uvm内置的许多函数，如compare（），copy（）等。需要在变量前后加上如下语句

`uvm_objection_utils_begin(my_transaction)
`uvm_objection_utils_end

sequence

最后的也是最重要的sequence机制，sequence机制有两部分组成，一是sequence，二是sequencer。
sequence不属于验证平台中，但是在它的帮助下，sequencer才能正常工作。

• 从本质上来说，sequencer是一个uvm_component；而sequence是一个uvm_object。
• 每一个sequence都应该派生自uvm_sequence，用·uvm_do这个这个宏产生transaction，这个宏的功能是
• 1.创建一个实例。2.将其随机化。3.最终给sequencer。

但是一个sequence在向sequencer发送transaction之前，要先做两件事，一是发送一个请求，二是检测driver是否发出申请了。通过这种握手机制后，driver才可以通过get_next_item向sequencer申请transaction。

• 申请下一transaction可以用get_next_item还有try_next_item前者是阻塞的，后者是非阻塞的。

---

最后给大家安利一个好网站：
  Verilog的学习还是要多以练习为主，想要练习Verilog的同学，推荐可以去nowcoder看看，他们现在的题库内容很丰富，属于国内做的很好的了，而且是课程+刷题+面经+求职+讨论区分享，一站式求职学习网站，最最最重要的里面的资源全部免费