Difficulty: Hard · Puzzle 6 of 6 · Topic: Factory and config_db
UVM 1.2. `my_drv #(W)` is registered with `uvm_component_param_utils`. The test overrides `my_drv#(8)` with `my_err_drv#(8)` by type. The env creates one `my_drv#(8)` and one `my_drv#(16)`. Which drivers become error drivers? Would `set_type_override("my_drv", "my_err_drv")` by string do the same?
class my_drv #(int W = 8) extends uvm_driver #(bus_item);
`uvm_component_param_utils(my_drv #(W))
function new(string name, uvm_component parent); super.new(name, parent); endfunction
endclass
class my_err_drv #(int W = 8) extends my_drv #(W);
`uvm_component_param_utils(my_err_drv #(W))
function new(string name, uvm_component parent); super.new(name, parent); endfunction
endclass
// test build_phase
set_type_override_by_type(my_drv#(8)::get_type(), my_err_drv#(8)::get_type());
// env build_phase
d8 = my_drv#(8)::type_id::create("d8", this);
d16 = my_drv#(16)::type_id::create("d16", this);Each specialization is its own type with its own factory wrapper. And what name does `uvm_component_param_utils` register?
1) my_drv#(8) and my_drv#(16) are different types with different registry wrappers; an override is keyed by the wrapper of the original type.
2) The by-type override applies to creates of `my_drv#(8)` only: d8 becomes a my_err_drv#(8), d16 stays a plain my_drv#(16).
3) The by-name form does not help: the param macro registers the wrapper without a usable type name, so a string such as "my_drv" is not a name of any registered specialization and nothing is overridden.
4) To override every width, either write one override per specialization, or put the behaviour in a non-parameterised base and override that, or use a mixin. (The override type must also be derived from the original type, as my_err_drv#(8) is from my_drv#(8).)Answer: Only d8 (the #(8) specialization) becomes an error driver; d16 is unaffected. The string-based override does not target a parameterized specialization.
Not run here: The UVM library is not installed here, so this cannot be executed; factory registration of parameterised classes is UVM library behaviour; the claim about name registration of uvm_component_param_utils is the least certain part.. The answer follows the language rules and the solution steps above.
Overriding `my_drv#(8)` is not overriding 'my_drv': every specialization needs its own override, and name-based overrides can not address them at all.
Why does a hierarchy of parameterised drivers usually get a non-parameterised abstract base class? Model answer: the base gives a single type to override, to hold handles in, and to `$cast` to, independent of W; the parameterised classes then only specialise widths and the factory/override logic works at the base level.