UVM学习笔记（一）

第1章与UVM的第一次接触

基本没有感兴趣的内容，推荐直接从第2章开始，防止劝退。

第2章一个简单的UVM验证平台

2.1 验证平台的组成

2.2 只有driver的验证平台

2.2.1 最简单的验证平台

driver应该派生自uvm_driver，而uvm_driver派生自uvm_component。相关派生关系如下图所示：

2.2.2 加入factory机制

factory机制的实现被集成在了一个宏中：uvm_component_utils。它可以将my_driver注册在UVM内部的一张表中。只要在定义一个新的类时使用这个宏，就相当于把这个类注册到了这张表中。然后使用run_test时，可以自动创建一个类的实例并调用其中函数main_phase。其中uvm_component_utils的入参是类名my_driver，而run_test入参为在UVM内部表中注册的字符串名（注意：这里的字符串名必须和类名相同）。

2.2.3 加入objection机制

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

2.2.4 加入virtual interface

目的：杜绝在验证平台中使用绝对路径，从而增强验证平台的可移植性。

SV和UVM中端口使用的比对：

• sv中
  • 使用interface，通过对top_tb.my_driver.xxx的引用实现赋值。
• UVM中
  • 引入virtual interface：解决UVM类中无法实例化接口的问题。
  • 引入config_db机制：解决top中无法通过实例模块引用内部接口的问题（UVM通过run_test语句实例化了一个脱离了top_tb层次结构的实例，建立了一个新的层次结构，导致top_tb.my_dut.xxx可以，但top_tb.my_driver.xxx不可以）。具体而言分为set和get两步操作
  • 引入了build_phase：为config_db机制的实现服务。它也是UVM中内建的一个phase，在new函数之后main_phase之前执行（是一个函数phase，不消耗仿真时间）。通过config_db的set和get操作来传递一些数据，以及实例化成员变量等。

config_db机制中set方法的使用

• 第一个参数：目标get所在实例的参考路径索引（举例：“null”，“this”）。在top_tb中设置virtual interface时，由于top_tb不是一个类，无法使用this指针，所以设置set的第一个参数为null。
• 第二个参数：目标get所在实例的路径索引，它是相对于第一个参数的相对路径（举例："uvm_test_top"、"uvm_test_top.drv"）
• 第三个参数：一个名字，建立set与get之间的对应关系
• 第四个参数：set要传递个get的信号，信号为uvm_config_db#(xxx)中xxx的实例。

进一步解释：

• 无论传递给run_test的参数是什么，创建的实例的名字都为uvm_test_top。
• 由于set操作的目标是my_driver，所以set函数的第二个参数就是uvm_test_top。
• set函数与get函数使用双冒号是因为这两个函数都是静态函数，而uvm_config_db#（ virtual my_if）则是一个参数化的类，其参数就是要寄信的类型。

uvm_fatal宏的理解

• 类似于断言，条件为假时，结束仿真。

路径索引的概念：

• UVM采用树形结构，对于树中任何一个结点，都有一个与其相应的字符串类型的路径索引。路径索引可以通过get_full_name函数来获取，把下列代码加入任何UVM树的结点中就可以得知当前结点的路径索引：

$display("the full name of current component is: %s", get_full_name());