·driver所做的事情几乎都在main_phase中完成。UVM由phase来管理验证平台的运行，这些phase统一以xxxx_phase来命名，且都有一个类型为uvm_phase、名字为phase的参数。main_phase是uvm_driver中预先定义好的一个任务。因此几乎可以简单地认为，实现一个driver等于实现其main_phase。

uvm_info宏：

与Verilog中display语句的功能类似，更加强大。

有三个参数：

第一个参数是字符串，用于把打印的信息归类；

第二个参数也是字符串，是具体需要打印的信息；

第三个参数则是冗余级别。

某些信息是非常关键——设置为UVM_LOW（低过滤），

而有些信息可有可无——设置为UVM_HIGH（高过滤），

介于两者之间的就是——UVM_MEDIUM。

`uvm_info("my_driver", "data is drived", UVM_LOW)

工厂机制：

run_test：

传递给run_test一个字符串（如my_drive），创建字符串所代表类的一个实例，并且会自动调用my_driver的main_phase。

根据类名创建一个类的实例，这是uvm_component_utils宏所带来的效果：所有派生自uvm_component及其派生类的类都应该使用uvm_component_utils宏注册。。在UVM验证平台中，只要一个类使用uvm_component_utils注册且此类被实例化了，那么这个类的main_phase就会自动被调用。

objection机制：

raise_objection：挂起才运行

UVM中通过objection机制来控制验证平台的关闭。在每个phase中，UVM会检查是否有objection被提起（raise_objection），如果有，那么等待这个objection被撤销（drop_objection）后停止仿真；如果没有，则马上结束当前phase。

drop_objection：落下就是结束

是finish函数的替代者，只是在drop_objection语句之前必须先调用raise_objection语句，raise_objection和drop_objection总是成对出现。

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

virtual interface：代码中的绝对路径已经消除

避免绝对路径的方法：宏或者interface

避免绝对路径的一个方法是使用宏。当路径修改时，只需要修改宏的定义即可。

避免绝对路径的另外一种方式是使用interface。

interface来连接验证平台与DUT的端口

模块中可以声明interface

类中只能声明virtual interface=vif

config_db机制：

在config_db机制中，分为set和get两步操作。

所谓set操作，理解成是“寄信”，

而get则相当于是“收信”。在top_tb中执行set操作

build_phase

当UVM启动后，会自动执行build_phase。build_phase在new函数之后main_phase之前执行。在build_phase中主要通过config_db的set和get操作来传递一些数据，以及实例化成员变量等。

build_phase执行顺序

在UVM的树形结构中，build_phase的执行遵照从树根到树叶的顺序，即先执行my_env的build_phase，再执行my_driver的build_phase。当把整棵树的build_phase都执行完毕后，再执行后面的phase。

uvm_fatal宏

是一个类似于uvm_info的宏，但是它只有两个参数，这两个参数与uvm_info宏

的前两个参数的意义完全一样。uvm_fatal的出现表示验证平台出现了重大问题而无法继续下去，必须停止仿真并做相应的检查。

平台各组件：

transaction：

一笔transaction就是一个包。每个包的大小至少是64byte。这个包中要包括源地址、目的地址、包的类型、整个包的CRC校验数据。

monitor：

验证平台要收集DUT的输出并把它们传递给scoreboard。monitor的行为与driver相对（driver向DUT的pin上发送数据，而monitor则是从DUT的pin上接收数据），用于收集DUT的端口数据，并将其转换成transaction交给后续的组件如reference model、scoreboard等处理。

uvm_monitor在整个仿真中是一直存在的，所以它是一个component。由于monitor需要时刻收集数据，永不停歇，所以在main_phase中使用while（1）循环来实现这一目的

uvm_env:

派生自uvm_component

将验证平台上用到的固定不变的component都封装在一起。

reference model：

作用就是模仿DUT，完成与DUT相同的功能。DUT是用Verilog写成的时序电路，而reference model则可以直接使用SystemVerilog高级语言的特性，同时还可以通过DPI等接口调用其他语言来完成与DUT相同的功能

my_model并不复杂，这其中令人感兴趣的是my_transaction的传递方式。my_model是从i_agt中得到my_transaction，并把my_transaction传递给my_scoreboard。

在UVM中，通常使用TLM（Transaction Level Modeling）实现component之间transaction级别的通信在UVM的transaction级别的通信中，数据的发送有多种方式，其中一种是使用uvm_analysis_port。

uvm_agent：

显。它只是把driver和monitor封装在一起，根据参数值来决定是只实例化monitor还是要同时实例化driver和monitor。agent的使用主要是从可重用性的角度来考虑的。与uvm_component相比，uvm_agent的最大改动在于引入了一个变量is_active：

scoreboard：

my_scoreboard要比较的数据一是来源于reference model，通过exp_port获取

二是来源于o_agt的monitor。后者通过 act_port获取。

在main_phase中通过fork建立起了两个进程：

一个进程处理exp_port的数据，当收到数据后，把数据放入 expect_queue中；

另一进程处理act_port的数据，这是DUT的输出数据，当收集到这些数据后，从expect_queue中弹出之前从 exp_port收到的数据，并调用my_transaction的my_compare函数。

加入field_automation机制

1、直接调用copy、compare、print

2、调用pack_bytes将tr中所有的字段变成byte流放入data_q

使用unpack_bytes函数将data_q中的byte流转换成tr中的各个字段

base_test

真正的测试用例都是基于base_test派生的一个类。

report_phase

也是UVM内建的一个phase，它在main_phase结束之后执行。在report_phase中根据UVM_ERROR的数量来打印不同的信息。一些日志分析工具可以根据打印的信息来判断DUT是否通过了某个测试用例的检查。

标签：transaction,二章,driver,part1,UVM,phase,DUT,uvm
来源： https://blog.csdn.net/weixin_44857476/article/details/115372292

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

《UVM实战》笔记part1（第一、二章+常见缩写）

一、代码常用缩写：

二、简单的UVM平台

验证平台四大部件：

driver：

scoreboard记分板：

monitor：

reference model参考模型：

·所有派生自uvm_driver的类的new函数有两个参数：

main_phase：

uvm_info宏：

工厂机制：

run_test：

objection机制：

config_db机制：

build_phase

uvm_fatal宏

平台各组件：

transaction：

monitor：

uvm_env:

reference model：

uvm_agent：

scoreboard：

加入field_automation机制

base_test

report_phase