uvm_config_db(#T)::set() and get() question

I saw a test generating a config object and publish it using config_db like below in the test build phase,

    uvm_config_db#(dia_ahb_irq_handler_env_config)::set(null, "", "m_config", m_config);

in the env build phase, this object can be obtained by below get,the env is created in the test.

 if(!uvm_config_db#(dia_ahb_irq_handler_env_config)::get(this, "", "m_config", m_config)) begin

The test is passing, my question is there is no wildcard in either cntxt or inst_name, how does the get obtain the object? Is the “null” equivalent to “*”?

I also tried to change “null” to “this”, the test failed.

Regards,
Wenkai

In reply to wenkai.tang:

The first Argument in the uvm_config_db command is indicating if the path which follows is considered as an absolute path (null) or a relative path (this).

In reply to chr_sue:
Thank you for pointing out. My question is why null seems behavior like setting to every hierarchy? like * in the inst_name?

In reply to wenkai.tang:
The first Argument in the uvm_config_db command is indicating if the path which follows is considered as an absolute path (null) or a relative path (this).

In reply to wenkai.tang:

No this is not true.
If you don’t want to restricht the usage of a value you are Setting you have to use as the first 2 Arguments either (null, “", or (this, "”. In a module only null is possible as the first Argument, because there is no parent.

In reply to chr_sue:

This is exactly my question. I don’t expect the config_db::get can obtain the object setting in the first config_db::set, but the simulation proves it, if I change “null” to “this”, this test failed.

In reply to wenkai.tang:

null means the absolute Path, starting with uvm_top. This is the correct behavior.

In reply to chr_sue:

My understanding is the setting is on uvm_top on m_config field, but get is on uvm_top.uvm_env on m_config field. The start search point is different.

In reply to wenkai.tang:

Note that

 uvm_config_db#(dia_ahb_irq_handler_env_config)::set(null, "", "m_config", m_config);

is equivalent to

 uvm_config_db#(dia_ahb_irq_handler_env_config)::set(null, "*", "m_config", m_config);

and from the top level test, is equivalent to

 uvm_config_db#(dia_ahb_irq_handler_env_config)::set(this, "*", "m_config", m_config);

In reply to dave_59:

Thank you very much, that explains my question and clarified my confusion :-)

In reply to wenkai.tang:

it’s strange that no error happens when you use null in the set statement. as far as I know, null stand for uvm_top, which is a object of uvm_root class,it’s usually the top module in testbench. so I thought the set statement should write as following:

uvm_config_db #(dia_ahb_irq_handler_env_config)::set(this, "env", "m_config", m_config);

or

uvm_config_db #(dia_ahb_irq_handler_env_config)::set(this, "*", "m_config", m_config);

so would you mind share the top module file and the test case file, this set statement concerned code would be sufficient.

In reply to EnRoute_zt:
If you are using null as the firt argument in the config_db command it is indicating the hierarchical pth in the second argument has to be considered as an absolute path.
In the toplevel module the first argument can never be this, because there is no parent. There it has to be always null.

In reply to chr_sue:

In reply to EnRoute_zt:
If you are using null as the firt argument in the config_db command it is indicating the hierarchical pth in the second argument has to be considered as an absolute path.
In the toplevel module the first argument can never be this, because there is no parent. There it has to be always null.

I agree that if I use null as the first argument of `uvm_config_db ::set(), the second one should be an absolute path of the destination or using wildcard.
But in the toplevel,we can use both this or null as the first argument, or this.uvm_test_top(haven’t check if it work). In the top level, this equals null, means uvm_top.

I have learned UVM for only several months, so not quite sure about what I said.

In reply to EnRoute_zt:
calling set on the uvm_config_db in the toplevel module does not allow ‘this’ as the first argument. ‘this’ relates to the current component and this is a module and not a clas-based uvm_component.

In reply to chr_sue:

you’re right, this is a pointer, and the toplevel is not a class. thanks

In reply to chr_sue:

Hi ,
And what if we use uvm_test_top in place of “” (accesible location)in config_db

In reply to ramankaur09:

Do you mean for the get?
if you use

uvm_config_db #(dia_ahb_irq_handler_env_config)::get(this, "uvm_test_top", "m_config", m_config);

this means you are using a relative path and you are retrieving the object to uvm_test_top which is the instance of your test. But you might want to have the object in the component/instance where you are executing the get.

In reply to chr_sue:

Hi ,
Thank you for response.
Yes got it thnks,
I meant for set , setting the scope to uvm_test_top , which means scope till the test and lower components not accesing it as you explained,ryt
and for get : its going to get for test only as per scope .

Thanks

In reply to ramankaur09:

Using

uvm_config_db #(dia_ahb_irq_handler_env_config)::set(this, "uvm_test_top", "m_config", m_config);

means your set command is restricted to the test class/instance. If it should be also for the components below you have to write

uvm_config_db #(dia_ahb_irq_handler_env_config)::get(this, "uvm_test_top*", "m_config", m_config);