uvm_config_db源代码分析

伪代码参考链接：https://www.processon.com/view/link/622af92e1efad407e98a6fca

config_db机制是UVM中在不同的component之间实现资源共享的机制，它避免了全局变量的弊端。
通篇源代码看下来，其实config_db机制也是利用了一个全局的大池子（uvm_resource_pool）来存放资源，然后进行存取。

• 资源存放在什么地方：uvm_resource_pool
• 资源以什么形式存放：uvm_resource#(type T)
• 资源是如何存取：uvm_resource_db#(type T)

uvm_resource#(T)

• uvm_resource_pool具有全局唯一性，其大部分工作都是通过uvm_resource_pool来做的。

uvm_reousece_pool

• rtab/ttab是联合数组，索引的类型分别是string（name）和uvm_reousece_base（type）,内容为uvm_queue#(uvm_resource_base)的队列，这个是两个全局存在的，用于存储set进来的resource，和get查找resource的地方。
• get()表明是全局唯一性。

• 其实就是将set的内容按照name/type进行存放在globle的rtab和ttab中去。

• 其实一些相关的函数set_override/set_name_override/set_type_override都是set不同参数的调用。

• set_priority_name是在相同的cntxt以及inst_name多次set的时候，后一次set会将前一次set的内容覆盖掉。这也就是所谓的时间优先的原则。

uvm_resource_db#(T)

• 利用uvm_reosurce的write和uvm_resource_pool的set实现资源的写入。
• write_by_name/write_by_type并不会更新资源池的东西，只会改变对应的值。

• get_by_name()/get_by_type():在uvm_resource_pool对应的资源赤字里面按照name/type进行查找。

在真正的项目实战中，其实uvm_resource_db并不会直接使用，我们直接使用的是在其基础上扩展来的uvm_config_db。

uvm_config_db

• uvm_config_db扩展自uvm_resource_db
• m_rsrc是一个关联数组，索引是uvm_component，内容是uvm_pool#(string,uvm_resource#(T))

• 其实跟uvm_resource_db是一样的。
• pool.add是用来判断同一个component的path+inst_name是否有多次覆盖。

• 同一个uvm_component，并且path+inst_name相同的时候，set_priority_name()，后一次set的值，要把前一次的给覆盖掉。

• get函数就更简单了，就是去uvm_resource_pool的之子里面按照path+inst_name+filed_name进行查找。
• 不同的uvm_component对应相同的path+inst_name的时候，应该按照层级precedence优先的原则进行。