Virtual interface and multiple drivers (signal drivers not UVM drivers)

UVM
, ,
1

I have an interface that has modports for UVM driver component and also for DUT.
The UVM driver modport has signals that are all output except for one signal that is input (driven by the DUT).
As expected, the DUT has all input signals except one signal that is output from the DUT.

Now, I am planning to use the DUT modport interface in the monitor also.
The monitor needs all output signals driven by the UVM driver. It does not need the one signal that is output of DUT.

In this scenario, the monitor is going to have a modport with one output signal. Will this create multiple driver condition.
I went through the LRM but could not find any description as to how drivers for virtual interfaces are created and how multiple drivers are resolved.

Thanks,

2

In reply to verif_learner:

I find that modports provide no real benefits, yet add unnecessary complexity, especially when used in a UVM environment. Because of this, I see no reason to use them.

You will typically only get warnings/errors when you multiply drive a signal by assign statements or connecting multiple registers. Port connections won’t generally create issues since the input/output notation are merely suggestions.

3

In reply to cgales:

I thought modports are very convenient and a way to specialize a given interface.
Any digital HW block has signal of 3 types (input, output, input_output).
Without modport, this basic direction of any signal cannot be specified.

This is my understanding. Let me know what issues you see.

4

In reply to verif_learner:

Modports are useful when designing synthesizable hardware blocks. For verification, they are of limited use and add confusion and complexity.

When interfaces used for verification are connected to the DUT, you will typically instantiate the interface, then connect it to the DUT as below:


interface my_if(input bit clk, input bit rst);
  wire a;
  wire b;
endinterface

my_if my_if_i(.clk(clk), .rst(rst));

dut dut_i(.clk(clk),
          .rst(rst),
          .a(my_if_i.a),
          .b(my_if_i.b)
);

Using a modport adds no additional benefit. You need to add another hierarchical name that isn’t necessary.

5

In reply to cgales:

Hi,
What about clocking block? I think it is more widely used.
Please let know your thoughts on skew also.

Regards,
Chandan

6

In reply to cgales:

In reply to verif_learner:
Modports are useful when designing synthesizable hardware blocks. For verification, they are of limited use and add confusion and complexity.





I am opening this thread.
When modports are used in agents, one can make the mistake of driving input ports etc.
So, I am wondering as to why this is not an advantage in using modports
7

In reply to verif_learner:

In reply to cgales:
I am opening this thread.
When modports are used in agents, one can make the mistake of driving input ports etc.
So, I am wondering as to why this is not an advantage in using modports

modports adding nothing else as checking of the data direction. But this is one thing you’ll see this immediately when you are driving an output indicated by an error.
I have never used modports in all my projects.

8

In reply to chr_sue:

In reply to verif_learner:
modports adding nothing else as checking of the data direction. But this is one thing you’ll see this immediately when you are driving an output indicated by an error.
I have never used modports in all my projects.

Thanks. Can you give a sample code for an interface that has signals and clocking blocks and no modports?

I can use it as a reference. I have always used signals from interface using the modports. So, I would like to see one without it.

9

In reply to verif_learner:

I want to ask only 1 question: what is the difference between a signal driver and a uvm_driver?