I am implementing an agent for a DMA function. The sequence for the agent basically sends DMA descriptor and data information through transaction item to the driver. Driver sends both descriptor and data to the DUT upon request from the DUT.
The monitor has to reconstruct the data based on what is happening on the bus and send the same to scoreboard.
On the bus, one can only see data and address and other control signals. There is no such thing as descriptor transfer or data transfer. Only DUT or test/sequence knows what address is assigned to the descriptor or data in the memory space.
Further, one cannot infer this based on the addresses, as descriptors or data can reside anywhere in the system memory.
Given this, I am not sure, how monitor can get the same information that driver gets. I am not sending any information from driver to monitor as this would break a basic rule of vertical re-use.
So, I am essentially stuck at this point and looking for some directions.
I can provide more clarity if needed.
At this point, you should ask yourself not “How would I verify this in UVM?” but “How would I verify this at all?”
You are correct that at the block level, having the driver send the descriptor information to the monitor so that the monitor knows what to look for makes sense. However, it is not always the case that the monitor has to be able to recreate everything on its own. You could have the monitor detect all the data/descriptors that occur on the bus and send them to the scoreboard, for example. But your driver could also send the descriptor information to the scoreboard which could, perhaps, wait until it sees the same descriptor reported by the monitor. Then you could have the scoreboard do whatever data checking is appropriate.
Given the nature of your system, even when this DMA function is put into a larger system, you’re still going to need to give your verification environment a hint as to what to look for. Having the scoreboard be told about descriptors is portable in that the descriptor information can come from anywhere in your system that you’re able to detect/predict it.
I am implementing an agent for a DMA function. The sequence for the agent basically sends DMA descriptor and data information through transaction item to the driver. Driver sends both descriptor and data to the DUT upon request from the DUT.
The monitor has to reconstruct the data based on what is happening on the bus and send the same to scoreboard.
On the bus, one can only see data and address and other control signals. There is no such thing as descriptor transfer or data transfer. Only DUT or test/sequence knows what address is assigned to the descriptor or data in the memory space.
Further, one cannot infer this based on the addresses, as descriptors or data can reside anywhere in the system memory.
Given this, I am not sure, how monitor can get the same information that driver gets. I am not sending any information from driver to monitor as this would break a basic rule of vertical re-use.
So, I am essentially stuck at this point and looking for some directions.
I can provide more clarity if needed.
As you are describing the scenario, you have a responding driver. Waiting for a request coming from your DUT. If the driver gets trhe request it starts the driver protocol and is sending data to your DUT.
The monitor is observing your pinlevel interface. The monitor is doing nothing until it sees the request coming from the DUT. Then it can extract the data from the pinlevel interface and putting them into a transaction.
Where is the problem?
In reply to verif_learner:
At this point, you should ask yourself not “How would I verify this in UVM?” but “How would I verify this at all?”
You are correct that at the block level, having the driver send the descriptor information to the monitor so that the monitor knows what to look for makes sense. However, it is not always the case that the monitor has to be able to recreate everything on its own. You could have the monitor detect all the data/descriptors that occur on the bus and send them to the scoreboard, for example. But your driver could also send the descriptor information to the scoreboard which could, perhaps, wait until it sees the same descriptor reported by the monitor. Then you could have the scoreboard do whatever data checking is appropriate.
Given the nature of your system, even when this DMA function is put into a larger system, you’re still going to need to give your verification environment a hint as to what to look for. Having the scoreboard be told about descriptors is portable in that the descriptor information can come from anywhere in your system that you’re able to detect/predict it.
Thank you, Sir. You are correct that the way I am approaching has a fundamental issue and probably has nothing to do with UVM itself. I was a bit fixated on the fact that driver gets direct information about where what information is kept and not the monitor. I was also trying to do process a whole lot of information in monitor to make scoreboard simple.
I stepped back and took a look at the testbench architecture once again. While this specific driver gets information from test/sequence about descriptor and data, the DUT is initiated for DMA transfer through another interface (that is another agent).
So, I will keep the monitor (in question) simple and have it just send transaction information as it is to scoreboard. The other agent will send register transfers to DUT and also to the scoreboard. This is sufficient for scoreboard to decipher complete details.
Also, I have a comment on your comment to have driver send information to scoreboard.
I beg to differ here. Having driver send this information to scoreboard would make it difficult to re-use this environment at the next level, which is one of the primary reasons why I raised this question.
I’d take even one more step back and ask myself the following questions:
Who supplies the driver the information as to which address which descriptor maps to? More importantly, how does the DUT get this information? If it’s not needed by the DUT (as you said it only gets address and data), why do you need to consider it in your scoreboard?
Is descriptor information stored in some DUT registers? Then you can monitor that using the register model and use it to reconstruct descriptor information from addresses.
In reply to verif_learner:
I’d take even one more step back and ask myself the following questions:
Who supplies the driver the information as to which address which descriptor maps to? More importantly, how does the DUT get this information? If it’s not needed by the DUT (as you said it only gets address and data), why do you need to consider it in your scoreboard?
Is descriptor information stored in some DUT registers? Then you can monitor that using the register model and use it to reconstruct descriptor information from addresses.
yes, that’s is what i figured. There is a register agent which sends configuration info to DUT.