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优先的原则进行。
