初识UVM

UVMlab1

---

---

前言

参考文章：路科验证MCDF_uvmlab1

---

一、工厂的注册、创建和覆盖机制

目的：工厂的注册、创建和覆盖机制

覆盖类最好是原始类的子类，相关方法virtual。如有需要请记得$cast。
get_full_name可以完整地得到当前component的路径。
set_type_override_by_type（）和set_type_override（）的区别，前者函数内部通过xx::get_type()传递类名，后者通过字符串传递，更方便。

二、域的自动化和uvm_object的常用方法

1.域的自动化

目的：通过将成员变量在下方代码中进行注册，可以直接赋予变量常用的操作，比如通过::config_db配置、复制、克隆、打印、比较等

2.uvm_object常用方法

在.compare()时如果不定义自己的uvm_comparer会使用uvm_default_comparer。可以通过uvm_default_comparer.show_max配置comparer来更改错误输出信息的最大值。

三、让component引以为傲的phase机制

贯穿UVM的设计哲学：在不同时间做不同的事情，在同一时间做不同的事情。

四、config机制

如果说SV对于package的配置是白盒验证，那么拥有config机制的UVM可以说是黑盒验证，直接开创了验证IP的新时代！

在哪里set，哪里get：在顶层tb去set，在底层的build_phase中去get（传递变量和对象也一样）。

1.传递virtual interface到环境中。

由于vif是硬件属性，接口set要发生在run_test之前。

uvm_config_db#(virtual uvm_config_if)::set(uvm_root::get(),"uvm_test_top.*","vif",if0);

uvm_config_db#(virtual uvm_config_if)::get(this,"","vif",vif)

2.设置单一变量值

在各个test中，可以在build_phase里对底层组件的变量set，在底层组件例化前get，既实现了变量值的修改，又无需重新编译。

uvm_config_db#(int)::set(this,"c1.c2","var2",20)

uvm_config_db#(int)::get(this,"","var2",var2)

3.传递配置对象

如果在test配置里，需要配置的参数多，而且还分属于不同的组件，那么对多层次的变量还采用变量设置的方法，就需要更多的代码，容易出错，还不易于复用。甚至底层组件的变量被删除后，也无法通过uvm_config_db::set()得知配置是否成功。

将每个组件中的变量加以整合，放置到一个uvm_object中，再把这个对象进行传递，会更有利于整理环境的维护。

uvm_config_db#(config_obj)::set(this,"c1.c2","cfg",cfg)

uvm_config_db#(config_obj)::get(this,"","cfg",cfg)

4.tips

《UVM实战》：对于build_phase来说，
uvm_component对其做的最重要的事情就是自动获取通过config_db::set设置的参数。

满足以下要求get可以省略
使用uvm_field_*对成员变量进行注册
build_phase中包含super.build_phase语句
笔者所接触的代码中大部分情况下都满足。
原因在于super.build_phase，执行完super.build_phase这一句后，变量的值就已经config。

五、消息管理

验证后期，验证环境较为稳定，减少不必要的消息打印可以提高仿真速度。

对于本类的消息管理

set_report_verbosity_level_hier(UVM_NONE)

set_report_id_verbosity_hier("id",UVM_NONE)

对于全局的消息管理

uvm_root::get().set_report_verbosity_level_hier(UVM_NONE)

uvm_root::get().set_report_id_verbosity_hier("id",UVM_NONE)

结语

念去去，千里烟波，暮霭沉沉楚天阔 ------《雨霖铃》
2023.5.11于西军电