Difficulty: Medium · Puzzle 3 of 6 · Topic: Factory Override Puzzles
Two type overrides are applied for the same base. Predict behavior with `replace=0` and `replace=1`.
class base_item extends uvm_object;
`uvm_object_utils(base_item)
function new(string name="base_item"); super.new(name); endfunction
endclass
class item_a extends base_item;
`uvm_object_utils(item_a)
function new(string name="item_a"); super.new(name); endfunction
endclass
class item_b extends base_item;
`uvm_object_utils(item_b)
function new(string name="item_b"); super.new(name); endfunction
endclass
initial begin
base_item::type_id::set_type_override(item_a::get_type(), 0);
base_item::type_id::set_type_override(item_b::get_type(), 0);
$display("first=%s", base_item::type_id::create("x").get_type_name());
base_item::type_id::set_type_override(item_b::get_type(), 1);
$display("second=%s", base_item::type_id::create("y").get_type_name());
endSecond call with `replace=0` does not overwrite existing mapping.
1) First mapping base->item_a is installed.
2) Second call with `replace=0` keeps existing mapping unchanged.
3) `first` therefore prints `item_a`.
4) Third call with `replace=1` updates mapping to item_b, so `second` prints `item_b`.Answer: Output is `first=item_a` then `second=item_b`.
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): replace=0 keeps the first mapping, replace=1 overwrites it.
`replace=0` on a second override of the same original type is ignored (UVM warns), so the latest call does not always win; only `replace=1` changes the mapping.
Why can hidden replace defaults create flaky tests across reused env code? Model answer: the default `replace` is 1, so any later `set_type_override` (for example in a reused base test or sequence library) silently replaces your earlier choice, while `replace=0` silently keeps the first one. Which one wins then depends on file and call order, which is why overrides belong in one place (the test) and are checked with `factory.print()`.
First is item_a and second is item_b. The second call with replace set to 0 keeps the existing mapping, so the first print still shows item_a. The later call with replace set to 1 updates the mapping, so the second print shows item_b. The trap is assuming the latest call always wins, so I would check the replace argument.