release notes: 略。有需要再回头去查。
基类:
– 概括
所有环境的基础构建模块都是组件和他们用来通信的transactions。UVM的基类继承关系可以参考下图。
所有的组件和transactions都继承自uvm_object。它定义了一个内核基类的操作接口：create, copy, compare, print, sprint, record,等等。他还定义了实例化识别的接口(name, type name, unique id,等等），随机种子的接口。
uvm_component是所有UVM组件的基类。组件是贯穿整个仿真都存在的准静态对象。这样他们可以像module或program一样去建立结构化层次。每个组件都可以通过一个层次化路径名子来单独索引，例如”env1.pci1.master3.driver”这样的写法。uvm_components还定义了一个分相位的测试流程，在仿真的进程中组件都会follow这个流程。每个相位（build, connect, run, 等等）都由一个有精确执行顺序的回调(callback)来定义。最后，uvm_components还定义了configuration，reporting，transaction recording, 工厂模式接口。
uvm_transaction是所有uvm transaction的基类。不同于uvm_components，transaction在本质上是瞬态的。它在uvm_object基类只是，扩展了timing和recording的接口。简单的transactions可以直接继承自uvm_transaction，使能了序列的transaction则需要继承自uvm_sequence_item。
uvm_root类是特殊的uvm_component类，他用作所有uvm组件的顶层组件，为所有UVM组件提供相位控制和其他全局服务。
– uvm_void
uvm_void类是所有UVM类的基类。它是一个抽象类，不包含数据成员或函数。它可以为对象创建通用容器，类似C语言中的空指针。从uvm_void派生的用户类不继承任何UVM功能，但这样的类可以和其他UVM对象一同放置在uvm_void类型的容器中。
uvm_utils #(TYPE, FIELD)类包含很有用的模板功能。
其中find_all method可以由start组件开始向下递归地找到所有参数类型为TYPE的组件实例。
*此处附一则find_all的使用示例：使用find_all通过关键字查找并自动连接sequencer，有趣的用法。
其中get_config method用来获得与组件comp相关联的、类型为TYPE的对象配置。同时会检查这两项约束条件，返回一个error标志。
*查看源码可知，get_config实际上调用的是uvm_component中的get_config_object函数；而该函数最终调用的是uvm_config_db的get方法。
– uvm_object
uvm_object类是所有UVM数据和层次化类的基类。它主要的角色是为像create/copy/compare/print/record这样的通用操作来定义一系列method。从uvm_object派生出来的类必须执行像create和get_type_name这样的纯虚函数。
uvm_object的methods介绍：
a)
new – 用给定的实例名字创建一个新的uvm_object。
b)种子：
use_uvm_seeding – 该bit使能或关闭UVM种子产生机制。
reseed – 在该对象里调用srandom，以通过UVM种子产生机制重新为该对象产生种子。该机制大概是：基于类型名字和实例名字来设置种子，而非基于实例在一个线程中的位置设置。
c)标识：
set_name – 为对象设置实例名，覆盖任何先前定义的名字。
get_name – 返回该对象的名字，是new构造函数或者set_name方法给赋值的名字。
get_full_name – 返回该对象完整的层次化的名字。
get_inst_id – 返回该对象独有的数字编号的实例id。
get_inst_count – 返回实例计数器的当前值，反映了当前仿真中已分配的uvm_object基类对象的总数。
get_type – 返回该对象的类型代理（封装）。
*uvm_factory的基于类型的override和creation方法会带uvm_object_wrapper参数。如果实现了这个get_type方法，那么它可以很方便地提供这些参数。
*该函数默认会产生错误返回null。要想使能它，用户的子类型必须实现一个返回子类型wrapper的版本。示例如下图：
*如果使用了`uvm_*_utils宏，那么就会实现这个函数。
**（参见源码，macro/uvm_object_defines.svh里所有此类宏都实现了get_type方法）
get_object_type – 返回该对象的类型代理（封装）。
*这个方法跟get_type很像，唯一区别是它访问的是已分配对象，而get_type访问的是静态对象。
*该方法的缺省实现调用的是get_type_name;如果get_type_name的返回类型是没有注册到工厂的，那么就返回null句柄。
get_type_name – 该函数返回该对象和类型名字，一般就是写在括号里的类型标识。
*该方法用于库的多种debug功能，还用于工厂模式下创建对象。该函数必须在每个继承类都定义一遍。
*像下图这种典型实现，定义一个静态变量type_name，这样可以通过作用域操作符”::”访问类型名称，mytype::type_name，而无需类的实例化对象。
d)创建：
create – 该方法分配了一个与该对象类型相同的新对象，并通过一个基础的uvm_object句柄返回该对象。从uvm_object继承的每一个类，都必须直接或间接地实现create方法。典型实现如下图。
clone – 该方法创建并返回一个该对象的精确副本。缺省实现实在create后面加一个copy。因为clone是虚函数，继承类如果需要的话可以覆盖该实现。
***虚函数可以被覆盖，实函数不能被覆盖吗???
***虚函数的解析过程发生在运行时，成员函数的解析过程发生在编译时???
e)打印：
print – print方法基于给定的print参数，以特定的格式和风格，详尽地打印该对象的属性。如果没有提供参数，那么就使用全局对象uvm_default_printer. UVM还提供了很多策略诸如uvm_line_printer/uvm_tree_printer/uvm_table_printer等等。
sprint – sprint方法跟print方法基本一致，区别是sprint会把结果作为字符返回，而不是打印出来。该方法不是虚函数，因此不能被重载。如果要在print和sprint操作之外增加功能，派生类必须重载do_print方法，使用提供的printer策略类来固定格式输出。printwe策略会把所有字符连接起来，提供给sprint，返回给调用接口。
do_print – 该方法是用户可自定义的钩子，print和sprint里调用了这个钩子，允许用户来定制，除`uvm_filed_*宏提供的域信息之外，还要打印哪些信息。printer参数是策略对象，决定输出的格式和内容。为确保print和sprint正确执行，确保输出格式统一，所有do_print实现中都必须使用printer参数。也就是说，跟使用$display或者直接拼接字符不一样，一个do_print实现必须通过调用printer API来增加打印信息。
参考实例如下：
更多API信息可参考uvm_printer介绍。
convert2string – 该虚函数是一个用户自定义钩子，直接由用户调用，允许用户以字符形式提供对象信息。跟sprint不用的是，这里不需要使用uvm_printer策略对象。因此，这里输出的格式和内容是完全客制化的，可用于不需要跟print/sprint/do_print API保持格式一致的应用场景。使用示例可参考下面几张图：
f)记录：
record – 该方法根据可选的recorder策略来详细记录该对象的属性。这不是虚函数，所以不能重载。要增加额外的记录，派生类应该覆盖do_record方法。可选的recorder参数指定了记录策略，可参考uvm_recorder API部分的详情。每个仿真器的记录机制都是厂商自定的。通过提供一个通用访问接口，uvm_recorder策略提供了独立于厂商的仿真器记录能力。
do_record – 该方法是由record方法调用的用户可自定义的钩子。派生类应该覆盖该方法，以便记录下自己的field。典型应用参考下图。
g)复制：
copy – 该方法把当前对象变为指定对象的副本。该方法不是虚函数，不能在派生类中重载。如果想copy派生类中的域，需要覆盖do_copy方法。
do_copy – 该方法是由copy方法调用的用户可自定义的钩子。派生类要想在copy中包含自动的域，必须覆盖该方法。实现必须调用super.do_copy，而且在复制之前必须把rhs参数强制类型转换到派生类型。（***此处我需要一个更详细的实例啊）
h)比较：
compare – 将当前数据对象和rhs(左手边)语句提供的对象进行比较，相同返回1，不匹配返回0. 该方法不是虚函数，在派生类里不能被重载。
do_compare –
i)封包：
j)解包：
k)配置：
– uvm_transaction
– uvm_root
– ucm_port_base