Getting multiply-driven warnings from vsim with passive agent

UVM
, , ,
1

I don’t know what’s causing this or how to pin it down. I have an interface with producer, consumer, and monitor clocking blocks and modports. Most go from my DUT to agents that instantiate drivers or receivers based on an env member or just a monitor is is_active== UVM_PASSIVE. A couple of interfaces go to an RTL model so they are set to UVM_PASSIVE. However, for those interfaces, I’m getting warning like this:

** Warning: (vsim-3839) my_if.sv(xx):

Variable ‘/tb_top/my_if[yy]/ZZZ’, driven via a port connection, is multiply driven.
See my_rtl_model.sv(xx).

Region: /tb_top/my_if[yy]

In my_rtl_model, the port ZZZ is an output. In my DUT, it’s an input. In tb_top, the actual to the port of the instance of my_rtl_model is a modport where ZZZ is an output. And, in my agent, if is_active==UVM_PASSIVE, I only instantiate the monitor which only has inputs for the interface.

Any idea how to get a better idea of what QuestaSim is complaining about?

Thanks,

David

2

In reply to drogoff:

Could you please explain the difference between my rtl_model and your DUT.

3

In reply to drogoff:
The warning you are getting is from the compiler before the
is_active flag gets set during simulation. When it comes to procedural code the compiler does not know what source code will or will not get executed. It has to generate the machine code to execute everything.

without seeing the actual code, the only thing I can suggest to change the code to make it work in for any setting of
is_active. That might mean changing the interface signal to a wire.

4

In reply to chr_sue:

DUT is the RTL module being tested.
rtl_model is another RTL module that is needed as part of the testbench but isn’t being tested.

FYI, looks like Dave has the answer. I’ll post a response to his in a minute.

5

In reply to dave_59:

In reply to drogoff:
The warning you are getting is from the compiler before the
is_active flag gets set during simulation. When it comes to procedural code the compiler does not know what source code will or will not get executed. It has to generate the machine code to execute everything.
without seeing the actual code, the only thing I can suggest to change the code to make it work in for any setting of
is_active. That might mean changing the interface signal to a wire.

Yep - that was it. This also explains why I see examples of SV Interfaces with the signals declared as wires and not logic. I couldn’t figure out why this was being done since, with modports, no signal was bidirectional or multiply driven. Now it makes sense although it’s a bit ugly.

Thanks!

David

6

In reply to drogoff:

In reply to dave_59:
Yep - that was it. This also explains why I see examples of SV Interfaces with the signals declared as wires and not logic. I couldn’t figure out why this was being done since, with modports, no signal was bidirectional or multiply driven. Now it makes sense although it’s a bit ugly.

Dave, this solution of using wires just hit a speed bump. In one of my agents using the interface and clocking blocks, I need to look for an input signal and change an output signal in the same clock cycle. This is to model the RTL which is combinatorial. I can’t figure out a legal way to do this. I tried driving my_vif.signal_a directly to avoid the clocking block delay but got an error since signal_a is defined as a wire in the interface. I also tried using $deposit, but this gave an error since the signal is automatic.

So, any suggestion on modelling one output signal in an interface being combinatorial?

Thanks,

David

7

In reply to drogoff:

I don’t know what you meant by the signal being automatic. You said you defined
signal_a as a wire, and there’s no such thing as an automatic wire.

You can try doing this inside your interface

wire signal_a;
logic signal_a_driver = 'z;
assign signal_a = signal_a_driver;

Then you can procedurally assign
signal_a_driver from your driver class, setting it back to 'z when you want to turn it off.

It’s hard to help you further without seeing more code. You may want to contact your local support group for more help where you can share all the necessary code.