- 使用UVM的第一条原则：验证平台中所有的组件均应派生自UVM中的类。
- factory机制：必须用宏
uvm_component_utils，uvm_object_utils, uvm_object_utils_begin … end注册后才能使用。 - UVM factory机制会维护一个注册表，这些宏可以把用户定义的类注册到该表中。
- 在top tb中使用
run_test("your_test_name"),它会自动创建和运行类，该对象的名字是uvm_test_top。也可以在run的命令行中添加：+UVM_TESTNAME=my_case 来指定运行某个case。 - config_db 机制：由于UVM通过run_test语句实例化了一个脱离了top tb层次结构的实例，建立了脱离了硬件世界的软件天地，为了对这片天地里的信号等进行配置，UVM引入了config_db机制。
config_db分为set和get两部操作。 - 在main_phase中，raise_objection() 应该放在第一个消耗时间的语句前，否则无法起到作用。当然，标准的基于uvm 的testbench只应该在sequence里 raise/drop objection.
- 执行顺序 ：
在build_phase时是从树根到叶子，有在每级节点创建完成后才开始下级结点的创建。同一级下的component创建先后顺序不确定 (?)
具体参考build_phase执行顺序的实验结果
在connect_phase时是从叶子到树根的顺序. - interface在class中使用会引起编译错误。为了在class中使用，SystemVerilog创造了
virtual interface。 - 使用UVM宏语句的结尾不用分号结尾也可，如
uvm_info, uvm_fatal, uvm_component_utils等。 - UVM
test类的三个主要作用：1.例化顶层验证环境 2.通过factory overrides或config db的方式配置验证环境 3.通过引入Sequence来完成test的具体测试内容。 - UVM
env类： 一个soc top env下可能由许多 dedicated的env，如PCIe Env， USB env， Memory controller Env等。 - filed automation机制: 提供
copy()，compare()，print()等函数，以及pack_bytes(),unpack_bytes()等。
tr.pack_bytes(data_q)将tr中所有的字段变成byte流放入data_q中，其放入顺序是根据uvm_filed系列宏的书写顺序排列的。
tr.unpack_bytes(data_array)函数将data_array数组中的byte流转化成tr中已被filed automation注册过的各个字段 - 在定义component 时使用参数化的定义之名使用的transcation类型，这样可以使用其预定义好的成员变量，如driver中的req
- sequence不属于验证平台的任何一部分。sequence就像弹夹，里面的子弹是transcation，而sqeuencer是一把枪。弹夹用完就扔掉没用了，但枪只有战斗结束才不用。
uvm_do宏做如下事：
1.创建一个transcation的实例。
2.将其随机化。
3.最终将其送给sequencer。- driver从sequencer中获取item的方法：
seq_item_port.get_next_item(req)是阻塞的
seq_item_port.try_next_item(req)是非阻塞的
try_next_item的行为更接近真实的driver的行为，当由数据时就驱动数据到总线，否则总线就处于空闲状态。 - 通过set
default_sequence的方式启动sequence。 starting_phase是uvm_sequence基类中的uvm_phase类型的成员变量。sequencer在启动default_sequence时，会将自身的phase赋值给seq.starting_phase. 因此sequence中可以使用starting_phase进行raise/drop objection。
参考：
UVM实战(卷1) (张强 著)