In reply to aarelovich:
Here is my situation.
The output of my DUT drives an 8 bit word on each clock and also a write enable when the data is valid. The DUT will be connected to another IP which has a FIFO receiving the data, becuase it needs to process each byte and it takes several clocks to do so. When the DUT attempts to write into the FIFO and the FIFO is full, it will emit a FIFO_full signal so that the DUT does not change continue sending the information.
The only way of knowing when the information is all sent is to buffer and process the each byte in the UVM testbench.
In order to fully verify the DUT I need to reproduce that FIFO_full behaviour, hence I need a driver for that interface. Thing is, that a monitor for that interface will need to do the almost EXACT same thing. The only difference is that the driver will drive the FIFO_full signal, while the monitor will just read it, to know whether to buffer the data or not. But both will need to receive and process each byte. The Driver needs to do this in order to know when the transaction is done. And the Monitor needs to do it because it actually needs the information so it can provide it to the scoreboard.
This seems very counter-intuitive because of doing the same thing twice.
The problem can easily be fixed by either having the monitor drive the FIFO_full signal or just having the driver use an analysis port to send the information to the scoreboard.
Is there any reason why this should not be done?
My question is: does the DUT fifo indicate ‘full’ or do you have a fifo in the driver indicating ‘full’? I gues you want to verify ‘fifo full’ in the design. Then you have to feed your DUT fifo with appropriate data.