UVM入门实验——lab3

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

提示：这里可以添加本文要记录的大概内容：

实验3在实验2的基础上，主要是一些组件通信的改造：

• TLM单向通行端口和多向通信端口的使用
• TLM的通信管道
• UVM的回调类型uvm_callback
• UVM的一些仿真控制函数

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、TLM单向通信和多向通信

在SV实验中monitor和checker，checker与reference mode之间的通信都是通过mailbox以及在上层的句柄传递实现的。在UVM中使用TLM端口进行通信，对其进行逐步替换。l

【get()数据流向是不是反了？】
按照上面的图，对组件添加TLM通信端口完成实验：

1.1 monitor中port端口替换

• 将monitor中用来与checker通信的mailbox‘句柄替换成uvm_blocking_put_port类型

reg_monitor:
有三处需要替换的

一是将mailbox mon_mb的声明替换成端口的声明，二是mailmox的例化换成端口的例化，三是传递数据需要通过端口调用put()方法

chnl_monitor:


fmt_montor:

1.2 checker中imp端口声明

• 在checker中声明与monitor通信的import端口，以及与reference model通信的import端口。注意：checker与多个monitor以及refmod通信是典型的多向通信，需要在checker之前使用多端口通信的宏声明方法；在使用宏声明端口类型之后，再在checker中声明其句柄，并完成例化

宏声明

端口声明句柄：
需要注意的是这里的mailbox并没有删掉，因为在imp端口实现数据传输方法时需要一个存放数据的地方，恰好mailbox可以当成一个buffer。

实例化：

1.3 实现imp端口对应方法

在checker中声明的imp端口需要实现其对应的方法：

1.4 在refmod中的port端口声明

在refmod中声明用来与checker中imp端口连接的port端口，并完成例化。在这之后将原来的mailbox句柄调用方法的方式改为用TLM端口呼叫方法的方式。

port端口声明：


实例化：

或者可以使用数组
数组大小是3，这里写错了

方法调用：

1.5 在env中完成monitor的TLM port端口与checker的TLM imp端口连接

端口连接需要在connect phase中完成

1.5 在checker中完成refmod的TLM port端口与checker的TLM imp端口连接

---

完成以上操作以后，编译成功，说明TLM端口替换成功。

二、TLM通信管道

TLM通信优点：

• 通信函数可以定制化，例如put()/get()/peek()的内容和参数，这比mailbox更灵活
• 将组件实现了完全的隔离，TLM端口按照层次的连接，使得组件之间保持独立
  但是TLM端口还需要自己定义imp端的数据传输方法，接下来使用不实现这些方法也能使用TLM端口的办法。

2.1 完成refmod中out_box的替换

uvm_tlm_fifo类继承于uvm_component类，且预先内置多个端口，实现多个方法。它的内部内置了一个mailbox #(T) 该mailbox没有尺寸限制，用来储存数据类型T，而内置的多个端口的对应方法均是利用该mailbox实现了数据读写。可以把它看做一个具有TLM端口、方法的mailbox。这样我们需要做的就是将refmod中的普通的mailbox out_mbs替换成TLM特殊mailbox——uvm_tlm_fifo

还有相应的out_mbs变量替换没有展示

2.2 完成checker中mailbox exp_mbs的替换

连接时需要索引到对应的端口实例，这里refmod里使用的uvm_tlm_fifo out_tlm_fifos内置端口是uvm_get_peek_imp端口，它的端口实例时blocking_get_export
内置端口都是import端口，TLM FIFO内置了方法，而方法时在imp里实现的

---

完成上述步骤后，编译仿真结果没问题。

三、UVM回调类

练习uvm_callback的定义、链接和使用方式。将原有的mcdf_data_consistence_basic_test和mcdf_full_random_test的类的实现方式（类的继承方式）修改为回调函数的实现方式。
类的复用除了可以用继承，还可以使用回调函数

3.1 在uvm_callback类中预定义虚方法

3.2 使用宏注册完成uvm_test类与uvm_callback类的关联

在mcdf_base_test类中使用宏uvm_register_cb(T,CB)完成类的关联

mcdf_base_test类与cb_mcdf_base类匹配

3.3 指定uvm_callback类的回调方法

在mcdf_base_test中的方法里，使用宏uvm_do_callbacks(T,CB,METHOD)指定执行的回调方法

3.4 完成剩余两个测试类与回调类的定义

回调类属于uvm_object类

1.cb_mcdf_data_consistence_basic与cb_mcdf_data_consistence_basictest
首先完成回调类CB中的cb_do_reg/cb_do_data/cb_do_formatter的配置任务，直接复制SV中的内容即可，然后是在测试类T中的build phase阶段完成添加callback，添加前需要声明并例化回调类CB，最后在connect phase阶段将测试类T的句柄交给回调类的mcdf_base_test test句柄。这样在mcdf_base_test中注册时相当于测试类T与回调类CB的父类完成了关联，这样子类就可以回调CB可以使用宏执行回调函数，测试类T的add就可以生效。
也就是说只要用目标测试类替换了第一个参数，就能完成目标测试类T与回调函数CB的关联，而且这样并不会有影响（感觉有点麻烦，注册时CB参数是父类就可以，为什么T参数是父类就不可以，还必须要把子类句柄T给父类test）

说到这里是不是感觉缺点什么，没错注册有了，添加有了，回调方法有了还缺宏uvm_do_callback来指定回调方法，那么它在哪里呢？它就在测试类T的父类的配置方法里面，测试子类继承于父类，自然是有这些方法的。
整体步骤：

2.cb_mcdf_full_random与cb_mcdf_full_random_test
同上，略

---

【思考】UVM_callback的优势：
从3.4节我们可以看到在完成了3.1~3.3的步骤后（完成CB基类与test基类定义与关联），如果需要定义一个新的测试用例我们只需要一个callback类和一个test类，看似从一个class变成两个class，代码量也些许增加了。在callback类中我们只需要更新回调方法即配置任务的内容，test类中我们只需要声明例化CB类，然后添加uvm_callback对象来执行回调方法，test类句柄替换test基类句柄。那么它的优势在哪？
我感觉它是将配置与测试分离，并且通过callback的add()方法又将配置与测试匹配。这样可以实现一个测试用例多种配置，多种组合？比如我在cb_full_random_test中添加add两次callback对象相当于SV模块跑了两次不同的测试用例，当然一定有其他典型应用场景。现阶段用不上

四、UVM仿真控制方法

使用更多的uvm_root方法，参考实验1消息管理：

• 在mcdf_base_test类中connect phase后面添加新的phase函数 end_of_elaboration_phase()。同时使用uvm_root类将信息的冗余度设置为UVM_HIGH。另外用uvm_root::set_report_max_quit_count()函数设置仿真退出的最大数值，当error信息数量超过设定值，仿真退出。（默认情况下为-1，表示仿真不会随error信息数量影响而退出）
• 利用uvm_root::set_timeout()方法设置仿真最长时间，以此代替do_watchdog()方法

该函数指定仿真的时间，即模拟的最大时间，防止仿真因未知原因持续挂起。