The built-in bit-bash test fails on a status register the design implements exactly as specified. Fix the register model.
Hardware context: Event counter register slice with a write-1-to-clear flag and a read-to-clear counter. Give a write-1-to-clear field its correct access policy.
An event counter has three registers: CTRL, STATUS and COUNT. Its first regression runs uvm_reg_hw_reset_seq and uvm_reg_bit_bash_seq on the block, then a short scenario: count eighteen events, read COUNT, read STATUS, clear the overflow flag and read STATUS again.
bit_bash reports errors on STATUS, and the model's mirror of STATUS after the clear disagrees with what the design then reads. The designer points at the register map in the comment, and the design follows it.
One field of the model does not describe the design. Fix the model so the built-in tests pass and its mirror follows the design through the scenario.
Full specification
// 0x00 CTRL en[0] read-write, reset 0: count events while 1
// 0x04 STATUS ovf[0] set when COUNT wraps from 15 to 0; writing 1 clears it
// 0x08 COUNT n[3:0] events since the last read; a bus read returns it and clears it
The bench builds the block from your three register classes, with auto prediction on, and runs hw_reset and bit_bash straight after reset, then the scenario. It counts UVM errors per stage and shows them as warnings. A field that the design changes on its own, such as a flag an event sets, is volatile.
Examples
Example 1
Built-in tests- Input
uvm_reg_hw_reset_seq, then uvm_reg_bit_bash_seq, on the whole block straight after reset
- Output
hw_reset_errors = 0, bit_bash_errors = 0
Every reset value matches, and bit_bash skips the two volatile fields and checks every other bit, including the unimplemented ones as read-only zeros.
Example 2
COUNT clears on read- Input
18 events with CTRL.en = 1, then count.read()
- Output
count_read = 2, count_mirrored_after_read = 0
Eighteen events wrap the 4-bit counter once and leave 2. The read returns 2, and a read-to-clear model predicts 0 afterwards.
Example 3
Clearing ovf- Input
status.read(), status.write(1), then status.read()
- Output
ovf_read = 1, ovf_mirrored_after_clear = 0, ovf_read_after_clear = 0, errors_in_the_scenario = 0
ovf reads 1 after the wrap. Writing 1 clears it in the design, so a correct model predicts 0, and the next read agrees.
Constraints and contract
- Change only field configuration; keep the classes, the field names, widths and positions.
- Every field's access policy and volatility must match the register map.
- The built-in tests must pass with no register excluded.
Hints
Hint 1
bit_bash writes each bit and reads it back, expecting what the model's access policy says. What does the design return after a 1 is written to ovf?
Hint 2
Read the map's line for STATUS as an access policy: what does a write of 1 do, and who else changes the bit?
Hint 3
UVM has an access string for "writing 1 clears", and a field that hardware sets is volatile.
What this judge verifies: Your register model runs the library's hw_reset and bit_bash sequences and a short event scenario against the event counter design, through a real register map with auto prediction. The checks count errors per stage and compare the model's mirror with what the design returns.
3 checks on UVM · local server. Run the examples first, then check the full regression. The suite is local and inspectable. A passing result establishes the tested cases, not a proof for all possible inputs.
See all 1 problem on this path