In reply to verif_learner:
I know you will ask this question finally. One suggestion, if you can’t find all the answers from user guide etc. document, looking at UVM library code comments may be very helpful for clarification.
Regarding to the uvm_config_db setting precedence, the uvm_config_db.svh comments provide a comprehensive description as below.
in uvm_config_db.svh
// function: set
//
// Create a new or update an existing configuration setting for
// ~field_name~ in ~inst_name~ from ~cntxt~.
// The setting is made at ~cntxt~, with the full scope of the set
// being {~cntxt~,“.”,~inst_name~}. If ~cntxt~ is ~null~ then ~inst_name~
// provides the complete scope information of the setting.
// ~field_name~ is the target field. Both ~inst_name~ and ~field_name~
// may be glob style or regular expression style expressions.
//
// If a setting is made at build time, the ~cntxt~ hierarchy is
// used to determine the setting’s precedence in the database.
// Settings from hierarchically higher levels have higher
// precedence. Settings from the same level of hierarchy have
// a last setting wins semantic. A precedence setting of
// <uvm_resource_base::default_precedence> is used for uvm_top, and
// each hierarchical level below the top is decremented by 1.
//
// After build time, all settings use the default precedence and thus
// have a last wins semantic. So, if at run time, a low level
// component makes a runtime setting of some field, that setting
// will have precedence over a setting from the test level that was
// made earlier in the simulation.
//