IC验证学霸笔记4——UVM--uvm_scoreboard

1 uvm_scoreboard

• 从名字来看，uvm_scoreboard担任着同SV中checker一样的功能，即进行数据比对和报告。
• uvm_scoreboard本身也没有添加额外的成员变量和方法，但UVM建议用户将自定义的scoreboard类继承于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是一个参数类，并且它有两个端口before_export和after_export分别从DUT的输入端monitor和输出端monitor获取观测到的数据事务。这些数据事务是将多个时钟周期内的数据整合为更高抽象级的数据对象，而且要求前后端监测到数据事务类型应该相同。
• uvm_algorithm_comparator也是一个参数类，它的参数数目要更多，这是为了贴合在更多实际场景中，DUT的输入端监测数据格式不同于输出端数据格式，因此typeBEFORE与typeAFTER两个事务类可以不相同，同时用户也应该提供用来将BEFORE类转换为AFTER类的转换类type TRANSFORMER。

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

2 uvm_env

从环境层次结构而言，uvm_env可能包含多个uvm_agent和其它component。

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

下面的验证结构中，就定义了一个高层的环境，它里面包含 sub_env、agent、scoreboard。

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

3 uvm_test

uvm_test类本身没有什么新成员，但是作为测试用例的代言人，它不但决定着环境的结构和连接关系，也决定着使用哪一个测试序列。
如果没有这个代言人，整个环境都无从建立，所以uvm_test是验证环境的唯一入口，只有通过它才能正常运转UVM的phase机制。

我们从下面的示例看到，在一个顶层test中可以例化多个组件，譬如uvm_env或者uvm_agent, 而在仿真时通过uvm_test可以实现验证环境的运转。

我们推荐在uvm_test中只例化一个顶层uvm_env, 这便于提供一个唯一环境节点以形成树状的拓扑结构，而这种树状环境结构也会对应着一种树状配置结构。