One of the blocks in our design is mostly complex control logic, and will set bits in a status register under certain conditions. I have read the information on using a register model in a scoreboard (spi_scoreboard example) and plan to use a similar approach. In my DUT, stimulus will be applied, then we need to wait for some amount of time and check the status register bits to confirm they have been set (or not set depending on testcase). Since the bits in the status register are internal to the DUT, I can’t use the wait_for_event technique to automatically determine when to read the status bits. How can I automate the amount of time delay before reading of status bits?
In the olden days (before SystemVerilog, e, vera) with a plain old Verilog testbench, I would have used a parameter to insert a delay or wait before reading back the status bits and proceeding to the next test. The parameter would be set differently depending on the testcase.
Ideally status bits are used to trigger an interrupt. If your module has an interrupt associated with this status bits registers, you could enable the interrupt and wait for the interrupt event to occur.
Once the interrupt is triggered, you could issue reads to the status register.
The module does have interrupt bits - in the status register. Some of the block level outputs will toggle based on certain operating conditions, and I will check these via the wait_for_signal task in my interface. There are some normal operating modes that will set status bits, but may not cause any activity on the block level outputs.
your Register model implementation is 0th time model not cyclic model.correct me if i am wrong ! in the case of zero time model you cant exactly predict the status register bit update in DUT. but there are 3 below options might helpful,
(1) You probe signal(responsible to set status bit) inside dut and use that event it in wait_for_signal task & then read the status register.
(2) There is backdoor sync in register model.through which your model will automatically get updated when DUT registers updated but this is not a recommended way to do that but still if u can use DUT status register update event.
(3)calculate exact delay between the stimulu operation and status register update on trial and error basis.use it in your testcase.
It turns out I am able to use the wait_for_event technique to trigger reading of status bits. My DUT has a 1588 system time input (everything synced to this) that is generated with a simple homegrown UVC. I added a wait_for_time (sys_time) task to the configuration of the UVC, and the test writer simply needs to call this task before checking status register bits. The test writer will know how long to wait since they are creating the test. I could further automate the tests by reading DUT configuration registers, then calculating the amount of time to wait based on the configuration.