In UVM, the testbench does not have any visibility into the internal registers of the DUT. Then why is there mirroring and creation of Register models in the UVM testbench architecture? What purpose does it serve?
The testbench would not come to know if any status bit etc is ever updated or not inside DUT since it only has access to its input output ports.
The DUT may not have direct access internal registers via ports, but some registers are accessible via an interface protocol. The register model is primarily intended for these registers. But you can access any register in the design via the backdoor (but not always desirable as it requires more work to setup and maintain).
The mirror stores the value of what the test-bench thinks are the register values of the DUT. When you do a
.mirror()
, the register model compares the register value (actual) verses the mirror (expected).Status bits are often complicated to predict. To simplify things you can turn off the compare of the field (or register) with
.set_compare(UVM_NO_CHECK)
. If you disable the check at the field level, other fields in the same register will still be compared.If your ambiances and want to do more complex predictions/mirror-compare on status bits, then you do have the options, such as register callbacks or of extending the
uvm_reg
anduvm_reg_field
classes to overwrite the.predict
and.mirror
methods.