Config_db - parameters for set/get method

UVM
,
1

I have a few questions related to config_db working and also parameters related to set/get function.

  1. what is the difference between uvm_component context parameter which is the 1st parameter for the set function and string instance name?
  2. users of get method need to know the exact field name they are looking for? are there use-cases where users may not know the exact name or know the name at all?
  3. would there be any issue or changes needed when an unit level testbench is instantiated in a system level testbench?
    In this case, any special care has to be taken at the system level testbench to make sure that re-use is possible without touching unit level env?
2

In reply to verif_learner:


  //class uvm_config_db ....
  static function void set(
    uvm_component cntxt,
    string inst_name,
    string field_name,
    T value
  )

Here is my two cents:

  1. uvm_config_db::set function is to create a new or an update of an existing configuration setting for field_name in inst_name from cntxt. The full scope of set is the concatenation of cntxt and inst_name {cntxt,”.”,~inst_name~}. If cntxt is null then inst_name provides the complete scope information of the setting.
  2. I would think this in an opposite way - the user of uvm_config_db::set() should know exactly what hierarchy and field name to configure. The lower layer component expects field_name to be configured. If configuration fails, it can report error or fatal message. The upper layer component should provide matched scope and field_name setting to satisfy it.
  3. When reuse from unit level to system level, may or may not need to take care of scope change {cntxt,”.”,~inst_name~} of uvm_config_db::set().
3

In reply to Lina.Lin:

Thanks for your help.

4

In reply to verif_learner:

Hi Lina Lin,

Without going into set syntax, I assume, when using set, one can specify the actual instance that gets the configuration value or any instance with a given name.

For example, if I have 2 instances as below:
top.module_a.instance_a
top.module_b.instance_a

Then I can specify set only for top.module_a.instance_a or
I can specify set for instance_a in which case both top.module_a.instance_a and top.module_b.instance_a would get the value.

Is my understanding correct?

5

In reply to verif_learner:

Yes you Can restrict the access through the get for a certain instance.

6

In reply to verif_learner:

Configure successfully only when the full scope matches between get() and set() functioins. full scope is {cnxt, “.”,”inst_name,“.”, field_name}


  //in instance_a, using "fld_name" to configure "my_val" variable value
  int my_val;
  uvm_config_db#(int)::get(this,"","fld_name", my_val);

Configure module_a and module_b with difference value.


  uvm_config_db#(int)::set("", "top.module_a.instance_a", "fld_name", a_val);
  uvm_config_db#(int)::set("", "top.module_b.instance_a", "fld_name", b_val);

Configure both module_a and module_b with same value


  uvm_config_db#(int)::set("", “top.module_*.instance_a”, "fld_name", val);
7

In reply to Lina.Lin:

Thank you, Lina Lin. Appreciate your help.

I have one more question. I can understand context and instance name for set but what about get. What is the purpose of context and instance name in this case?

8

In reply to verif_learner:

uvm_config_db::get() will get the value for field_name in inst_name, using component cntxt as the starting search point.

In the example below， cnxt is this and inst_name is empty “”， this keyword refers to the component’s current instance. so get（）will loop up fld_name setting by using the component’s current instance as the starting point. If fld_name setting is found, get its setting to my_val.


uvm_config_db#(int)::get(this,"","fld_name", my_val);

In the example below, get() will search fld_name setting by using top.module_a.instance_a as the starting point.


uvm_config_db#(int)::get("top",".module_a.instance_a","fld_name", my_val);
9

In reply to Lina.Lin:

This is so confusing to me. Looks like I have to spend some time going through configuration mechanism.

Thanks a lot. You have been very patient.

10

In reply to verif_learner:

Lina Lin and others,

Thanks a lot. I think I understand basics now. I have to apply this in the project and see.
So, hopefully one last question.

What happens when same field is available at 2 hierarchies when get is called.
Would the lowest in the scope be available or the variable higher in the scope?

11

In reply to verif_learner:

If you are setting values from different levels using the same Name, the highest level (which is nearest to the root) wins.

12

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.
//

13

In reply to Lina.Lin:

Thanks. This helps.

14

One more question on this topic.

If config item is an object then getting once is sufficient as objects are passed by reference and once the consumer entity gets it once, any change in the value by producer will automatically reflect in the consumer. Right?

15

In reply to verif_learner:

This is not restricted to objects (Class-based variables). This is also valid for other variables. See the virtual interface as an example.

16

In reply to Lina.Lin:

In reply to verif_learner:
uvm_config_db::get() will get the value for field_name in inst_name, using component cntxt as the starting search point.
In the example below， cnxt is this and inst_name is empty “”， this keyword refers to the component’s current instance. so get（）will loop up fld_name setting by using the component’s current instance as the starting point. If fld_name setting is found, get its setting to my_val.


uvm_config_db#(int)::get(this,"","fld_name", my_val);

In the example below, get() will search fld_name setting by using top.module_a.instance_a as the starting point.


uvm_config_db#(int)::get("top",".module_a.instance_a","fld_name", my_val);

Hi Lina Lin,

What is the difference between the following 3 statements:

uvm_config_db#(int)::set("", "top.module_a.instance_a", "fld_name", a_val);



uvm_config_db#(int)::set("top", ".module_a.instance_a", "fld_name", a_val);


uvm_config_db#(int)::set("top.module_a", ".instance_a", "fld_name", a_val);

Also, if I have set as follows:

uvm_config_db#(int)::set("top", "", "fld_name", a_val);

and I using get as follows as top.instance_a:

uvm_config_db#(int)::get("this","","fld_name", my_val);

will the get be successful?
if this is not successful, how can a lower component get value set at the upper hierarchy level such as above?

After reading multiple articles on this topic, I somehow get a feeling that match is just based on field name alone. Where context and instance name help is, to return appropriate value when multiple entries with the same name are present. I am not sure if I am going in the correct direction.

17

In reply to verif_learner:

Your get will not be successful, because you are restricting the hierarchy by the set command.
The 3 set commands have the same result. Only a component in the hierachy top.module_a.instance_a can retrieve a value.
In your get you are considering only the hierarchy top.instance_a which does not meet the hierarchy from the set which is top.module_a.instance_a.

18

In reply to verif_learner:

There is a mistake here. The first argument to the set/get methods is a context handle. That is an instance of a uvm_component. These methods take the first two arguments and concatenates them together [sv]{ arg1.get_full_name() , arg2 }

. 

Normally arg1 is **this** or **null** depending if you want to specify a relative or absolute path. Only the result of the concatenation matters, not how the original two strings piece together.
19

In reply to dave_59:

In reply to verif_learner:
Only the result of the concatenation matters, not how the original two strings piece together.

Thanks. Unfortunately, none of the UVM documentation, including user guide or reference manual, care to explain this fact.

In fact I spent days understanding the importance of context & instance and got a good understanding only after going through the following tutorial:
http://cluelogic.com/2013/12/uvm-tutorial-for-candy-lovers-configuration-database-revisited/

In fact there are some many scenarios and pitalls while using config_db and most of the documents make customary explanation and move on.

20

In reply to verif_learner:

You cannot learn UVM by reading the reference manual. Any basic UVM course explains the context of the uvm_config_db.