ejo Posted October 13, 2014 Report Share Posted October 13, 2014 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 Quote Link to comment Share on other sites More sharing options...
uwes Posted October 13, 2014 Report Share Posted October 13, 2014 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 Quote Link to comment Share on other sites More sharing options...
ejo Posted October 13, 2014 Author Report Share Posted October 13, 2014 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 Quote Link to comment Share on other sites More sharing options...
uwes Posted October 13, 2014 Report Share Posted October 13, 2014 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 Quote Link to comment Share on other sites More sharing options...
ejo Posted October 13, 2014 Author Report Share Posted October 13, 2014 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 Quote Link to comment Share on other sites More sharing options...
ejo Posted October 14, 2014 Author Report Share Posted October 14, 2014 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 Quote Link to comment Share on other sites More sharing options...
york Posted March 27 Report Share Posted March 27 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. Quote Link to comment Share on other sites More sharing options...
york Posted March 27 Report Share Posted March 27 The fact that the desired value of RO field doesn't change when you call set() basically means that the RO field shouldn't need any bus access when update() is called. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.