set_type_override and set_inst_override usage inconsistency

[chintanm86]

Hi,

Recently I was working on updates to my environment and had to switch to set_inst_override from set_type_override to be able to override the base_sequence with a different sequence for different master agents.

Code in base_test to start sequence on master sequencer ::

master_base_seq seq = master_base_seq::type_id::create("seq",this,"masterName");
seq.start(top.virtual_sequencer.masterSequencer);

Code in test for initial override ::

master_base_seq::type_id::set_inst_override(master_user1_seq::get_type,"masterName.seq");

Now, later in test I need to change this override so that I can start another sequence on the same master.

Coming from the set_type_override usage, i ended up writing below code ::

master_base_seq::type_id::set_inst_override(master_user2_seq::get_type,"masterName.seq");

I observed that second time, the master still started the master_user1_seq instead the intended master_user2_seq.

I printed the factory to see whether the override was registered or not, and I got below print ::

# Instance Overrides:
# 
# Requested Type Override Path Override Type 
# ------------------------- --------------------------------------------------- ---------------------------------
# master_base_seq masterName.seq master_user1_seq
# master_base_seq masterName.seq master_user2_seq

After some experiments, I found that second time I need to use below override to be able to start the master_user2_seq on the master ::

master_user1_seq::type_id::set_inst_override(master_user2_seq::get_type,"masterName.seq");

Above approach works, but have 2 issues ::

1.  It's not consistent with the set_type_override usage.

2. This requires to keep track of last set_inst_override type in-order to override the inst with new type.

I ended-up updating the uvm-1.2 library in-order to make the set_inst_override usage in-line with set_type_override as below::

In the check_inst_override_exists method in uvm_factory_.svh file -

1. I commented the same override_type check

This way I only check whether the new request is for existing original_type and same full_inst_path.

2. When I get the match, I simply override the existing override with the new override_type and override_type_name.

Updated code looks as below ::

 

// check_inst_override_exists
// --------------------------
function bit uvm_default_factory::check_inst_override_exists (uvm_object_wrapper original_type,
                                      uvm_object_wrapper override_type,
                                      string full_inst_path);
  uvm_factory_override override;
  uvm_factory_queue_class qc;

  if (m_inst_override_queues.exists(original_type))
    qc = m_inst_override_queues[original_type];
  else
    return 0;

  for (int index=0; index<qc.queue.size(); ++index) begin

    override = qc.queue[index]; 
    if (override.full_inst_path == full_inst_path &&
        override.orig_type == original_type &&
        /*override.ovrd_type == override_type &&*/ //Commented check
        override.orig_type_name == original_type.get_type_name()) begin
    uvm_report_info("DUPOVRD",{"Instance override for '",
       original_type.get_type_name(),"' already exists: override type '",
       override_type.get_type_name(),"' with full_inst_path '",
       full_inst_path,"'"},UVM_HIGH);
      override.ovrd_type = override_type; // New Line
      override.ovrd_type_name = override_type.get_type_name(); //New Line
      return 1;
    end
  end
  return 0;
endfunction

 

With above change the set_inst_override usage becomes same as set_type_override.

I am able to override inst for a object/component any number of time while using the same base_type and full_inst_path.

Please, let me know, if this change or a batter solution can be incorporated in the next release.

Thanks,

Chintan

 

[mastrick]

Thank you for posting Chintan.  I see the 1800.2-2017 standard says in "8.3.1.4.1 set_inst_override_by_type and set_inst_override_by_name":

Quote

When the factory processes instance overrides, the instance queue is processed in order of override
registrations and the first override match prevails. Thus, more specific overrides should be registered first,
followed by more general overrides.

That says to me that when you gave your original commands to override master_base_seq twice with different override types, the first one should be applied, just as you saw.  The set_type_override variations include a "replace" argument that controls whether the new or the older override has priority, so it can work either way.

[chintanm86]

Hi Mastrick,

 

Thanks for the reply.

 

Can we have similar replace argument for set_inst_override? that would make more sense and debug will be less complex.

 

Also, it will enable more simple inst_override usage.

 

Thanks,

Chintan