UVM rerun removes the stimuli and RTL parts of the testbench, and plays back the stimuli from a wave file via python code. The python code reads the wave file (fsdb, shm, vcd, etc), and replays it on virtual interface pins. monitors/checker operate normally since they don't know the RTL/stimuli is gone.
When the original UVM testbench raises objection from sequences, these objections will not be raised at rerun time. Hence in such cases during replay UVM might terminate the test too early.
One solution to this problem would be to have a python function that will call a c function that will call into SV and raise an objection. We then use this function in the the test that replays the wave: https://github.com/avidan-efody/assertion_rerun/blob/main/injector/wave_rerunner.py
UVM rerun removes the stimuli and RTL parts of the testbench, and plays back the stimuli from a wave file via python code. The python code reads the wave file (fsdb, shm, vcd, etc), and replays it on virtual interface pins. monitors/checker operate normally since they don't know the RTL/stimuli is gone.
When the original UVM testbench raises objection from sequences, these objections will not be raised at rerun time. Hence in such cases during replay UVM might terminate the test too early.
One solution to this problem would be to have a python function that will call a c function that will call into SV and raise an objection. We then use this function in the the test that replays the wave: https://github.com/avidan-efody/assertion_rerun/blob/main/injector/wave_rerunner.py