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?
In reply to aarelovich:
My suggestion would be not to mix and match the operations of driver with monitor and vice-versa.
a. Say if you are porting your bench to the SoC level, in that scenario you don’t want the driver/sequence active components and you tend to disable them. So in that case, your scoreboard will be expecting some data for checking process and will get stuck since your components are in passive mode.
b. Instead if you have your monitor by default as per basic flow, irrespective whether you agent is in active/passive mode, the monitor keeps monitor the data and sends it to the scoreboard for checks.
So for portability from IP/Subsystem Verification to SoC verification, its better to have them separate and do their functionalities separately and not to mix them.
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.
In reply to desperadorocks:
This is the final design. These situations are very very unlikely. Basically they are not a problem.
In reply to chr_sue:
The IP that will be connected to the DUT is the one that will emit the FIFO_full signal. I need (in my driver) to simulate this behaviour in order to see if the DUT reacts accordingly to that signal.
I hope that clarifies it for you.
In reply to aarelovich:
OK, your IP is a VIP (verification IP). Is this a UVM agent or environment?
Then you can generate a sequence to drive the fifo_full signal.
In reply to chr_sue:
Yes, this is what I’ve done. I just didn’t add a monitor since the sequence can only end when the driver obtains all of the information.
In reply to aarelovich:
The UVM does not have compliance rules. For this reason it is OK, what you are doing. In some of my UVM testbenches I do not have monitors. I’m passing directly from the driver data needed for coverage collection or scoreboarding through an analysis port in the driver to the appropriate components. It’s simply fine and not a violation of rules.
For most problems there is not ONE best practice. There are always more than ONE solutions.