Register Model Study -- Back-door read/write vs. peek/poke

You can perform back-door access to registers and memory by calling the following read/write methods
with their path argument as UVM_BACKDOOR:

a) uvm_reg_field::read() or uvm_reg_field::write()
b) uvm_reg::read() or uvm_reg::write()
c) uvm_mem::read() or uvm_mem::write()

… or by calling the following peek/poke methods:

d) uvm_reg_field::peek() or uvm_reg_field::poke()
e) uvm_reg::peek() or uvm_reg::poke()
f) uvm_mem::peek() or uvm_mem::poke()

• The peek() methods return the raw value read using the back-door without modifying the content of the register or memory. Should the register content be modified upon a normal read operation, such as a clear-on-read field, it will not be modified. Therefore, reading using peek() methods may yield different results than reading through read() methods.
• The poke() methods deposit the specified value directly in the register or memory. Should the register contain non-writable bits or bits that do not reflect the exact value written, such as read-only or write-1-to-clear fields, they will contain a different value than if the same value had been written through normal means. All field values, regardless of their access mode, will be forced to the poked value. Therefore, writing using poke() methods may yield different results than writing through the front-door.
• When using the read() methods with a back-door access path, the behavior of the register or memory access mimics the same access performed using a front-door access. For example, reading a register containing a clear-on-read field will cause the field value to be cleared by poking 0’s into it.
• When using the write() method with a back-door access path, the behavior of the register or memory access mimics the same access performed using a front-door access. For example, writing to a read-only field using back-door access will cause the field value to be maintained by first peeking its current value then poking it back in instead of the specified value.