In reply to Robin Hotchkiss:
No warnings are seen from the model when this occurs. The predict of the previous read is performed after the next call to write starts, but before the time progresses - so before the write starts on the bus, but after some of the non-time consuming code of the write task has been executed.
Hmmm. I see now the code for that warning doesn’t apply here. It protects multiple read(), write(), mirror(), and update() calls from simultaneously driving the bus, but it doesn’t prevent predict() from coming in like this. As you said, I don’t see anything to prevent such a race. It seems to me predict() should test m_atomic.try_get(1). If it doesn’t get a key, it should warn that the register is already in use and simply return, throwing the prediction away.
There’s really no way to completely prevent a late prediction race like this, but predict() could certain do a better job of protecting you. Can you change how your driver or monitor are coded to change the event order? Can you modify your uvm library to add a test for m_atomic?