umv 1.2: update of volatile reg fields

[ejo]

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

[uwes]

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

[ejo]

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

[uwes]

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

[ejo]

I don't get it. Say I have a register with one volatile readonly field that can't be written. How do I model this?

 

 

Erling

[ejo]

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