According to the UVM documents:
UVM uses the IEEE 1685-2009 IP-XACT definition of “volatility”. If TRUE, the value of the register is not predictable because it may change between consecutive accesses. This typically indicates a field whose value is updated by the DUT. The nature or cause of the change is not specified.
Since this states that you cannot “predict” for a volatile field, why is do_predict() called for the field?
I would assume that we would want to implement a “cycle accurate prediction model” (by monitoring the RTL signal and updating the RAL model appropriately if we wanted to keep a consistent RAL. Thus I would need to disable this prediction (and “locking” [busy]). However I cannot find a field method or field to control this.
What is to be done, and is this something that should be added ?
Hey so basically the m_volitile generally speaking is only and only an indication of the volatility of such register and does not change the comparison/operation behavior at least in UVM1.1d.
If you have such registers in your design (status register, HW written only register or shadow register) then the best approach I could suggest is to call the predict on your own by modeling how those registers should be predicted.
Alternatively, you can add a specific call back to those registers (if they behave in the same way) so that the post predict will be called hence you will have to compare the mirrored value between RAL and RTL.
This is the best approach I come up wit in my testbench since I have such tricky registers in RTL.
Regards
In reply to Rsignori92:
I cannot speak to UVM 1.1d, but UVM 1.2 has the following (in uvm_ral_field in configure():
m_check = volatile ? UVM_NO_CHECK : UVM_CHECK;
Thus it will not check between the read value (from RTL) and the expected for that field.
in uvm_reg::do_check()
So that is not my issue. It still will call do_predict()
That updates m_mirrored, m_desired, and this.value in the field and register.
My contention is that this should be controllable, so that if you add a monitor on the RTL signal, and then update the RAL “in real time”, that these should be disabled.
It literally states that “it cannot be predicted” [unless you white box it].
I understand why they would do what they are doing. It is as close as you can get without that white box monitoring.
If your suggestion is working, I would like to know, are you hooking the cb.post_predict(…) then to replace what was read by what IS? I think this is my only choice at this point.
In reply to DavidEllis:
Yep, by hooking the cb with post predict you basically are gonna model behaviour like: clear register IRQ when the value of another register is written.
Or alternatively you can eventually predict by calling the prediction methods in your scoreboard or model.
I’m using both, sometimes callbacks save you time, nevertheless other scenarios would require the scoreboard properly updated.
Basically i was not aware of uvm 1.2 removed checks on that basically makes sense as you said.
Hope this helps.