UVM结构篇总结

UVM结构篇之一：组件家族

uvm_scoreboard

从名字来看，uvm_scoreboard担任着同SV中介绍的checker一样的功能，即进行数据比对和报告。uvm_scoreboard本身也并没有额外的成员变量和方法，但UVM建议用户将检查器类继承与uvm_scoreboard，这也便于日后的子类可以自动继承于可能被扩充到uvm_scoreboard中的成员。在实际环境中，uvm_scoreboard会接收来自于多个monitor中的监测数据，进行比对和报告。也正由于uvm_scoreboard通用的比较数据的特性，UVM自带的其它两个用来做数据比较的类则很少被使用到：

• uvm_in_order_comparator #(type T)

• uvm_algorithm_comparator #(type BEFORE, type AFTER, type TRANSFORMER)

uvm_in_order_comparator是一个参数类，并且它有两个端口

• uvm_analysis_export #(T) before_export;

• uvm_analysis_export #(T) after_export;

分别用来从DUT的输入端的monitor和输出端的monitor获取观测到的数据事务。该数据事务时将多个时钟周期内的数据整合为更高抽象级别的数据对象，而且要求是前后端监测到数据事务类型应该相同。为了进行数据比对，用户应该事先定义好需要的type T类，并且事先必要的函数compare()和convert2string()函数。这是因为uvm_in_order_comparator类会间接调用type T类的T::compare()函数进行数据比对，并且记录数据比较成功和失败的次数；同时在比较数据时如果发生不匹配，也会调用T::conver2string()将两个数据事务对象的内容进行报告。
uvm_algorithm_comparator也是一个参数类，只不过它的参数数目要更多。这是为了贴合更多实际的场景中，DUT的输入端监测数据格式不同于输出端数据格式，因此type BEFORE与type AFTER两个类不相同，同时用户也应该提供一个用来将type BEFORE转换为type AFTER类的转换类type TRANSFORMER。至于uvm_algorithm_comparator类的实现，它是内嵌了一个uvm_in_order_comparator作为数据比对的基础，在比较之前，用户需要实现BEFORE类和AFTER类的compare()、conver2string()函数，同时也应当实现TRANSFORMER类的transform()函数。这样便可以将接收到的BEFORE类，通过TRANSFORMER::transform()函数转化为AFTER类送给其内置的uvm_in_order_comparator对象，保证提供给uvm_in_order_comparator对象的输入端和输出端的数据类型一致，最终完成数据比对。

而在更多的项目实践中，上面这两种类很少被使用的一个主要原因是，“一千个验证者就有一千个比较器”。UVM在开发初始，期望通过一般化的原则提取比较的主要方式，提供给用户两个更具有可维护性的类，但这仍然难以阻止用户们打扮自己的scorebaord，而不怎么热衷于使用这两个有碍于他们发挥横溢才华的盒子。

UVM结构篇之四（终）：构建环境的内经

在上一节如何建立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不会克隆，而直接在这些对象（引用对象）上进行操作。对克隆后的对象操作，改变了数值不会影响原先的自生对象属性；而如果在引用对象上进行操作，那么也会对自生对象造成数据修改。