Difficulty: Easy · Puzzle 6 of 6 · Topic: Factory Override Puzzles
An object is created before override registration and another after. Which object types result and why?
class base_item extends uvm_object;
`uvm_object_utils(base_item)
function new(string name="base_item"); super.new(name); endfunction
endclass
class tuned_item extends base_item;
`uvm_object_utils(tuned_item)
function new(string name="tuned_item"); super.new(name); endfunction
endclass
initial begin
base_item pre, post;
pre = base_item::type_id::create("pre");
base_item::type_id::set_type_override(tuned_item::get_type());
post = base_item::type_id::create("post");
$display("pre=%s post=%s", pre.get_type_name(), post.get_type_name());
endFactory resolves override at each create call; existing objects are already constructed.
1) `pre` is created before override table is updated, so it is `base_item`.
2) After `set_type_override`, subsequent create requests for base map to `tuned_item`.
3) `post` becomes `tuned_item`; overrides are not retroactive.Answer: Output is `pre=base_item post=tuned_item`; factory overrides affect future creates only.
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): an override affects only later create calls.
Teams sometimes expect override calls to mutate already-constructed object types. `pre` stays a `base_item` forever, so the order of override and create is what the test depends on.
How can testbench architecture delay creation to keep overrides deterministic? Model answer: register all overrides in the test's `build_phase` before `super.build_phase` creates the env, build the environment only through `type_id::create` in `build_phase`, and create sequence items lazily at use time (inside the sequence body) rather than in constructors or static initializers.
It prints pre equals base_item and post equals tuned_item. Overrides affect only creates that happen after they are set, and they are not retroactive. The pre object was created before the override, so it stays base_item. The trap is expecting the override to change existing objects, so I would check the ordering of set and create calls.