Can you explain the difference between uvm_resource_db and uvm_config_db in the context of the Universal Verification Methodology (UVM)? Specifically, how does uvm_config_db’s behavior change depending on the phase of the simulation, and what is meant by “parent wins” and “last write wins” in this context? Please provide an example to illustrate these concepts.
Config_db & Resource_db both are different based on features and usability.
- Resource_db designed for managing design environment, In other word made for configuring DUTs.
Typically used for configuring/parameterizing the DUT at run-time.
Set : static function void set(input string scope, input string name,
T val, input uvm_object accessor = null);
Get :
a. Get_by_type :
static function rsrc_t get_by_type(string scope);
return rsrc_t::get_by_type(scope, rsrc_t::get_type());
endfunction
b. Get-by_name
tatic function rsrc_t get_by_name(string scope,
string name,
bit rpterr=1);
- Config_db designed for verification environment.Helps to configure and manage in the build_phase and elaboration phase.But config_db extends from resource_db -
class uvm_config_db#(type T=int) extends uvm_resource_db#(T);
Set : static function void set(uvm_component cntxt,
string inst_name,
string field_name,
T value);
Get : static function bit get(uvm_component cntxt,
string inst_name,
string field_name,
inout T value);
Keep it in mind:
If you use resource_db in verification environment that not design for that, sometimes that codes to less clear and harder to maintain.
can anyone explain how does uvm resource db and uvm_config_db’s behavior change depending on the phase of the simulation, and what is meant by “parent wins” and “last write wins” in this context?
In reply to harsh7112001:
what Amir is saying is not really true.
uvm_resource_db provides the base mechanism to pass objects through an object hierarchy.
uvm_config_db is like a shell pu around the uvm_resource_db to make this base mechanism more flexible.
The recommendation is to employ the uvm_config_db and not te uvm_resource_db.
The best way to understand the behavior is to make your own example.