env的作用：
实例化验证平台的各个组件，作为一个容器类，在这个容器里面实例化其他组件，然后再调用run_test时传递的参数就不再是my_driver，而是这个容器类，即让UVM自动创建这个容器类的实例。
所有env都应该派生自uvm_env，且与my_driver一样，容器类在仿真中也一直是存在的，使用uvm_component_utils宏来实现factory的注册。
14：这里使用了一种独特的的实例化方式。只有使用factory机制注册过的类才能使用这种实例化方式；只有使用这种实例化方式的实例，才能使用后文要讲诉的factory机制中最强大的重载功能。验证平台中的组件在实例化时都应该使用type_name::type_id::create的方式。
在drv实例化时，传递了两个参数，一个是名字drv，另一个是this指针，表示env，之前my_driver的new函数如下：
这个new函数有两个参数，第一个是实例的名字，第二个则是parent。由于my_driver在uvm_env中实例化，所以my_driver的父节点(parent)就是my_env。通过parent的形式，UVM建立起了树形的组织结构。在这种树形的组织结构中，由run_test创建的文件是树根（这里是my_env),并且树根的名字是固定的，为uvm_test_top
树根之后会长出枝叶（这里只有my_driver)，长出枝叶的过程需要在my_env的build_phase中手动实现。无论是树根还是树叶，都必须由uvm_conponent或者其派生类继承而来。UVM树的结构如图：
在加入my_env之后，整个验证平台有两个build_phase，一个是my_env的,一个是my_driver的。那么这两个bulid_phase按照何种顺序执行？
在UVM的树形结构中，phase的执行顺序是从树根到树叶的顺序,先执行所有的build_phase。当把整棵树的build_phase都执行完成之后，再执行其他的phase。
my_driver在验证平台中的层次结构发生了变化，一下从树根变成了树叶，所以在代码中也需要修改。
首先在top_tb中的run_test的参数修改了，从my_driver改为了my_env，在top_tb中使用config_db机制传递virtual my_if时，要改变相应的路径；
set函数的第二个参数从uvm_test_top变成了uvm_test_top.drv，其中uvm_test_top是UVM自动创建的树根的名字，而drv则是在my_env的build_phase中实例化drv时传递过去的名字。
