Ordering of initial block doing config_db set and build phase get

UVM
, ,
1

Hi,

I have an interface set() to config_db inside an initial block of a module instantiated inside top module. I understand that run_test() from an initial block of top module kicks off the UVM phases. My config_db get() for the interface handle is in the build phase of the env class.
1.Is there an ordering requirement between initial block and time-0 phases mandated by UVM?
2.If no, how can I make sure the ordering between config_db set and get is maintained in such a case?

2

In reply to rishikpillai90:

All initial blocks in all modules and interfaces get started at time 0 in an indeterminate order. However when you call run_test() the UVM forks of the phases of the testbench as separate processes in a way that guarantees that all the other intial blocks at time 0 start executing first.

3

Thanks for replying. I put displays and verified your statement. As you said, initial block(config_db set()) is executed before build phase (config_db get()). But somehow, get() is not receiving the interface handle.

Set code inside module:


apss_tb_mhm_if grouped_signals();
initial begin
uvm_config_db#(virtual apss_tb_mhm_if)::set(uvm_root::get(), "uvm_test_top.m_env_h*", "apss_tb_mhm_vif", grouped_signals);

end

Get code inside env build phase:

if(!uvm_config_db#(virtual apss_tb_mhm_if)::get(uvm_root::get(),"*","apss_tb_mhm_vif",grouped_sig))
 begin
  `uvm_info(get_type_name(),"DID NOT GET THE INTF", UVM_NONE);
      
  end else begin
  `uvm_info(get_type_name(),"GOT THE INTF", UVM_NONE);
end

This is printing

“DID NOT GET THE INTF”

The interface used here is hierarchical (there are other interface instances inside aforementioned interface). I hope it doesn’t have anything to do with this problem.

Else if that’s indeed the problem, what are the options available : should I be setting and getting each instances of interfaces separately?

Even if I manage to get the outermost interface handle in env, can my agents(drivers) use the inner interfaces like this?:

grouped_sig.inner_intf0.signal0

Sorry that the doubts deviated from initial post. I started this exercise to try out hierarchical interface access inside env, but stuck with this config_db issue. If you can already point out limitations, I might as well be exploring some other ways of doing this.

4

In reply to rishikpillai90:

Use


uvm_config_db#(virtual apss_tb_mhm_if)::set(null, "uvm_test_top.m_env_h*", "apss_tb_mhm_vif", grouped_signals);


uvm_config_db#(virtual apss_tb_mhm_if)::get(this,"","apss_tb_mhm_vif",grouped_sig

If that doesn’t work, check the path name printed by the error message to see if it matches what you are expecting it to be.

5

In reply to dave_59:

This worked! Thanks a lot. And simulator did not complain about my

grouped_sig.inner_intf0.signal0

usage. I have to check in waves to see if the pin got indeed driven, but I guess this means that we can access the inner interfaces without having to declare a virtual interface for them in TB. SV creates the child handle for us (maybe?).