UVM学习笔记
UVM学习笔记
一、类库地图
1、来源：
将验证过程中可以重用和标准化的部分都规定在其方法学的类库中。
2、对验证环境的共同需求：
- 组件的创建和访问；
- 环境的结构创建、组件之间的连接和运行；
- 不同阶段的顺序安排；
- 激励的生成、传递和控制；
- 测试报告机制。
3、类库地图
4、地图分类：
- 核心基类：提供最低层的支持，包括复制、创建、比较和打印等一些基本方法；
- 工厂（factory）类：提供注册环境组件、创建组件和覆盖组件类型方法；
- 事务（transaction）和序列（sequence）类：规定在TLM传输管道中的数据类型和数据生成方式；
- 结构创建（structure creation）类；
- 环境组件（environment component）类：构成验证的主要部分；
- 通信管道（channel）类；
- 信息报告（message report）类；
- 寄存器模型（register model）类；
- 线程同步（thread synchronization）类；
- 事务接口（transaction interface）类：与通信管道类共同实现组件之间的通信和存储。
二、工厂机制
1、工厂的意义：为了更方便的替换验证环境中的实例或者注册了的类型。
2、UVM验证环境一部分构成了环境的层次，通过uvm_component类完成；另一部分构成了环境的属性和数据传输，通过uvm_object类完成。
3、运用factory的步骤：
- 将类注册到工厂；
- 在例化前设置覆盖对象和类型；
- 对象创建。
4、uvm_coreservice_t类内置了UVM世界核心的组件和方法，主要包括：唯一的uvm_factory，用来注册、覆盖和例化；全局的report_server，用来做消息统筹和报告；全局的tr_database，用来记录transaction记录；get_root()方法用来返回当前UVM环境的结构顶层对象。
5、覆盖方法
6、确保正确覆盖的代码要求
7、UVM通过域的自动化，使得用户在注册UVM类的同时也可以声明今后会参与到对象复制、克隆、打印等操作的成员变量。
8、验证的不动产：generator、simulator、monitor、agent、checker/reference model、environment、test。非固定资产：TLM transaction、从generator流向stimulator的数据包。
9、创建component和object的方法：
comp_type::type_id::create(string name,uvm_component parent);
其中parent参数将整个UVM结构串接起来；
object_type::type_id::create(string name);
只能作为configuration或者transaction等用做传递的配置结构体或者抽象数据传输的数据结构体。
10、uvm_coreservice_t类，内置UVM世界核心的组件和方法，主要包括：
- 唯一的uvm_factory，用来注册、覆盖和例化；
- 全局的report_server，用来做消息统筹和报告；
- 全局的tb_database，用来记录transaction记录；
- get_root()方法用来返回当前UVM环境的结构顶层对象。
11、注册宏
-
`uvm_{component,object}_utils
-
通过例化该类的对象来完成；
-
调用宏时只注册一次，放置到factory字典当中；
12、component/object配合工厂注册、创建和覆盖的方法：
create()、create_component()、get()、get_type_name()、set_inst_override()、set_type_override()
三、覆盖
1、覆盖机制可以将原来所属的类型替换为另一个新的类型，保证了原有代码的封装性。新的替换类型必须与被替换类型相兼容。
2、类型覆盖：UVM 层次结构下所有原有类型都会被覆盖类型所替换；
实例覆盖：在某些位置中原有的类型会被覆盖类型所替换。
3、覆盖方法：
static function void set_type_override(uvm_object_wrepper override_type,bit replace=1);
其中override_type是注册后的某一个类在工厂中注册的句柄，使用new_type::get_type()找到。
static function void set inst_override(uvm_object_wrapper override_type,string inst_path,uvm_component parent=null);
其中inst_path表示组件结构的路径字符串。
4、comp2覆盖了comp1类型：
comp1::type_id::set_type_override(comp2::get_type());
5、factory的三个核心要素：注册、创建和覆盖：
`uvm_{component,object}_utils
uvm_{component,object}::type_id::create()
set_{type,inst}_override{,_by_type}()
四、核心基类（uvm_object）
1、核心方法：
copy、clone、compare、print、pack/unpack。
2、域的自动化（field automation）：
用户在注册UVM类的同时也可以申明今后会参与到对象拷贝、克隆、打印等操作的成员变量。使用`uvm_{component,object}_utils_begin和`uvm_{component,object}_utils_end来配对包裹接下来的域的自动化。
3、Copy和clone：
前者默认已经创建好了对象，只需要对数据进行拷贝；后者则会自动创建对象并对source object进行数据拷贝，再返回target object句柄。
4、比较（compare）：
function bit compare (uvm_object rhs,uvm_comparer comparer=null);
5、全局对象：
uvm_default_comparer、uvm_default_printer、uvm_default_packer。
6、打印（print）：
- uvm_dafault_tree_printer：可以将对象按树状结构打印；
- uvm_dafault_line_printer：可以将对象数据打印到一行上面；
- uvm_dafault_table_printer：可以将对象按表格的方式打印；
- uvm_dafault_printer：UVM默认的打印设计，指向uvm_dafault_table_printer。
五、phase机制
1、用途：可以很清晰地将UVM仿真阶段层次化。
| phase | 函数/任务 | 执行顺序 | 功能 | 典型应用 |
|---|---|---|---|---|
| build | 函数 | 自顶向下 | 创建和配置测试平台的结构 | 创建组件和寄存器模型，设置或获取配置 |
| connect | 函数 | 自底向上 | 建立组件之间的连接 | 连接TLM/TLM2的端口，连接寄存器模型和adapter |
| end_of_elaboration | 函数 | 自底向上 | 测试环境的微调 | 显示环境结构，打开文件，为组件添加额外配置 |
| end_of_simulation | 函数 | 自底向上 | 准备测试环境的仿真 | 显示环境结构，设置断点，设置初始运行的配置值 |
| run | 任务 | 自底向上 | 激励设计 | 提供激励、采集数据和比较数据，与OVM兼容 |
| extract | 函数 | 自底向上 | 从测试环境中收集数据 | 从测试平台提取剩余数据，从设计观察最终状态 |
| check | 函数 | 自底向上 | 检查任何不期望的行为 | 检查不期望的数据 |
| report | 函数 | 自底向上 | 报告测试结果 | 报告测试结果，将结果写入到文件中 |
| final | 函数 | 自底向上 | 完成测试活动，结束仿真 | 关闭文件，结束联合仿真引擎 |
2、常用的phase包括build、connect、run、report，分别完成组件的建立、连接、运行和报告。
3、run_phase中，用户如果要完成测试，通常需要组织以下激励序列：上电、复位、寄存器配置、发送主要的测试内容、等待DUT完成测试。
4、
5、uvm_top承担的核心职责：
- 通过创建组件时指定parent来构建层次；
- 若parent为null，那它将作为uvm_top的子组件；
- Phase控制，控制所有组件的phase顺序；
- 索引功能，通过层次名称来索引组件实例；
- 报告配置，通过uvm_top来全局配置报告的繁简度；
- 全局报告配置。
6、通过uvm_top调用方法run_test（test_name），uvm_top做了如下初始化：
- 得到正确的test_name；
- 初始化objection机制；
- 创建uvm_test_top实例；
- 调用phase控制方法，安排所有组件的phase方法执行顺序；
- 等待所有phase执行结束，关闭phase控制进程；
- 报告总结和结束仿真。
六、config机制
1、便利性：在仿真中可以通过变量设置来修改环境。通过外部的参数配置，使得环境在创建时可以根据不同参数来选择创建的组件类型、组件实例数目、组件之间的连接以及组件的运行模式。
2、常见的uvm_config_db类使用方式：
- 传递virtual interface到环境中；
- 设置单一变量值，例如int、string、enum等；
- 传递配置对象（config object）到环境。
例如：
uvm_config_db#(T)::set(uvm_component cntxt, string isnt_name, string field_name, T value);
uvm_config_db#(T)::gett(uvm_component cntxt,string isnt_name, string field_name, inout T value);
3、interface传递：解决了连接硬件世界和软件世界。uvm_config_db使得接口的传递和获取彻底分离开来。
七、消息管理
1、消息的处理方式是同消息的严重级别对应的。
| 处理方式 | 说明 |
|---|---|
| NO_ACTION | 不做任何处理 |
| UVM_DISPLAY | 将消息输出到标准输出端口 |
| UVM_LOG | 将消息写入到文件中 |
| UVM_COUNT | 增加退出计数变量quit_count，当quit_count达到一定数值时停止仿真 |
| UVM_EXIT | 立刻退出仿真 |
| UVM_CALL_HOOK | 调用对应的回调函数 |
| UVM_STOP | 停止仿真 |
而不同的严重级别消息，用户可以使用默认的消息处理方式
| 严重级别 | 默认处理方式 |
|---|---|
| UVM_INFO | UVM_DISPLAY |
| UVM_WARING | UVM_DISPLAY |
| UVM_ERROR | UVM_DISPLAY|UVM_COUNT |
| UVM_FATAL | UVM_DISPLAY|UVM_EXIT |
2、四个消息函数有若干共同信息：严重级别（severity）、冗余度（verbosity）、消息ID、消息、文件名和行号。
3、回调函数：用户在调用回调函数时，首先会调用report_hook()函数，接下来才按照severity级别选择更细致的回调函数report_SEVERITY_hook()。
八、组件家族
1、uvm_driver类定义：
class uvm_driver #(type REQ = uvm_sequence_item, type RSP = REQ) extends uvm_component;
该类会从uvm_sequencer中获取事务（transaction），经过转化进而在接口中对DUT进行时序激励。
2、uvm_monitor：该类为了监测接口数据，任何需要用户自定义的数据监测行为的monitor 都应该继承与该类。
3、该类执行的功能包括：
-
观测DUT的interface，并且收集总线信息；
-
永远保持PASSIVE模式，永远不会驱动DUT；
-
在总线协议或者内部信号协议观察时，可以做一些功能和时序的检查；
-
对于更加复杂的检查要求，它可以将数据发送至其他验证组件。
4、uvm_sequencer：如同一个管道，从这个管道中会产生连续的激励事务，并最终通过TLM端口送至driver一侧。也可从uvm_driver那获得随后的RSP对象来得知数据通信是否正常。
5、sequencer既管理sequence，同时也将sequence中产生的transaction item传送到driver一侧。
6、uvm_agent：一个标准的验证环境单位，通常包含driver、monitor、sequencer。按总线传输方向agent可分为master和slave，master agent用来向DUT发起transaction，slave agent用来响应events。
7、is_active是agent的一个成员，缺省值是UVM_ACTIVE。
8、uvm_scoreboard：接收来自多个monitor的检测数据，继而进行对比和报告。
9、uvm_env：包含多个uvm_agent和其它component。uvm_env为结构化容器，可以容纳其他组件，同时也可作为子环境在更高层的集成中被嵌入。
10、uvm_test:决定环境的结构和连接关系和使用哪一个测试程序，只有通过它才能正常运转UVM的phase机制。