Override Timing Relative to create Calls

Puzzle

Difficulty: Hard · Puzzle 6 of 6 · Topic: Factory Override Puzzles

An object is created before override registration and another after. Which object types result and why?

Code

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());
end

Hint

Factory resolves override at each create call; existing objects are already constructed.

Step-by-step solution

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

Answer: Output is `pre=base_item post=tuned_item`; factory overrides affect future creates only.

Why candidates get it wrong

Teams sometimes expect override calls to mutate already-constructed object types.

Interviewer follow-up

How can testbench architecture delay creation to keep overrides deterministic?

Related topics

• Back to Factory Override Puzzles

• OOP & Testbench Puzzles section