Jump to content

uvm_reg_hw_reset_seq verifying reset value even though has_reset is 0


Recommended Posts

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?

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...