Can a driver have an analysis port to collect information from a modelled checker

UVM
,
1

I am working on a driver which needs to use the Timer modelled in UVM via an analysis port. Is this acceptable?

2

In reply to dsherlek:

Your question is vague. We have no idea what kind of information you need to collect and how often. There are many different mechanisms for communication in the UVM, and it is best to limit what you do unless you have compelling reasons for a particular one. What do you think would not be acceptable about what you want to do?

3

In reply to dave_59:

I am writing a UVM driver for a Flow. It needs to wait for a timer expiration. Since the Timer expiration is modelled in our environment via monitoring internal signals. I would like to use the timer expiration completed value from this monitor to the driver to proceed with the flow.

I have seen in the past that Analysis ports in the driver are not preferred. Is that the case? If Yes, what would be a good way of implementing hte same?

4

In reply to dsherlek:

Usually the thing that is not preferred is having a monitor affects the stimulus to the DUT.; monitors are supposed to be passive. And depending on the block to system level reuse that you need in a agent (i.e. if the driver is turned off in a passive agent), a monitor should not depend on the driver for the monitor to function properly.

But sometimes a driver depends on a monitor to function properly. So either you duplicate the functionality in the driver (also not preferred), or let the monitor feed the driver, which is probably your best option.