How to set_inst_override_by_type a uvm_reg

UVM
1

I want to override the behavior of a register instance by using set_inst_override_by_type() but it doesn’t seem to work.

Here’s the snippet of the code:

class mytest extends uvm_test;
  // bunch of boilerplate code
  virtual function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    set_inst_override_by_type("*err_cnt", apb_err_cnt::get_type(), myoverride_err_cnt::get_type());
  endfunction: build_phase
endclass: mytest

The above does not work because I’m trying to override a uvm_reg which is a uvm_object and therefore can’t be found in the hierarchy (not being a uvm_component). At least this is my current understanding.

So the question is: how to override an instance of a register?

I know I could override by type (with set_type_override_by_type()), but as I have an array of registers and some of them require a different override than the others, then I would like to understand whether there’s a way around the current set_inst_override_by_type() limitation to work only on uvm_component types.

2

Take a look here:

3

Hi Michael, thanks for your answer.

Unfortunately the DVCon 2013 paper that Tudor is referring to is not accessible anymore and it seems that even here on VerificationAcademy this link seems to be referring to the wrong paper.

Following the same approach could be an option if we are able to modify the register generator for the RAL.

But the idea to leverage the context during creation is an interesting one, thanks a lot!

4

FYI, I’ve updated the link to the DVcon paper on stackoverflow

2 Likes
5

@abasili do you perform factory registration for your registers via `uvm_object_utils ?

Without it there would no override possible

Also, could you share the code where you create the respective register to be overridden ?

6

yes we do, despite some argue that automation macros are adding overhead.

As I initially said, we are already “type overriding” - something that wouldn’t have worked if we did not register those objects with the factory - but sometimes it is necessary to use instance overrides to alter the register behavior of some elements of the registers array.

By looking at the create function, it seems that context can be used when the parent argument is null:

static function T create(string name, uvm_component parent, string contxt="");
  uvm_object obj;
  uvm_coreservice_t cs = uvm_coreservice_t::get();                                                     
  uvm_factory factory=cs.get_factory();
  if (contxt == "" && parent != null)
    contxt = parent.get_full_name();
  obj = factory.create_component_by_type(get(),contxt,name,parent);
  if (!$cast(create, obj)) begin
    string msg;
    msg = {"Factory did not return a component of type '",type_name,
        "'. A component of type '",obj == null ? "null" : obj.get_type_name(),
        "' was returned instead. Name=",name," Parent=",
        parent==null?"null":parent.get_type_name()," contxt=",contxt};
    uvm_report_fatal("FCTTYP", msg, UVM_NONE);
  end
endfunction

Hard to say why the create_component_by_type now requires again both the context and the parent, as it clearly can use the context only… but that’s beyond this discussion I believe.

7

My understanding is that since the registers are created in build() function of the reg_block ( which is an object as well ) , one can’t pass this as 2nd arg. during creation of the registers.

Hence one must pass get_full_name() as 3rd argument to create ( during creation of registers ) and then provide the same hierarchy while registering the instance override via your test

8

the registers are created with the create() method, not the in the build() one. And I’m afraid you can’t pass the second argument, i.e. parent, because the registers are uvm_objects and not uvm_components.

that’s what I also gathered, despite the fact the object is still not part of any test hierarchy, it can still be overridden by passing the full “hierarchical” name, whatever the result of get_full_name() is.