在上一节如何建立MCDF子模块以及顶层环境复用方案的介绍中，读者们可以看到在发送测试序列之前，首先需要创建一个结构化的环境。如果我们将环境建立的核心要素拆解开来，那么它们可以分为下面四个部分：

• 单元组件的自闭性

• 递归创建

• 通信端口连接

• 顶层配置

单元组件的自闭性

自闭性指的是单元组件（例如uvm_agent或者uvm_env）自身可以成为独立行为，不依赖于其它并行的组件。举例来说，driver同sequencer之间，虽然driver需要获取sequencer的tranaction item，但是它本身可以独立例化，而它们之间的通信也是基于TLM端对端的连接实现的。这种单元组件的自闭性为日后的组件复用提供了良好基础，又例如上一节在MCDF的顶层环境复用方案二中，各个子环境也可以独立集成于顶层环境，互相之间也不需要额外的通信连接，各自划分“小世界”施行自治。

递归创建

环境的框架建立主要就依靠这一技能了。通过这种方式，上一级的组件在例化自身（执行new()函数）之后，会进而执行各个phase阶段，通过build phase可以进一步穿件它内部的子组件。而这些子组件也通过一样的过程，在创建它们的下一级组件。递归创建之所以可以实现，这要依赖于自顶向下执行顺序的build phase。在之前的《工厂机制》中我们详细讲过各个phase的功能特点，通过build phase的这种结构化执行顺序可以保证父组件必先于子组件创建，而其它创建的过程中包含了这些步骤：

• 通过在定义成员变量时赋予默认值，或者在new()函数中赋予初始值。

• 结构配置变量用来决定组件的条件生成，例如uvm_agent依靠is_active变量来判断是否需要例化uvm_sequencer和uvm_driver。

• 模式配置变量用来决定各个子组件的工作模式。

• 子组件按照自顶向下的顺序依次生成。

通信端口连接

在完成了整个环境结构的创建以后，各个组件之间会通过通信端口的连接进行数据通信。常见的端口通信用途包括：

• driver的端口连接到sequencer，并且从sequencer出采取blocking pull的形式获取transaction item。

• monitor的端口连接到scoreboard内部的analysis fifo，将监测到的数据写入其中。

更多TLM通信的细节我们将在《UVM通信篇》中为读者介绍。

顶层配置

正是由于单元组件的自闭性，UVM的结构不建议用户通过引用子环境的句柄，索引更深层次的变量进行顶层的配置，因为这样做无疑会增加顶层环境同子环境的黏性，无法做到更好的分离。所以，更好的方式是通过配置化的对象，作为绑定与顶层环境的部分，传递到子环境中，而子环境的各个组件又可以从结构化的配置对象中获取自身的配置参数，从而在build phase、connect phase以及run phase中来决定它们的结构和运行模式。

而顶层配置对象可以在子环境没有例化时就将其配置到将来会创建的子环境当中，无需考虑顶层配置对象会先于子环境生成。这就给UVM使用者们提供了安全的配置方式：

• 无论在哪一层使用配置，应该尽量将所有的配置都置于子环境和子组件的创建之前，保证配置已经完成设置。

• 配置的作用域应该只关注当前及以下的层次，而不涉及更高的层次配置。

• 配置的对象结构也应该尽量独立，最好也同环境结构一样形成一个树状结构。这样带来的好处在于，独立的配置对象会对应独立的子环境，如果将独立的配置最终合并为一个顶层配置结构，那么顶层配置对象便于维护和配置。

• 由于config_db的配置特性，使得高层的配置作用会覆盖低层的配置，这也使得在uvm_test层次做出的不同配置可以控制整体的结构和模式。

在抽离出这些核心要素以后，读者们可以再来看看，一个典型的验证环境中的变量、组件和配置是如何存在和相互作用的。而这些互动的关系，也可以一一对应到一个实体环境中来。我们依旧将MCDF的一个模块环境reg_env作为参考，来看看一个环境中的生态系统是怎么运行的。

在这个环境当中有更多的细节，而且将uvm_test层也作为比uvm_env更高的层次绘制出来，这是因为在uvm_test一层中也会有一些配置的部分传递给子环境。包括构成环境结构的组件uvm_component在内，环境中更多的元素经过分类可以分为三大部分：

• 成员变量

• 一般变量

• 结构变量

• 模式变量

• 子组件

• 固定组件

• 条件组件

• 引用组件

• 子对象

• 自生对象

• 克隆对象

• 
  

• 引用对象

成员变量

一般变量用于对象内部的操作，或者为外部访问提供状态值。结构变量则用来决定内部的子组件是否需要创建和连接，例如上图中顶层的is_active变量即用作该目的。模式变量用来控制组件的行为方式，例如driver内部的模式变量经过配置，可以在run phase中做出不同的激励行为。对于结构变量和模式变量，它们一般由int或者enum类型定义，用户可以在uvm_test层通过uvm_config_db的配置方法直接设置，也可以通过结构化的配置对象来进行系统设置，而对于复杂的验证组件，后者的方式会容易操作和维护。

子组件

环境中必须创建的组件称之为固定组件，例如agent中的monitor无论对于active或者passive模式，都需要创建；又或者顶层环境中的scoreboard，也需要创建用来比较数据。条件组件则是通过结构变量的配置来决定是否需要创建，例如sequencer和driver只允许在active模式组件内创建。引用组件则是内部声明一个类型的句柄，同时通过自顶向下的句柄传递，使得该句柄可以指向外部的一个对象。例如，上面的图中在uvm_test一层，首先例化了一个寄存器模型rgm（固定组件），其后将该模型的句柄通过配置方式，传递到reg_env层中的rgm句柄（引用组件）。利用引用组件的方式，使得环境中各个层次在需要的情况下，都可以共享一个组件。这个共享方式，我们还会在接下来的《UVM通信篇》中为读者介绍uvm_event的特性和应用场景。

子对象

与子组件的细分方式类似的是子对象（uvm_object）的细分方法。在某一个层次中首先会创建一个对象，该对象可以称之为自生对象。而在该对象传递的过程中，该对象经过克隆从而生成一个成员数值相同的对象，称之为克隆对象。如果该对象经过了端口的传递，“到达”另一个组件，而该组件对其未经过克隆而直接进行操作的话，可以称之为对引用对象的操作。一个典型的例子就同上图的virtual sequence中，会生成分别送至reg_master_agent和reg_slave_agent的transaction item，分别是mst_t和slv_t。这些连续发送的mst_t和slv_t通过uvm_sequencer，最终抵达了uvm_driver。uvm_driver拿到这些transaction对象之后，如果首先做了克隆的操作，而后在该克隆的对象操作，进行数据激励是一种方式；也有一种方式，即driver不会克隆，而直接在这些对象（引用对象）上进行操作。对克隆后的对象操作，改变了数值不会影响原先的自生对象属性；而如果在引用对象上进行操作，那么也会对自生对象造成数据修改。

至此，路桑已经抽丝剥茧将验证方法学的核心模式和环境构成元素展示给了读者。也许读者在看完这些之后，还是有一种无法将思维模式落地的窘处，但坚持代码日常实践和对验证环境的系统思考是需要同时修炼的功课。

我们下一章《UVM通信篇》将带领读者领略TLM通信的魅力，希望读者在该篇过后不但可以懂得主要的TLM通信端口的特点，还可以知道UVM1.2同SystemC之间通过TLM2的通信端口如何进行常规通信，同时还可以学习一些UVM提供的经过扩展的同步元件。只有掌握了TLM通信的特性和意义，才可以为后面的《UVM序列篇》打好基础。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。