在验证平台中加入reference model、scoreboard等之前，思考一个问题：假设这些组件已经定义好了，那么在验证平台的什么位置对它们进行实例化呢？在top_tb中使用run_test进行实例化显然是不行的，因为run_test函数虽然强大，但也只能实例化一个实例；如果在top_tb中使用2.2.1节中实例化driver的方式显然也不可行，因为run_test相当于在top_tb结构层次之外建立一个新的结构层次，而2.2.1节的方式则是基于top_tb的层次结构，如果基于此进行实例化，那么run_test的引用也就没有太大的意义了；如果在driver中进行实例化则更加不合理。

这个问题的解决方案是引入一个容器类，在这个容器类中实例化driver、monitor、reference model和scoreboard等。在调用run_test时，传递的参数不再是my_driver，而是这个容器类，即让UVM自动创建这个容器类的实例。在UVM中，这个容器类称为uvm_env：

代码清单　2-25文件：src/ch2/section2.3/2.3.2/my_env.sv  4 class my_env extends uvm_env;  5  6   my_driver drv;  7  8   function new(string name = "my_env", uvm_component parent);  9     super.new(name, parent); 10   endfunction 11 12   virtual function void build_phase(uvm_phase phase); 13     super.build_phase(phase); 14     drv = my_driver::type_id::create("drv", this); 15   endfunction 16 17   `uvm_component_utils(my_env) 18 endclass

所有的env应该派生自uvm_env，且与my_driver一样，容器类在仿真中也是一直存在的，使用uvm_component_utils宏来实现factory的注册。

在my_env的定义中，最让人难以理解的是第14行drv的实例化。这里没有直接调用my_driver的new函数，而是使用了一种古怪的方式。这种方式就是factory机制带来的独特的实例化方式。只有使用factory机制注册过的类才能使用这种方式实例化；只有使用这种方式实例化的实例，才能使用后文要讲述的factory机制中最为强大的重载功能。验证平台中的组件在实例化时都应该使用type_name::type_id::create的方式。

在drv实例化时，传递了两个参数，一个是名字drv，另外一个是this指针，表示my_env。回顾一下my_driver的new函数：

代码清单　2-26function new(string name = "my_driver", uvm_component parent = null);   super.new(name, parent);endfuncti

这个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_component或者其派生类继承而来。整棵UVM树的结构如图2-3所示。

当加入了my_env后，整个验证平台中存在两个build_phase，一个是my_env的，一个是my_driver的。那么这两个build_phase按照何种顺序执行呢？在UVM的树形结构中，build_phase的执行遵照从树根到树叶的顺序，即先执行my_env的build_phase，再执行my_driver的build_phase。当把整棵树的build_phase都执行完毕后，再执行后面的phase。

my_driver在验证平台中的层次结构发生了变化，它一跃从树根变成了树叶，所以在top_tb中使用config_db机制传递virtual my_if时，要改变相应的路径；同时，run_test的参数也从my_driver变为了my_env：

代码清单　2-27文件：src/ch2/section2.3/2.3.2/top_tb.sv 42 initial begin 43   run_test("my_env"); 44 end 45 46 initial begin 47   uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.drv", "vif", inp ut_if); 48 end

set函数的第二个参数从uvm_test_top变为了uvm_test_top.drv，其中uvm_test_top是UVM自动创建的树根的名字，而drv则是在my_env的build_phase中实例化drv时传递过去的名字。如果在实例化drv时传递的名字是my_drv，那么set函数的第二个参数中也应该是my_drv：

代码清单　2-28class my_env extends uvm_env  …  drv = my_driver::type_id::create("my_drv", this);  …endclassmodule top_tb;…initial begin  uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.my_drv", "vif", inpu t_if);endendmodule