Lets say you have a simple serial interface, with an enable signal. As long as that signal is high you need to buffer incoming bits. Once the signal goes down, then the transaction has finished. You build a UVM monitor for it. So every time you get a falling edge of the enable, a transaction is finished, which you write to a port. The data will eventually be compared against the expected transaction generated by a predictor.
However, lets assume a test where that particular interface does not need to generate any transactions at all. And at the same time, by an error in the DUT the enable signal goes up, but it never goes down. So the UVM monitor will never send the “incorrect” transaction as the finish condition was never reached. There will be no error in the comparison between the expected data and the DUT data. And this error will be missed.
You are transmitting your transactions via analysis_port to a subscriber, like a functional coverage collector. If no transaction is sent to coverage collector you’ll see this in the in your coverage numbers and you see also that the monotor has not reported anything in the UVM Summary.
But that is just the problem. I should see something somewhere because the signals were not supposed to move at all. If nothing shows up when I was expecting nothing, the system cannot recognized that something was wrong.
I believe there is no general answer. But if there is no transaction in the monitor this can be reported. You could balance the number of transactions in the driving side and the monitor. This might give you also a hint to investigate the details. You could also write an assertion to indicate that your tarnsaction ha a start and a stop bit etc.
You shouldn’t stop your simulation while there are still transactions in flight. Your monitor should delay the end of the test whenever it starts collecting a transaction and allow it only after a transaction was collected. This can be done in multiple ways:
raise an objection whenever you start collecting and drop it once that transaction has been collected and sent out an analysis port
override phase_ready_to_end() to block the end of the run_phase while you’re collecting a transaction
Well actually I did something similar to this. I’ve implemented a simple flag that raises when the transaction starts and lower when it ends. I check the status of the flag in the check_phase for the monitor. I belived this solves the issue. Thank you!
I would use a UVM objection at the rising edge of the signal; and then fork/join_any a parallel thread with a timeout delay that will throw a UVM error at completion. The racing thread being the monitor main thread.
So long as your are doing that check in the monitor; that looks pretty elegant too: but it seems to me you could have a test end while a transaction is still incoming and valid.
either with too long simulation time, because as DUT enable never goes down, that means your simulation will keep going. So somewhere in your code just put # $finish and when it finish the simulation you will see that something is wrong.
another simple way I guess using assertion, just write assertion to track the DUT enable port to go low, after while, when it goes high
monitor also can track that signal and print error