Factory Over-ride question: set_type_override Vs set_inst_override

My router env has a background sequence “seq”, which has been defined to be of type router_base_seq.

From the test, i am trying to over-ride it to be of type router_012_seq.

Over-riding by type is working fine. However, override by instance name is not working.
I am calling the below after router_env has been created.

Case 1:  router_base_seq::type_id::set_type_override(router_012_seq::get_type());

Case 2: router_base_seq::type_id::set_inst_override(router_012_seq::get_type(), "router_env.seq");

Any idea on what is wrong with Case 2?

Thanks!

In reply to Coppola:
From cookbook:
Specific sequences can be overridden via their “path” in the UVM testbench component hierarchy. For
uvm_components, the path is defined as part of the build process via the name and parent arguments to the create
method. However, sequences are uvm_objects and only use a name argument in their constructor and are not linked
into the uvm_component hierarchy. The solution for creating a path for a sequence is to use two further arguments to
the create method. The third argument passed to the sequence can be populated by the results of a get_full_name()
call, or it can be any arbitrary string. The instance override then uses this string concatenated with the instance name
field of the sequence to recreate the “instance path” of the sequence. For obvious reasons this means that a sequence
instance override has to be pre-meditated as part of a sequences architecture.

In reply to Coppola:

My router env has a background sequence “seq”, which has been defined to be of type router_base_seq.
From the test, i am trying to over-ride it to be of type router_012_seq.
Over-riding by type is working fine. However, override by instance name is not working.
I am calling the below after router_env has been created.
Case 1: router_base_seq::type_id::set_type_override(router_012_seq::get_type());
Case 2: router_base_seq::type_id::set_inst_override(router_012_seq::get_type(), “router_env.seq”);
Any idea on what is wrong with Case 2?
Thanks!

Your case 2 is wrong. The hierarchical path points to the sequencer and not to the sequence.
I believe there is no value in constructing a ‘sequence architecture’. This would be in contrast or an alternative to the inheritence of object-oriented programming.
It is more easy and obvious to create/extend another sequence with the required behavior instead of overriding a certain sequence object.

In reply to Coppola:
The instance name should come from uvm_test_top.

 // try this
router_base_seq::type_id::set_inst_override(router_012_seq::get_type(), "uvm_test_top.router_env.seq");

In reply to Raghunandan Reddy:

In reply to Coppola:
The instance name should come from uvm_test_top.

 // try this
router_base_seq::type_id::set_inst_override(router_012_seq::get_type(), "uvm_test_top.router_env.seq");

Again the sequence does not belong to the topology of the UVM testbench. It is not a component. It is an object.

Agree with chr_sue and rag123 that sequence in general does not belong to the UVM topology. However, i explicitly declared an instance “seq” in my env. Hence, i should be able to access it using env.seq. Given that, following solution worked.

// try this
router_base_seq::type_id::set_inst_override(router_012_seq::get_type(),“uvm_test_top.router_env.seq”);