The UVM Primer -- Chapter 13 UVM Environments

The UVM Primer – Chapter 13 UVM Environments

• 前面两节介绍了使用factory机制创建顶层对象uvm_test,并在uvm_test中例化uvm_componnets;UVM会自动的调用uvm_components中的各个phase，并且自为每个componnet的run_phase开启独立的进程.这样的方式易于理解，却难以复用。
• 采用以上方式，每次定义新的uvm_test都需要声明对应类型的tester；每个uvm_test类都会例化所有的uvm_components;
• UVM通过uvm_env将测试平台的组件和行为分离，uvm_env专注于构造测试平台的框架。

13.1 Architecting Adaptable Code

• 对于tester而言，我们希望tester可以实现的功能：
  • random_tester：发送1000个随机operation with different oprands；
  • add_tester: 发送1000次add operation with different oprands；
    (1) 实现方式-A
    rando_tester和add_tester都分别扩展自uvm_component,每个tester都需要定义get_op,get_data,run_phase方法；无论是random operation还是add operation，在run_phase都以同样的方式送往DUT，这样run_phase就难以维护。一旦我们需要对run_phase做出修改，就需要同时修改各个tester中的run_phase函数。
    
    (2) 实现方式-B
    首先从uvm_component中扩展一个类，base_tester,在其中定义虚函数virtual get_op(),get_data()和非虚函数run_phase，在此类中定义run_phase的行为。random_tester和add_tester均扩展自base_tester,此时如果需要对run_phase中的行为进行修改，就只需要修改base_tester中的方法即可。(PS:为了防止声明base_tester的变量，导致仿真报错，可以将base_tester定义为虚类,将get_op和get_data定义为纯虚方法) 这样base_tester就变成了，我们可以使用的资源，便于扩展。
    
    (3) 实现方式-C
    将random_tester也变成可使用资源，继承关系：uvm_component -> base_tester -> random_tester -> add_tester; 因为get_data()在random_tester和add_tester中的机制是一致的，因此add_tester可以继承random_tester中的get_data函数，类似的mul_tester,xor_tester都可以扩展自random_tester,并且只需要重构get_op函数即可，其他功能可以通过继承获得。
    

13.2 Separating Structure from stimulus

• base_tester时测试平台架构中关键的一环，通过base_tester可以派生出一系列的tester，然后我么可以像前两节所述，在uvm_test中例化这些tester开始仿真，这样可以正常工作但是却不利于代码维护。
• 原因: testbench中的stimulus