Connection between driver and monitor

UVM
1

Hi All,
I have written a code of Agent in which i have included three modules i.e.Driver, Sequencer and Monitor. Now i have to make a connection between Driver and monitor.Which is the best possible way to do so.

Thanks in advance

2

In reply to arju singh:

There should be no connection between the driver and the monitor. They should be two distinct components designed to function independently.

They will both use the same virtual interface handle, but the driver will be used to both read and write signals in the interface while the monitor will only read signals.

3

In reply to cgales:

Exactly! And in hierarchical designs, one will have monitors on internal busses, without drivers. So the monitor has to be able to function without the driver being active.

Also: since those monitors will be attached to internal busses: put any assertions in the SV Interface code, so that the assertions can be active on those internal busses. If you put assertions in the driver, then they can’t be used except at the primary IO of the DUV.

4

In reply to erik.k.jessen@raytheon.com:

I think you NEED a master agent and a slave agent. The slave agent works in passive mode (only monitor work) . Master agent drive your DUT through VIF and the slave agent just working in passive mode, it can collect data through VIF. And then write to analysis port which connected to your scoreboard.

5

In reply to TingWang:

I’m used to the following:
a) driver (configures to master or slave)
b) monitor (does nothing but watching bus; it doesn’t know/care if driver is master or slave)

Master-driver example would be: I2C or SPI initiating a transaction.
Slave-driver example would be: responding to a I2C or SPI transaction.

The monitor is used in all cases, and is the only thing used in cases where one is monitoring a bus internal to the DUV.

An example would be:
One has built block-level testbenches for blocks A, B, and C. Complete with predictors for each.
One then builds a chip from blocks A, B, C. There are busses internal to the chip that go between A/B/C. One needs monitors on those internal busses (and the monitor is neither master nor slave, since master is driven by RTL, as well as slave).

But I think we are just differing on how to partition the functionality.

6

In reply to erik.k.jessen@raytheon.com:

Hi Erik,
I fully agree with you, actually my original intention is reply to arju. I just give her a example of typical connection between driver , DUT and monitor :)

7

In reply to arju singh:

Hi Arju,
As ‘cgales’ said, Drivers and Monitors are totally independent components on Agent. Only one common thing is, both component shares the same Virtual Interface for their action. Driver Will do transaction with DUT through the interface. At the same time the Monitor will collect those transactions from the interface and forward it to the higher connected components like functional coverage/scoreboard/another monitors through analysis port if any.

In connect phase on Agent , you have make sure that you have connected your driver with appropriate sequencer and at the same time you have to make sure that you connected the all   analysis ports of monitors with the appropriate components like scbd/fc/layer monitor's analysis exports if any.

No need of any connection between Driver and Monitor since both are not having any business with each other.

Thank you.

8

To summarize the ideas, the main arguments of not sending data from driver to monitor are following

  1. Monitor should be able to function without driver. If driver is in off mode, or we change the driver than the monitor should be able to function.
  2. Assume there is some issue in driver when delivering data to interface. Than it would be much easy to catch such type of issues while monitor and driver are separate i.e. monitor is not getting the data from driver
  3. In case monitor gets DUT input data from driver, than each time we modify/update the driver we have to change the data sending part in driver also. Kind of some extra work.

→ So the best way to have separate monitor which will track DUT inputs.

The other suggestion was adding passive agent which will track DUT inputs. To be honest I don’t know what are the benefits of this solution? Why somebody needs to add some extra hierarchy in his code.
Please if you know some benefits of having passive agent in UVM, that would be great.

Thanks
Hayk

9

In reply to haykp:

A passive agent is still an agent, but one that doesn’t instantiate a driver and sequencer. This is useful when integrating a unit testbench at the next level, where the driver may now actually be another DUT. Hope that helps.

10

In reply to arju singh:

I know this is a very old thread, but I wanted to clarify the intent. Were you looking to share code between the driver and monitor? If so, then the reasons given by those above are valid and both components should be separate. The monitor needs to be independent so that it can be reused in a passive agent at a higher level, only listening to transactions and sending them to analysis components (coverage, scoreboards etc).

However, if you’re talking about a reactive slave that needs to wait on some signals from the DUT, then you may want to look at this paper here. The idea is to connect the monitor to the sequencer, and then use the sequencer to send transactions to the driver as usual.

Hope this helps!