Writing register fields

[ejo]

I am confused about register field write() vs register field set() followed by register update().

 

When writing a register field, a warning is echoed on the transcript (with uvm 1.1b and 1.1d):

 

"...[RegModel] Target bus does not support byte enabling, and the field 'test_rm.test_field' is not the only field within the entire bus width. Individual field access will not be available. Accessing complete register instead."

 

While it is correct that my target bus does not support byte enabling, the field is indeed the only field in the register.

 

Single-stepping through uvm_reg_field::write() up to the point where the warning is echoed, shows that a check for side effects is being made before the actual bus write, in this case resulting in a "bad_side_effect" flag being cleared (since there is no fields to conflict with), but instead of just proceeding with the bus write at this point, another checker is called to figure out if the field is individually accessible, and this check fails, even if the field has been configured as such. The checker even concludes there is only one field in the register by setting a bit named "sole_field", still the checker emits the warning and returns failure. This does not look right.

 

So in an attempt to get rid of the warning, I tried set(value) on the field followed by update() on the register. But it seems this isn't the same as write(value) on the field. For example, if the field has W1C access, then set(1) will clear bit 0 of the desired value and if that changed the desired value, a subsequent update will write the desired value to the bus. A write(1) on the field, on the other hand, will do just that. Thus there is a difference both in what value is written on the bus and also whether or not a bus transaction will take place.

 

So how can register fields be written to the dut without flooding the transcript with warnings?  I realize the warnings can be silenced via the log system, but that will disable all warnings from [RegModel], and that is probably not a good idea.

 

 

Erling