Difficulty: Medium · Puzzle 5 of 6 · Topic: Analysis, Scoreboards and RAL
UVM 1.2. An interrupt status register holds 3 and clears itself when read over the bus (RC). The test reads it twice by backdoor (peek) and then twice by front-door read. What are the four values?
status.peek(st, a, UVM_BACKDOOR);
status.peek(st, b, UVM_BACKDOOR);
status.read(st, c, UVM_FRONTDOOR);
status.read(st, d, UVM_FRONTDOOR);
`uvm_info("R", $sformatf("%0d %0d %0d %0d", a, b, c, d), UVM_LOW)What actually causes the clearing in the RTL, and does a backdoor access produce it?
1) The register clears because the RTL sees a bus read strobe. A backdoor peek reads the register's signal hierarchically and produces no bus transaction.
2) So the two peeks both return 3 and leave it at 3.
3) The first front-door read returns 3 and triggers the clear; the second returns 0.
4) Values: 3 3 3 0.Answer: 3 3 3 0.
Checked by running the code in Verilator 5; the printed output supports the answer above. Hand-written model of the documented UVM 1.2 behaviour in plain SystemVerilog (Verilator), not the UVM library: a clear-on-read register: only the front-door read has the side effect.
Backdoor accesses bypass side effects (clear-on-read, FIFO pops, W1C), so a backdoor check of such a register tells you the stored value but proves nothing about the read side effect; and conversely a front-door read of an RC register destroys the state you wanted to inspect.
Which access do you use to verify the clear-on-read behaviour itself? Model answer: front-door reads: read once and check the returned value (3), read again and check 0; backdoor peek can then be used to confirm the stored bits cleared, without disturbing further state.