uvm_config_db::set for the same field more than once from a single component

[eyalbaram]

Hi,

I noticed a behavior which I didn't expect when trying to override a value set to field by a parent component (when the parent sets the resource more than once).

Can the described result below be explained?

from UVM1.1b class reference (uvm_component):

When a descendant component calls a get_config_* method, the inst_name and field_name provided in the get call are matched against all the configuration settings stored in the global table and then in each component in the parent hierarchy, top-down. Upon the first match, the value stored in the configuration setting is returned. Thus, precedence is global, following by the top-level component, and so on down to the descendent component's parent

.

in the example code below, an extension of parent_test class, parent_bp was used in order to override the value set to field "x" in grandchild component:

class grandchild_comp extends uvm_component;
    `uvm_component_utils(grandchild_comp)
    int x;
    function new(string name="", uvm_component parent=null); super.new(name, parent); endfunction 
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);
         get_config_int("x", x);
        $display("x ==> %0d",x);
    endfunction
endclass

class child_comp extends uvm_component;
    grandchild_comp grandchild;

    function new(string name="", uvm_component parent=null); super.new(name, parent); endfunction 
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);

        set_config_int("grandchild", "x", 3);
        grandchild = grandchild_comp::type_id::create("grandchild", this);
    endfunction
    `uvm_component_utils(child_comp)
endclass


class parent_test extends uvm_test;
    child_comp child;

    function new(string name="", uvm_component parent=null); super.new(name, parent); endfunction 
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);
        child = child_comp::type_id::create("child", this);
        set_config_int("child.*", "x", 4);
    endfunction

    `uvm_component_utils(parent_test)
endclass


class parent_bp extends parent_test;
    `uvm_component_utils(parent_bp);
    function new(string name="", uvm_component parent=null); super.new(name, parent); endfunction 
    function void build_phase(uvm_phase phase);
        super.build_phase(phase);
        set_config_int("child.*", "x", 5);

    endfunction

endclass

module top;
    initial run_test("parent_bp");
endmodule

according to the class reference (above), my expectation was that grandchild.x == 5 after grandchild's build_phase is done, but grandchild.x == 3.

Running trace I got this:

UVM_INFO uvm_resource_db.svh(129) @ 0: reporter [CFGDB/SET] Configuration 'uvm_test_top.child.*.x' (type logic signed[4095:0]) set by uvm_test_top = (uvm_bitstream_t) 100

UVM_INFO uvm_resource_db.svh(129) @ 0: reporter [CFGDB/SET] Configuration 'uvm_test_top.child.*.x' (type logic signed[4095:0]) set by uvm_test_top = (uvm_bitstream_t) 101

UVM_INFO uvm_resource_db.svh(129) @ 0: reporter [CFGDB/SET] Configuration 'uvm_test_top.child.grandchild.x' (type logic signed[4095:0]) set by uvm_test_top.child = (uvm_bitstream_t) 11

UVM_INFO uvm_resource_db.svh(129) @ 0: reporter [CFGDB/GET] Configuration 'uvm_test_top.child.grandchild.x' (type logic signed[4095:0]) read by uvm_test_top.child.grandchild = (uvm_bitstream_t) 11

Since uvm_test_top is the top-level component, I expected that "x" would get its value from it, but it got the value set by "child".

I traced the reason to the following code in uvm_config_db::set() :

if(curr_phase != null && curr_phase.get_name() == "build")
      r.precedence -= cntxt.get_depth();

Since both parent_bp::build_phase and parent_test::build_phase are called, the "child.*.x" resource's precedence is reduced twice, making get_config_int() retrieve the value of "grandchild.x" resource.

To override this issue the search priority had to be changed manually

[janick]

Looks odd to me. Filed http://www.eda.org/svdb/view.php?id=4315 so it can be examined by the TSC.