I have a protocol in which i have to check start,capture address of slave,capture r/w bit (implemented in monitor) and then depending on the read/write bit(in monitor) i have to either drive data onto the SDA line or sample the SDA line.So is it possible to drive interface level signals from the monitor?
1)Is there a need of a driver to generate the read transactions and generate acknowledge bit?
2)Can these be done within the monitor or do i need to sample and check these conditions again and then drive inside the driver?
UVM in general, monitor should only monitor the signals (signals shall be used in input mode ONLY). User shall not drive the interface from the monitor component.
Even though, there is no mechanism in UVM that will not allow user to drive the signals from monitor. You can drive the signals from monitor depend on how you design your interface (ie, you have signal with output mode in the monitor modport).
In UVM if you want to drive the signals, the information shall come from the sequence_item, which is passed through the sequencer. And only the driver has the built in seq_item_port, which means by default only driver is the one that can drive signals. It is possible to enable the connection between sequencer and monitor if you want (but, it is highly not recommended).
With that said, you can drive the signals from monitor if you really want with some strong reason, and it will never being used PASSIVE mode. But, it is highly not recommended to drive signals from the monitor. As. monitor is the only component that shall be created in PASSIVE mode, and any agent shall not drive the signals in PASSIVE mode.
For your case, I think the better solution will be, your agent should have the master and slave driver. Where in master driver will take input from sequencer and drives the request, and the slave should just response to the request (ie, drive back the read data). The slave should have the function that user can set callback for the read data. And if the callback is not set, it should send the previously written data, OR random data OR fixed value data (you should design in the way you want). And the monitor should just monitor the transactions as usual.
Hi Christie,
Baser is correct in saying that a monitor should only read the input signals, and that it’s up to the driver to get the transaction from the sequence and drive the bus. It sounds like you need to implement a Slave sequence, which is discussed in the UVM Cookbook here.
Good luck,
-Tom
I don’t think I have understood how to trigger this slave sequence and how it can be ended. I meant, does this need to be an infinite sequence ? When does this sequence stop. In the example it is given as repeat(n). If I wrap this sequence in fork_join then the test ends even before the slave response is driven. On the other hand, if I make it infinite sequence by putting fork_join_none, then test hangs as there is no blocking statement in the sequence. Please correct my understanding.
the article mentions a “responder”. If I understand this subject correctly, a responder is like a “driver” in that it actively drives the interface, but unlike the master side driver, doesn’t drive based on the sequence item from the sequencer, but rather based on the signals observed on the interface.
if there is configuration of the responder needed, this can be done by adding variables to the agent’s cfg object, or by passing a responder sequence item from the responder’s sequencer.
or use one sequencer and look at the active /passive mode to know whether the items are for the driver or responder.
or configure the driver to do only responding in passive mode, and only driving in active mode. ??