Jump to content

umv 1.2: update of volatile reg fields


Recommended Posts

Starting with uvm 1.2, needs_update() of uvm_reg_field returns 1 for volatile fields. So after randomize on the register model, uvm_reg_field now thinks that volatile fields are to be updated, which doesn't work when the underlaying protocol doesn't allow writing to such fields.

 

What am I missing, ie why does uvm 1.2 force update of volatile registers/fields?

 

 

Erling
Link to comment
Share on other sites

hi,

 

this is because of the fact that volatile fields always needed to be updated. there is no way to filter out accesses based upon the knowledge that the write value is already in the register. uvm_reg::update() would otherwise not operate properly on volatile fields. 

 

>volatile fields are to be updated, which doesn't work when the underlaying protocol doesn't allow writing to such fields.

 

it sounds as if you are not using the right access policy. the volatile property is orthogonal to the fact that you can access a field . i didnt check in the UVM implementation if the update() operation would omit inaccessible regs. (a (volatile) reg/field with an effective policy NOACCESS should not be attempted to be written)

 

/uwe

Link to comment
Share on other sites

I still do not understand why the model should force an update to a volatile readonly field covering the full register width. Before 1.2, the predictor simply stored the register value on read without checking, and write's didn't happen because the register was never written to explicitly, and randomizing the model didn't change the value, and thus update() didn't touch the register. What does it mean "volatile fields always needed to be updated"?

 

 

Erling

Link to comment
Share on other sites

hi,

 

needs_update() is called as part of update() in order to determine the smallest subset of regs to be written in the update operation. with a volatile reg one has to assume that the reg needs to be written because the value of the reg cannot be determined for sure (it could change right after it has been read). therefore volatile regs do not attempt to determine if they have to be written by comparing desired+value you simply have to write them (if they are accessible).

 

>Before 1.2, the predictor simply stored the register value on read without checking, and write's didn't happen because the register was never written to >explicitly, and randomizing the model didn't change the value, and thus update() didn't touch the register.

 

basically you never wrote the reg because you did assume you know the reg value (which is wrong). the truth is that the regs value can change at any time and update has to unconditionally write the value. or the other way around: update() is a shortcut compared to write() which writes all registers unconditionally so in order to update the right regs/fields volatile have to be included unconditionally.

 

/uwe

Link to comment
Share on other sites

My current workaround is to configure register fields of said type as non-volatile, non-rand, and then explicitly call set_compare(UVM_NO_CHECK) to avoid checking of readback, since the non-volatile property isn't taking care of this implicitly. This seems to work, but I still think that something that used to work right of the box is broken in uvm 1.2.

 

 

Erling
Link to comment
Share on other sites

  • 9 years later...
On 10/13/2014 at 11:01 PM, uwes said:

hi,

 

needs_update() is called as part of update() in order to determine the smallest subset of regs to be written in the update operation. with a volatile reg one has to assume that the reg needs to be written because the value of the reg cannot be determined for sure (it could change right after it has been read). therefore volatile regs do not attempt to determine if they have to be written by comparing desired+value you simply have to write them (if they are accessible).

 

>Before 1.2, the predictor simply stored the register value on read without checking, and write's didn't happen because the register was never written to >explicitly, and randomizing the model didn't change the value, and thus update() didn't touch the register.

 

basically you never wrote the reg because you did assume you know the reg value (which is wrong). the truth is that the regs value can change at any time and update has to unconditionally write the value. or the other way around: update() is a shortcut compared to write() which writes all registers unconditionally so in order to update the right regs/fields volatile have to be included unconditionally.

 

/uwe

I understand your meaning. For RW volatile field. It is required to write the register every time the update() is called because the dut value may be different to the desired value since the last access.

But for RO volatile field, I don't think it is required to call update() because writing to them is useless. The dut value won't update to the desired value. In my opinion, it is only used to bypass read checking.

So I think needs_update() need to change to not writing to readonly register at all.

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.

×
×
  • Create New...