Why active agent and passive agent?

[cliffc]

It is very common to include two identical agents in a UVM testbench. One uses a default-active sequencer-driver pair and the other sets an is_active bit to uvm_passive to disable the sequencer-driver pair. Both monitors are identical and sample the VIF signals to re-assemble a standard transaction that is then sent through the monitor-analysis port to the agent-analysis port and on to both sides of the scoreboard.

 

Since the analysis port can write to multiple analysis export/imp-ports, when building simple UVM testbenches, why not just use one active agent that drives both sides of the scoreboard and discard the passive agent?

 

Regards - Cliff Cummings

[tudor.timi]

It's unclear to me what you mean. Do you have a device with two (almost) identical interfaces, where traffic flow only in one direction?

      _______
IF1  |       |  IF2
---->|  DUT  |---->
     |_______|

In this case it makes sense to instantiate 2 agents, because you have 2 different wire bundles. 

 

If not, do you have only one bidirectional interface?

      _______
IF1  |       |
<--->|  DUT  |
     |_______|

In this other case you only need one agent. You can have one monitor feed the scoreboard through an analysis port and the scoreboard itself would figure out what is RX and what is TX (based on the item direction).

[David Black]

Cliff,

 

No good reason that I can see. When you migrate a model to the SoC level (where driving is inappropriate), just change the agent to passive.

[robert_at_verilab]

I have frequently seen this testbench structure, in which an active agent is used to drive stimulus to the DUT and a passive agent is also instantiated alongside, and I have also wondered at this apparent use of a duplicate monitor with no obvious benefit.
This structure is frequently recommended by VIP vendors in the User Guide documentation and I have seen it often enough in that guise to conclude that it is relatively common.
I was lucky enough recently to be able to pin down a representative from one such vendor and grill him on exactly that question: why did his user documentation require me to instantiate two agents with identical monitors on the one bus? His answer was to the effect that the VIP is basically doing two things: firstly it is modelling an external component that will provide stimulus to the DUT and secondly it is modelling (or reflecting) the DUT itself. The first of these two tasks is given over to the active agent and the second to the passive agent.
In Cliff's original example he talks only about the passive monitor supplying DUT responses to a scoreboard, but in many examples that I have seen, the modelling or reflection of the DUT is far more complex, including perhaps modelling of the DUT register set and other internal state and prediction of responses on other interfaces, or whatever functionality the DUT might possess.
Now, while that answer does not present a technical reason why one can't use the same monitor for both tasks, it does, in my opinion, hint at a valid psychological reason. One of the key challenges in architecting a testbench is in allowing the verification engineers that will work on it an intuitive grasp of its structure, in terms of which parts of the testbench perform what function and why. I'm a big advocate of "separation of concerns" as a means to achieve clarity, and if clarity comes at the expense of an additional monitor then perhaps it's not such a big sacrifice - until it starts to hurt performance, maybe!

 

Regards, Robert.

 

[tudor.timi]

Now that Robert mentioned it, I also remember seeing VIP from one vendor that did such a separation of concerns. An active agent would be used to drive stimulus on an interface with a handshake mechanism. A passive agent hooked onto the same interface would monitor the DUT's handshakes and check that everything is in order. You could tap any of the monitors to feed the scoreboard, since they both collect the same thing.