Hi All ,
While running uvm_reg_hw_reset_seq to verify default of registers in CSR there are certain registers whose actual default value isn’t the same as documented when the hw_reset_sequence runs .
Turns out that on asserting the system reset the default value is as per documented value but post reset de-assertion the design writes value in a few registers ( based on internal logic ) .
By the time I run my hw_reset_seq ( after System Configuration ) the default value of a few registers has changed .
So we do the following ::
(1) Skip such registers from hw_reset_seq using “NO_REG_TESTS” / “NO_REG_HW_RESET_TEST”
(2) Use explicit predict before starting the hw_rest_sequence ::
rm_h.sub_block.regA.predict( 32'habcd ); // where 32'habcd is value written internally post reset
Prototype of function predict is as follows ::
function bit predict ( uvm_reg_data_t value,
uvm_reg_byte_en_t be = -1,
uvm_predict_e kind = UVM_PREDICT_DIRECT,
uvm_path_e path = UVM_FRONTDOOR,
uvm_reg_map map = null,
string fname = "",
int lineno = 0
)
So by default I use UVM_PREDICT_DIRECT in my test
However I wanted to know about the other 2 states of enum-type uvm_predict_e ( UVM_PREDICT_READ and UVM_PREDICT_WRITE ) .
When should the user pass them as 3rd argument to predict ?
The UVM Class Reference Manual continues ::
If kind is specified as UVM_PREDICT_READ, the value was observed in a read transaction on the specified address map or backdoor (if path is UVM_BACKDOOR).
If kind is specified as UVM_PREDICT_WRITE, the value was observed in a write transaction on the specified address map or backdoor (if path is UVM_BACKDOOR).
If kind is specified as UVM_PREDICT_DIRECT, the value was computed and is updated as-is, without regard to any access policy.
For example, the mirrored value of a read-only field is modified by this method if kind is specified as UVM_PREDICT_DIRECT.
I am not clear on the above explanation and seek simpler explanation for UVM_PREDICT_READ and UVM_PREDICT_WRITE