Config_db :: set Precedence from initial blocks at Time : 0

UVM
,
1

Hi All ,
I have the following scenario :

  • An interface instantiated in a CSR module ( only for UVM Verification simulations ) sets a parameter via uvm_config_db via an initial block at Time 0 . The CSR module is an IP at a lower level in a SOC chip top DUT .
  • The parameter is fetched ( via uvm_config_db :: get ) by a RAL file via reg_block’s build() . The build() for the root block is called in Env’s build_phase() .

Now the requirement is to override the parameter via top_tb via uvm_config_db :: set from an initial block ( different than the one which calls run_test ) .

Since both set are essentially done at Time 0 from a static entity ( prior to phasing ) , is there a precedence between the two settings ?

In the top_tb I tried setting it after using #0; delay and I observe it does override the parameter set from the interface .

Does the compilation order have an impact on the uvm_config_db :: set precedence ? As in latter compiled files would set it later giving a last write wins

2

In reply to MICRO_91:

The build_phase of a uvm_component does not start executing until at least one #0 delay. That number has been increasing every release (UVM 1.1d it was 5 #0’s, UVM 1.2 it was 8 #0’s, 1800.2-2017 it was over 10 #0’s). That’s a perfect example of why it is so bad to be using #0’s to force ordering within a time-step.

uvm_config_db uses the component context argument through the end of the build_phase to determine precedence. Higher levels have higher precedence, and a null context set from an initial block has the top-level context.

3

In reply to dave_59:

Higher levels have higher precedence, and a null context set from an initial block has the top-level context.

So set from an initial block ( using null context ) would take precedence over setting from Test component’s build_phase using ’ this ’ as context.
Hence in the above case the setting from the 2 initial blocks is equivalent to uvm_root context .

Combining it with :

Settings from the same level of hierarchy have a last setting wins semantic.

The latter set from the initial block ( using null context ) would certainly take precedence in the above case

As you mentioned the number of delays of #0 vary based on UVM version , so a better solution would be ::


  //  From  Test's  build_phase()  ::
 uvm_config_db #( <parameter> ) :: set( null , "<Hierarchy>" , "<Some_String>" , <Overridden_Value> ) ;
  //  String  arguments ' inst_name ' and ' field_name '  must  match  that  of  initial  block  setting

This would override the setting from initial block using null context since :

Settings from the same level of hierarchy have a last setting wins semantic.