Config_db - parameters for set/get method

UVM
,
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.

21

In reply to dave_59:

Sorry. I disagree. For me, UVM reference manual is closest to language LRM that we have. If that does not explain clearly the meaning of parameters that designers of UVM defined, what else will?

22

In reply to dave_59:

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.



Hi Dave,

How can I solve the problem ***"Range width must be constant expression"*** in an assignment like the following, when I get the value of this constant from database?:

``` verilog

data_a = data_b [RDW*i +: RDW];

To make more clear:
In my top test I have a parameter that I receive as a generic from cmd line when I simulate the test:


module test_top #(RDW= 16);
    initial begin
        uvm_config_db #(int)::set(null, "uvm_test_top.*", "RDW", RDW);
    end
endmodule

Then in my scoreboard I have:


int RDW;
function void build_phase (uvm_phase phase);
   void'(uvm_config_db #(int)::get(this, "*", "RDW", RDW));
endfunction

task write ();
   data_a = data_b [RDW*i +: RDW];
endtask

Thank you very much!