If register is RW both write/read function should work but if the register is RO/WO then,
If I have RO register A is that legitimate/allowed to use, A.write?
will it fail immediately without even starting a write transaction on bus?
or will do some bus transaction activity, and then fail as in the RTL/BUS will not allow to do that operation?
If it would fail just upon calling write function and no bus activity is possible through write function, then how should I test if any of these registers are not getting read as a bug in the design?
I only want to use UVM_FRONTDOOR options in this case, and lets assume register A will always return value 0 upon reading and write should not alter its value throughout simulation, but need to be tested.
Thank you.
In reply to megamind:
It depends on the rtl how it behaves.Moreover most of the times you will obey the access policies in the ral model.If at all if your simulation fails when you try to do write frontdoor,I suggest try doing write back door.You may find the actual issue
In reply to megamind:
If you are writing a RO Register the Status of the WR command returns NOT_OK and no bus cycle will be initiated.
The previous answer are either ambiguous or wrong.
Starting a write on a RO register will start a bus transfer. The DUT might then reject that bus transfer. For example, if you’re using an AHB bus to access registers, the DUT will issue an error via HRESP to signal the unsupported operation. This would be a design requirement and needs to be verified. You should also read the register back to make sure that it wasn’t updated by the write.
For WO registers, starting a read will work the same as above. Checking that the write did happen is a bit more complicated, since you can’t just read it via the bus. You could do a backdoor read which checks the value of the internal signal. If you can’t do backdoor accesses because you can’t/don’t want to set it up, you can still check that the write happened by “using” the values of the register. Registers configure operations in the DUT to behave differently, so if you perform an operation affected by this register and it misbehaves, you get a strong hint that the write didn’t go through. For example, a key register would be WO and would configure an encryption engine to perform an encrypt operation using that key. Your TB knows what key it programmed (via the register model) and if the results you predict for the operation don’t match what the DUT returns, this could be because the key write didn’t work properly.