uvm_reg_hw_reset_seq verifying reset value even though has_reset is 0

[Kasper T]

I am currently working on a RAL model where some registers do not have any reset value, and actually return X when read the first time after reset. Now, this should be no problem as the has_reset bit is set to 0 on all the fields in these registers, so uvm_reg_hw_reset_seq should not attempt to read them. But it does anyway. And looking into the source code of the sequence, it indeed never checks the has_reset bit.

Is this a bug in UVM 1.2?

[Kasper T]

I did a little digging, and it turns out this is indeed a bug in UVM. In uvm_reg_field::configure() the NO_REG_HW_RESET_TEST attribute is set on the field, not the register, but the uvm_reg_hw_reset_seq sequence checks the NO_REG_HW_RESET_TEST attribute on the register and not the fields.

I have written this code snippet as a workaround, getting the NO_REG_HW_RESET_TEST from the register fields and setting it on the parent registers.

uvm_reg regs[$];
reg_blk.get_registers(regs);    

foreach (regs[i]) begin
  uvm_reg_field fields[$];
  regs[i].get_fields(fields);
  foreach (fields[f]) begin
    if (uvm_resource_db#(bit)::get_by_name({"REG::",fields[f].get_full_name()}, "NO_REG_HW_RESET_TEST", 0) != null) begin
      uvm_resource_db#(bit)::set({"REG::", regs[i].get_full_name()}, "NO_REG_HW_RESET_TEST", 1, this);
      break;
    end
  end
end

 

[Jamsheed]

This issue was fixed in the Accellera UVM reference implementation version 1800.2-2017-1.0. To help the user community, the Accellera UVM working group is actively fixing bugs and adding enhancements in newer versions of the reference implementation.