UVM(3)-组件家族

相比于SV，UVM的组件成员多了一个uvm_sequenccer（在后面会详细叙述），SV环境中的验证组件按照功能需要，被称之为激励器（stimulator）、检测器（monitor）、检查器（checker）。

这三个核心组件与验证环境的三个关键特性对应，即激励、监测和检查。在过往那么多验证方法学中，都有与其对应的组件（component）。

目录

一、uvm_driver

 二、uvm_monitor

 三、uvm_sequencer

四、uvm_agent

 五、uvm_scoreboard

六、uvm_env

七、uvm_test

---

在这节讲一下UVM的组件，它们的继承关系如下：

 从uvm_component类继承的类均可以构成验证环境，这是因为也都会经历各它们都从uvm_component类继承了phase机制，也都会经历各个phase阶段。

一、uvm_driver

1、从该类会从uvm_sequencer中获取事务(transaction），经过转化进而在接口中对DUT进行时序激励。

2、任何继承于uvm_driver的类需要注意的是，该类是参数化类，因此在定义时需要声明参数的类型

 3、用户在定义新的driver类时应当声明该类所需要获取的事务参数REQ类型，默认情况下，RSP参数类型同REQ类型保持一致。

4、uvm_driver在uvm_component基础上没有扩展新的函数，而只是扩展了一些用来通信的端口和变量（这一点在后面会详细讲到，记得关注后面的文章！！！）

 5、driver类与sequencer类之间的通信就是为了获取新的事务对象，这一操作是通过pull的方式实现的:

 上面这两个连接一般用第一个连接就够了，后面会讲到！！！

下面看一个例子：

 二、uvm_monitor

1、从名字来看，这个类是为了监测接口数据，而任何需要用户自定义数据监测行为的monitor都应当继承于该类。

2、虽然uvm_monitor与它的父类（uvm_component）相比，并没有增添新的成员和方法，但将新定义的monitor类继承于uvm_monitor类会有助于实现父类uvm_monitor的方法和特性。

 通常所执行的功能如下：

 三、uvm_sequencer

从uvm_sequencer类的定义来看，它需要也同uvm_driver一样是个参数类，在定义sequencer时声明REQ的类型。

后面细讲，这就省略了

四、uvm_agent

1、uvm_agent本身不具备什么神技，但它却是一个标准的验证环境“单位”，这样一个标准单位通常包含个driver个monitor以及这样的一sequencer。这三个小伙伴经常是聚在一起，组成一个小团伙agent。

2、同时为了复用，有的时候uvm_agent中只需要包含一个monitor，而不需要driver和sequencer，这就需要通过一个变量来进行有条件的例化。

3、is_active是agent的一个成员，缺省值是UVM_ACTIVE，这表示处在active模式的agent需要例化driver、monitor和sequencer；而如果is active的值是UVM_PASSIVE，这表示agent是passive模式只可以例化monitor。

4、active模式的agent既有激励功能也有监测功能，passive模式的agent只具有监测功能。
5、active模式对应着DUT的接口暴露给agent且需要激励的场景，而passive模式对应着DUT的接口已经与其它设计连接而只需要监测的场景。

6、通过is_active变量，agent需要在build_phase()和connect_phase()等函数中，通过选择语句来对driver和sequencer进行有条件的例化和连接，面这段例码是如何对agent内三个组件进行有条件例化的参考。

 注意：

• agent的存在是为了验证环境的复用
• 按照总线的传输方向划分可以分为master和slave
• Master agent是用来向DUT发起transaction。
• Slave agent是用来响应DUT的events。
• 对于UVM初学者，按照“路，只需要考虑在agent中创建所列出的常见组件。
• 

 五、uvm_scoreboard

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

• uvm_in_order_comparator是一个参数类，并且它有两个端口before_export和after _export分别从DUT的输入端monitor和输出端monitor获取观测到的数据事务。这些数据事务是将多个时钟周期内的数据整合为更高抽象级的数据对象，而且要求前后端监测到数据事务类型应该相同。
• uvm_algorithm_comparator也是一个参数类，它的参数数目要更多，这是为了贴合在更多实际场景中，DUT的输入端监测数据格式不同于输出端数据格式，因此type BEFORE与type AFTER两个事务类可以不相同，同时用户也应该提供用来将BEFORE类转换为AFTER类的转换类type TRANSEORMER。

 注意：

• 在scoreboard中通常会声明TLM端口以供monitor传输数据。
• 简易比较的方法，可以采用UVM预定义的comparator。
• 对于复杂的设计，参考SV模块中的做法，可以在scoreboard中分别创建reference model和comparator。
• 以此为例，也需要注意的是，如果一个组件中有子一级的组件，应该考虑它们的创建连接和通信问题。

六、uvm_env

不同组件共同构成一个完整的验证环境，而这个环境在将来复用中可以作为子环境被进一步集成到更高的环境中。

1. uvm_env的角色就是一个结构化的容器，它可以容纳其它组件同时它也可以作为子环境在更高层的集成中被嵌入。
2. 在实际使用中，用户容易混淆uvm_env与uvm_agent之间的嵌套关系，而且容易在创建对象阶段出现错误，建议的嵌套关系是:

• uvm_agent作为一个标准单元，在更上层的集成中应该被例化到uvm_env。
• uvm_env在更高层的复用中，可以被其它uvm_env所嵌套 
• 顶层只有一个env

七、uvm_test

1. 从uvm_test类本身没有什么新成员，但是作为测试用例的“代言人”，它不但决定着环境的结构和连接关系，也决定着使用哪一个测试序列。
2. 如果没有这个代言人，整个环境都无从建立，所以uvm_test是验证环境建立的唯一入口，只有通过它，才能正常运转UVM的phase机制。
3. 在一个顶层test中可以例化多个组件，譬如uvm_env或者uvm_agent，而在仿真时通过uvm_test可以实现验证环境的运转。
4. 推荐在uvm_test中只例化一个顶层uvm_env，这便于提供一个唯一环境节点以形成树状的拓扑结构，而这种树状环境结构也会对应着一种树状配置结构。