【UVM源码】UVM Config_db机制使用总结与源码解析

UVM Config_db机制介绍

UVM Config_db 机制引入的背景

在Systemverilog搭建的验证平台中，需要对各组件进行参数配置，但是配置各组件必须得在各组件实例化之后才能配置参数，例如test中必须得执行env = new();才能配置env.i_agt.drv.pen_num = 10;。再比如接口指针，需要就需要为每个组件设定设定set_interface();方法，非常繁琐。为解决此问题，UVM提出了解决办法，即UVM Config_db机制。

UVM提供的config_db机制可在组件实例化前就设定好配置信息，这样就可在tb的initial块中就进行设定了。真正将这些配置信息落实在各component，是在testbench运行过程build_phase中。

基本介绍

config_db的作用

     UVM提供了uvm_config_db配置类以及几种方便地变量设置方法来实现仿真的环境控制

uvm_config_db类的使用方式包括：

• 传递virtual interface 到环境中
• 设置单一变量值，例如int、string、enum等
• 传递配置对象(config object)到环境

使用方法

set与get函数的参数：
config_db机制用于在UVM验证平台间传递参数，set()是寄信，get()是收信

uvm_config_db#(T)::set(uvm_component cntxt, string inst_name, string field_name, T value);
uvm_config_db#(T)::get(uvm_component cntxt, string inst_name, string field_name, inout T value);

T：是传递信息的类型
cntxt：是一个uvm_component实例的指针，cntxt+inst_name组成目标路径
inst_name：是相对此实例的路径
field_name：变量名set和get的第三个参数必须一致
value：表示的就是要存放的数据本身了。它可以用某一个变量或者句柄来表示具体的数据对象，也可以是直接给一个常数。这里需要注意，value的数据类型就是前面已经配置的my_type类型，如果不一致会引入错误。

优缺点：

优点：
用户只需要按照set、get方法要求，就能基本上完成testbench中virtual interface传递；

缺点：
源代码复杂；

UVM Config_db机制使用示例：

仿真结果如下：

UVM Config_db使用高阶规则

Config_db资源优先级

当不得已需要在环境中的多个地方，对相同数据对象，通过config_db进行配置的时候，就需要关心到这些资源的优先级，即在get时实际上会get到哪一个值或句柄。在config_db这一层（指的是不深入到uvm_resource_db这一层实现上），大概有以下几点需要关注。

第一点是get的优先级。get的机制比较简单，根据cntxt，inst_name，filed_name来找到全局资源池中所有匹配到的资源，并构成资源数组，然后返回该资源数组中优先级最高的资源。这里的优先级（precedence）跟上面提到的name、type、scope和value一样，是每个资源对象拥有的属性。如果优先级一样，就返回排在资源数组最前面的资源！

第二点是非build_phase时的set。不在build_phase函数中set的资源，优先级是一样的（default_precedence），但后set的资源会排在资源数组的最前面！

第三点是build_phase时的set。在build_phase函数中set的资源，优先级会根据cntxt的级数降低（default_precedence - cntxt.get_depth()）。也就是理想使用情况下（这里的理想使用情况指的是在顶层时cntxt参数用null，在其他层cntxt参数用this的情况），越靠近顶层set的资源的优先级更高。

UVM Config_db 源码解析

（等待补齐）

---

本文仅用作学习总结，转载自以下，特此感谢！

SystemVerilog | UVM | Config_db机制基础