UVM reg model mask

[qwerty]

Hi,

 

I have a 32 bit register in which some of the bits are reserved. I have added the mask in the register model. But the reserved bits are also read/writable.

I only wont to write to the bits which are not reserved.

 

    foreach (rg) begin
           foreach (fields[j]) begin
         if (fields[j].get_name() == "UNUSED" ) begin
            $display("UNUSED field= %s",fields[j].get_name());
             end
          else begin
                    fields[j].write(status, wdata,.parent(this));
        end  
 end

 

I tried the obove solution, but it writes for every field which is slowing me down.

Is their a way i can get the mask from the register model? Or any other solution?

 

Thanks

 

 

 

 

[uwes]

hi,

 

unmodelled bits are treated as "don't care" by the model - so why do you care? you may read/write the bits - you just cant access them by a "name" and of course they will not compare.

 

 

the simplest way is not to model "rsvd" fields otherwise if you want to model them and label the field "reserved" or similar you have to provide a matching access policy. If you do not want to consider the field in compare then disable the check (.set_check()). if you just cannot predict the value then mark it initially a "volatile" or turn off the check afterwards.

 

/uwe

[qwerty]

I have modeled the unused bits as "rsvd" in the model. but the issue is, the dut still writes on those unused bits. So while i do a mirror, it fails as the dut has all 1's (if i write all 1's ) but the model writes according to the mask in it.

 

So how can i disable the check or what access policy to use to disable it.

 

Thanks

[tudor.timi]

unmodelled bits are treated as "don't care" by the model - so why do you care? you may read/write the bits - you just cant access them by a "name" and of course they will not compare.

 

the simplest way is not to model "rsvd" fields otherwise if you want to model them and label the field "reserved" or similar you have to provide a matching access policy. If you do not want to consider the field in compare then disable the check (.set_check()). if you just cannot predict the value then mark it initially a "volatile" or turn off the check afterwards.

 

I have to strongly disagree with Uwe on this one. Unmodeled bits are not treated as don't care. The locations for unmodeled bits are not masked away for the check. The error message will look like this:

 

reporter [RegModel] Register "example_reg_block.example_reg" value read from DUT (0x00000000ffffffff) does not match mirrored value (0x00000000ff0000ff)

The middle 16 bits are not modeled in example_reg, but I simulated a read access from the DUT where those bits are set. There is an error message saying that the whole register value doesn't match, but no individual error message saying which field doesn't match (because there isn't any field modeled in example_reg). I agree that this is the way it should behave, but this isn't what is implemented in the BCL. Please file a Mantis item on this issue, as I can't. I can provide you with a testcase that reproduces the problem if you want.

 

P.S. You should really rethink this whole Mantis system to let users also add issues otherwise I'm pretty sure stuff will continue to be missed.

[uwes]

hi,

 

isnt this http://www.eda.org/mantis/view.php?id=4806 ? i think the patch is missing from uvm12 - can you try to apply http://sourceforge.net/p/uvm/code/ci/852d197932c928f526c44779e16c68bcc2854e73/ and see if your unmodelled fields are still considered?

 

/uwe

[tudor.timi]

Coming back to your problem, qwerty, your best bet is to model the reserved fields as volatile. The access policy can be "RW" (or any other I guess), as volatile fields are not checked:

class example_reg_type extends uvm_reg;
  `uvm_object_utils(example_reg_type)
  
  rand uvm_reg_field field1;
  rand uvm_reg_field rsvd;
  rand uvm_reg_field field2;
  
  function new(string name = "example_reg_type");
    super.new(name, 32, UVM_NO_COVERAGE);
  endfunction
  
  virtual function void build();
    field1 = uvm_reg_field::type_id::create("field1");
    rsvd   = uvm_reg_field::type_id::create("rsvd");
    field2 = uvm_reg_field::type_id::create("field2");
    
    field1.configure(this,  8, 24, "RW", 0, 0, 1, 1, 0);
    rsvd  .configure(this, 16, 8,  "RW", 1, 0, 1, 1, 0); 
    field2.configure(this,  8,  0, "RW", 0, 0, 1, 1, 0);
  endfunction
endclass

As you see in my example, I've declared a field called rsvd that is mapped between field1 and field2. It's policy is "RW" and it's set as volatile (the first argument after the access policy is 1).

[tudor.timi]

isnt this http://www.eda.org/mantis/view.php?id=4806 ? i think the patch is missing from uvm12

 

There's a Mantis for it. Cool! I'm using UVM 1.1d, so I can't say anything about UVM 1.2.

 

It's a bit worrisome IMHO that this was only found/reported in (very late) 2013 and wasn't fixed. This is 2 and something years after UVM 1.0 came out. It brings this blog post from a year ago back to the spotlight http://www.agilesoc.com/2013/07/07/how-uvm-1-1d-makes-the-case-for-unit-testing/

[uwes]

hi,

 

>It's a bit worrisome IMHO that this was only found/reported in (very late) 2013 and wasn't fixed. 

the issue was reported & fixed in dec2013. the issue is that the fix was omitted from uvm12 unnoticed because the issue was not targeted to be fixed in 1.2 in the mantis system. and actually there is a test for this scenario now but its in the same unmerged branch as the fix itself.

 

 

>Coming back to your problem, qwerty, your best bet is to model the reserved fields as volatile. 

marking the field as volatile during creation turns off the checks. but you can also go and find all "rsvd" fields once and mark them as UVM_NO_CHECK.

 

/uwe

[tudor.timi]

Hijacking the thread for a bit.

 

the issue was reported & fixed in dec2013. the issue is that the fix was omitted from uvm12 unnoticed because the issue was not targeted to be fixed in 1.2 in the mantis system. and actually there is a test for this scenario now but its in the same unmerged branch as the fix itself.

 

Is there a future bug fix release for UVM 1.1 planned? UVM 1.1e maybe for people who don't want to migrate to UVM 1.2 just yet?

[uwes]

>Is there a future bug fix release for UVM 1.1 planned? UVM 1.1e maybe for people who don't want to migrate to UVM 1.2 just yet?

there will be no uvm11 release anymore. "all" bugfixes/enhancements went into uvm12.

 

/uwe

[qwerty]

Thanks guys for the help..