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.
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?
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.
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.
//
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?
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.
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.
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.
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.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.
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.
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?
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!
In reply to germanbravolopez:
The value to the right of ‘+:’ needs to be a constant. In your case, it is a variable.
Typically you would use a static value or a parameter.
In reply to cgales:
Yes, that’s it. I thought to define “RDW” as a parameter, but the problem is that I cannot change the value of a parameter with the function “uvm_config_db()”.
I also thought to define my scoreboard parametric, like this:
class my_scoreboard #(RDW = 8) extends uvm_scoreboard;
But now I am force to define as parametric the environment and the test also. And to call the test from the “test_top” do I need to do something similar to the following code?
initial begin
run_test("base_test(RDW)");
end
I don’t know what to do…
In reply to germanbravolopez:
I think it is a good idea to revisit a bit your approach to the problem you need to solve, most of the times what may seem a parameter, it is not and can be passed using a config object. Now if you really need to pass the parameter from command line normally simulators provide some switches to do so (not the purpose nor this forum), also you could selectively add to the compile list a file or package with the parameters you need and import that package where needed.
Also with the first code shown you could assign in a for loop the bits you want.
task write();
for (int i=0; i<RDW; i++)begin
data_b[i] = data_a[i+RDW]; //Or whatever logic meet your requirements
end
endtask
Probably somebody else will provide you a more elaborate solution.
Anyways hope this helps.
-R
PS: I think it would be better to ask a new question as your problem is a bit different from what the original thread was about.
In reply to germanbravolopez:
Create a package of design parameters, and use that package to specialize your scoreboard in the environment:
typedef my_scoreboard#(param_pkg::RDW) my_scoreboard_t;
In reply to cgales:
I can edit this pkg from command line each time that I want to perform a simulation with different values in the parameters, but in that case I need to recompile with this new values, right?
In reply to germanbravolopez:
No you do not need recompile your code. You are passing the actual parameter values as switches of the simulator command to your code.