版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/maxwell2ic/article/details/90759208
- uvm_object是UVM中最基本的类，uvm_component也派生自uvm_object。
- 验证平台中常用派生自uvm_object的类有：
a) uvm_sequence_item，trasaction就是从uvm_sequence_item派生的封装了一定信息的类；
b) uvm_sequence，就是sequence_item的组合，sequence会直接与sequencer打交道，当driver向sequencer索要数据时，sequencer会检查是否有sequence要发送数据，当有sequence_item待发送时，会将此sequence_item交给driver；
c) config，主要功能是规范验证平台的行为方式，如driver读取总校要持续几个时钟
d) uvm_reg_item；uvm_reg_map；uvm_mem等用于register model
e) uvm_phase，主要作用为控制uvm_component的行为方式，使得uvm_component平滑地在各个phase之间依次运转 - uvm_component比uvm_object多的两大特性为：通过new的时候制定parent参数来形成一种树形的组织结构；phase自动执行的特点。常用派生自uvm_component的类：
a) Uvm_driver：driver的功能是向sequencer索要sequence_item(trasaction)，并将sequence_item中的信息驱动到DUT上；
b) Uvm_monitor：monitor做的事情与driver相反，从DUT的pin上接收数据，并转换成transaction级别的sequence_item，在把转换之后的数据发给scoreboard，供其比较
c) Uvm_sequencer：sequencer的功能是组织管理sequence
d) Uvm_scoreboard：比较reference model和monitor分别送来的数据
e) Reference model：派生自component，可以用高级语言实现
f) Uvm_agent：只是把driver和monitor封装起来，根据is_active决定只实例化monitor还是同时实例化driver和monitor，主要是可重用性角度考虑
g) Uvm_env：将验证平台中固定不变的component封装在一起
h) Uvm_test：不同测试用例派生不同的test类 - 完整的UVM树
- Field_automation机制：主要提供copy，compare，pack，unpack，print等函数对object实例进行操作
- Config_db机制：用于在UVM验证平台间传递参数，set函数寄信，get函数收信。函数第一个和第二个参数联合起来组成路径，第三个参数表明传给目标中的哪个成员，第四个参数是要设置的值
- TLM(Transaction Level Modeling)实现component之间通信。一个transaction就是把具有某一特定功能的一组信息封装在一个成为一个类
a) Put操作，A发起发送给B的transaction；get操作，A向B索取一个transaction。发起者A的端口是PORT，B的端口EXPORT，PORT->EXPORT体现的是控制流而不是数据流。一个transport操作相当于一次put一次get，两次发起者都是A。三种操作都有阻塞非阻塞之分。
b) Uvm中用connect函数建立连接关系A.port.connect(B.export) - Phase机制：按是否消耗仿真时间，分为
a) function phase，如build_phase、connect_phase、report_phase等不消耗仿真时间的phase，通过function实现；
b) task phase，如reset_phase、configure_phase、main_phase、shutdown_phase等消耗仿真时间的phase，通过task实现，后者task_phase称为动态运行phase。
c) uvm在build_phase中做例化工作（build按照树结构从上到下执行，首先执行my_testcase的build_phase，其次执行env的build_phase）；在connect_phase中做连线工作（自下而上执行）；对于同一层次的component如driver、monitor，uvm按照名称的字典顺序执行
d) phase机制的引入解决了因代码顺序杂乱引起的问题，比如要连线首先要例化
e) domain机制把不同的时钟域隔开，之后不同domain的动态运行phase就不必同步；但其他function phase依然是同步的 - sequence机制：为了避免不同的激励就要重写driver的main_phase，可将激励的产生与驱动分离。使用sequence机制后，不同的测试用例中，将不同的sequence设置成sequencer的main_phase和default_phase
- 寄存器模型：可以在任何消耗时间的phase中以前门访问（模拟cpu在总线上发出度之灵，进行读写操作）或后门访问（不通过总线，而是直接通过层次化的引用来改变寄存器的值）方式读取寄存器的值，也能在某些不耗费时间的phase使用后门访问方式读取
a) Uvm_reg_field是最小单位，是存储具体寄存器数值的变量；uvm_reg是纯虚类，必须由其派生一个新类，这个新类中至少加入一个uvm_reg_field；uvm_reg_block用于组织大量uvm_reg的一个大容器；uvm_reg_map则是一个大箱子。以上分别是寄存器模型中不同层级的概念
b) 前门访问分成读操作和写操作，都会通过sequence产生一个uvm_reg_bus_op的变量，存储操作类型，经过转换后交给bus_sequencer，随后交给bus_driver
c) 可以通过两个基本任务read/write进行读写操作 - Factory机制：一般OOP语言中创建一个类的实例要么是在类的可见范围内直接创建实例，一种是使用参数化的类。而factory机制可以通过一个字符串创建此字符串所代表的类的一个实例。在没有factory机制之前，创建一个类的实例只能使用new函数，而factory可以根据类名创建类实例，也可以在创建类实例时根据是否有重载记录来决定创建原始的类还是重载的类的实例。Factory机制的实现都被集成在宏uvm_component_utils中，只要定义类时使用uvm_component_utils注册，在top_tb中就不需要对该类new实例化，调用main_phase，只需要run_test(“my_driver”)即可创建实例并调用main_phase。