System Verilog Interfaces: How to model a bus with 1 or more

[Andrew FPGA]

Hi,
We are verifying a VHDL DUT using System Verilog. We attach the class
based testbench hierarchy to the DUT via SV interfaces (virtual
interfaces) in the standard way. However, we have not figured out how
to model a bus with multiple drivers from procedural code?

Below is what we currently do for a cpu bus. The data bus must be
declared of type wire, because it can have multiple drivers. The DUT
drives data directly, but the class based testbench hierarchy can only
procedurally assign, hence the TB writes to bup_data_from_task
variable, which is then continuously assigned to data within the SV
interface. This works, but it does not work as expected for multiple
bus masters in the class based testbench. We get last assignment
"wins" behaviour i.e. whichever task/class assigned to
bup_data_from_task gets driven onto the bus. When really a proper
model would allow the TB to have multiple drivers and then a
conflicted state on the bus.

There must be a way to model tristate/multiple TB drivers in System
Verilog using SV interfaces? But we havn't figured it out yet... Any
ideas on how to do this?

interface cpu_bus_if();
wire[7:0] data; //dut bup_data port is of inout type, so can
have multiple drivers. Thus must be wire type, not logic.
logic[10:0] addr = 0;
...

logic [7:0] bup_data_from_task = 8'bz;
assign data = bup_data_from_task;
endinterface : cpu_bus_if

Cheers
Andrew

 

[Jonathan Bromley]

Andrew

we have not figured out how to model a
bus with multiple drivers from procedural code?

A virtual interface connection will always represent
only one driver. if you want to model multiple drivers
from your testbench, you will need multiple instances
of the interface - one for each driving class. Each
class gets a different virtual interface reference,
and drives its own interface independently of any
other classes. Standard Verilog wire resolution
then resolves among the various interfaces' drivers.
Any class that wants to avoid driving the bus should
of course write Zs to its interface.

Alternatively, put multiple clocking blocks into
the interface and hook each class to just one of
the clocking blocks. That provides a convenient
way of allowing procedural writes to a wire; the
clocking block automatically adds a continuous
driver on to every net that it drives. However,
this arrangement is much harder to manage than
multiple independent interfaces, so I suggest
it's not such a good idea.

HTH
--
Jonathan Bromley

 

[Andrew FPGA]

Brilliant - so simple. Why couldn't we think of that! Thanks Jonathan.
Cheers
Andrew

On Aug 2, 11:38 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

Andrew

 we have not figured out how to model a
bus with multiple drivers from procedural code?

A virtual interface connection will always represent
only one driver.  if you want to model multiple drivers
from your testbench, you will need multiple instances
of the interface - one for each driving class.
Jonathan Bromley