Question regarding UVM_config_db::set and scoping information

Hello,
UVM reference 1.2 states following in section on configuration and resource classes- page 174:

“Each resource has a set of scopes over which it is visible. The set of scopes is
represented as a regular expression. When a resource is looked up the scope of the
entity doing the looking up is supplied to the lookup function. This is called the current
scope. If the current scope is in the set of scopes over which a resource is visible then
the resource can be retuned in the lookup.”

With reference to above, i have following questions:

1.How is the scope information derived from uvm_config_db::set call. For example in following call to uvm_config_db, what will be the scope information?
uvm_config_db #( spi_env_config )::set( this ,"", “spi_env_config”, m_env_cfg);*
2. During uvm_config_db::get call, how is the current scope information derived and compared with set of scopes stored with resource container?

thanks,
-sunil

In reply to puranik.sunil@tcs.com:

The “scope” is essentially a string concatenation using the first two arguments of get/set; cntxt and inst_name

{ get_fullname (cntx), ".", inst_name }

The cntxt argument (context - why they needed to save 2 vowel characters is perplexing IMHO) represents the relative uvm_component path. When it is null, the inst_name becomes an absolute.

Thanks Dave for immediate reply. I have a related question on configuration data base:

  1. The uvm_resource_pool which is a singleton resource data base stores two associative arrays, Type map and name map. Name map array uses field name as key and points to queue of resources having same name but different types. Type map entry points to queue of resources having same type. Now the uvm_config_db::get can use the name map for look up with field name as key and compare all the entries in queue for matching scope and type as given in uvm_config_db::get function. What is the necessity of the type map array in that case?

  2. If same field is configured from different levels of hierarchy, the scoping information context.instance will be same for all the entries. Is this a correct statement?
    In that case, are these entries stored in a queue (with configuration done from higher level having more priority than the configuration done from lower level?

thanks,
regards,
-sunil

In reply to puranik.sunil@tcs.com:

I’ve never gotten into this much detail, and don’t think anyone should.

See What is the difference between uvm_config_db and uvm_resource_db ? | Verification Academy