Difficulty: Medium · Puzzle 2 of 6 · Topic: Factory Override Puzzles
Two type overrides are installed on different original types so that A maps to B and B maps to C. Predict the type of each created object.
class item_a extends uvm_object;
`uvm_object_utils(item_a)
function new(string name="item_a"); super.new(name); endfunction
endclass
class item_b extends item_a;
`uvm_object_utils(item_b)
function new(string name="item_b"); super.new(name); endfunction
endclass
class item_c extends item_b;
`uvm_object_utils(item_c)
function new(string name="item_c"); super.new(name); endfunction
endclass
initial begin
item_a x;
item_b y;
item_a::type_id::set_type_override(item_b::get_type());
item_b::type_id::set_type_override(item_c::get_type());
x = item_a::type_id::create("x");
y = item_b::type_id::create("y");
$display("x=%s y=%s", x.get_type_name(), y.get_type_name());
endAfter the factory applies one override, it looks the result up again.
1) `y` asks for `item_b`; the override B->C applies, so `y` is an `item_c`.
2) `x` asks for `item_a`; override A->B applies, and the factory then checks the override table again for `item_b`, finds B->C, and ends at `item_c`.
3) Both objects are `item_c`: `x=item_c y=item_c`. The handle types still work because `item_c` extends `item_b` extends `item_a`.Answer: Prints `x=item_c y=item_c`: the factory resolves override chains, so A->B->C yields `item_c` for both requests.
Checked by running the code in Verilator 5; the printed output supports the answer above. A hand-written model of the documented UVM 1.2 factory rule (not the UVM library): the factory re-resolves the replacement, so A to B to C ends at C.
Overrides are not one-hop lookups: an override installed for the replacement type applies to requests for the original type too, so adding an unrelated override for B in another file silently changes what A produces.
What breaks if the chain is closed into a loop, A->B and B->A? Model answer: nothing legal can be resolved; the factory has to stop the recursion, and UVM reports an error rather than looping. Treat a cycle as a testbench bug and use `factory.print()` to inspect the table. (UVM 1.2 documented chaining; the cycle handling rests on the source, not a run.)
Both x and y are item_c. The factory resolves override chains, so A goes to B and then B goes to C. The trap is stopping after the first hop. The handle types still work because item_c extends item_b, which extends item_a, and I would confirm with a factory print.