uvma_obi_memory_mon: R-channel can mis-associate rvalid after reset with pre-reset outstanding transaction

[adrianf0]

Description:
In uvma_obi_memory_mon_c, the R-channel monitor thread can incorrectly associate an rvalid response observed after a reset with an outstanding transaction sampled before reset. This can result in uvma_obi_memory_mon_trn_c objects containing mismatched address/data (or wrong access ordering).

Expected behavior:
When reset_n is asserted:

• all outstanding pre-reset transactions should be flushed/aborted, and
• the monitor should not match a post-reset rvalid to a pre-reset request.

Actual behavior:
mon_chan_r_post_reset() pops an outstanding transaction from cntxt.mon_outstanding_reads_q and then waits for rvalid in mon_chan_r_trn(). If reset is asserted while mon_chan_r_trn() is waiting, the task does not abort. After reset deassertion, the next rvalid (from a new post-reset request) can be incorrectly matched to the pre-reset transaction.

How to reproduce:

1. Configure OBI agent in SLV mode with non-zero randomized rvalid_latency.
2. Issue one request so it is pushed into mon_outstanding_reads_q.
3. Assert reset_n==0 after the A-phase is observed but before the corresponding rvalid.
4. After reset is released, issue a new transaction.
5. Observe that the monitor can report a response for the old transaction using the rvalid of the new one (mismatched ordering/data).

Impact:
Scoreboards/checkers relying on uvma_obi_memory_mon_trn_c may report false data mismatches or “phantom” transactions around reset boundaries.

[MikeOpenHWGroup]

Hi @adrianf0, thanks for generating this Issue (and also #2734). We have known since the beginning that the OBI Agent lacks proper support for on-the-fly resets and you've motivated me to take another look at it. Due to other activities it is unlikely I will have time for this for several weeks. If you'd like to suggest a fix, we'd be happy to review your PR.

Be sure to review CONTRIBUTING first.