SystemVerilog interface: virtual and ref

D

Davy

Guest
Hi all,

When studying SystemVerilog, some book said 'virtual' is used to get
the reference of the interface. But why the language not use 'ref' to
get interface reference? And what's 'virtual interface' actually mean?
Thanks!

For example,
class eth_mii_mac;
local virtual eth_mii_if sigs;
task new (virtual eth_mii_if sigs);
this.sigs = sigs;
endtask: new
.... ...
endclass: eth_mii_mac

Best regards,
Davy
 
Hi,

I guess maybe they want to seperate property(data) with
class/interface/function/task (data and routine).

property(data) -> reference
class/interface/function/task -> virtual

Any comments are welcome!
Davy

sharp@cadence.com wrote:
Davy wrote:

When studying SystemVerilog, some book said 'virtual' is used to get
the reference of the interface. But why the language not use 'ref' to
get interface reference?

I agree that it is a strange choice. However, 'ref' generally means a
pass-by-reference argument. So what would you use for a virtual
interface variable passed by reference, 'ref ref interface'?
 
On 29 Oct 2006 02:23:57 -0800, "Davy" <zhushenli@gmail.com> wrote:

Hi all,

When studying SystemVerilog, some book said 'virtual' is used to get
the reference of the interface. But why the language not use 'ref' to
get interface reference? And what's 'virtual interface' actually mean?
Don't get me started...
<rant> "virtual interface" is a really stupid name;
as you correctly say, "ref interface" would have been far more
sensible. However, it's too late now and we're stuck with it.
</rant>

A "virtual interface" (or, simply, a "virtual") is just a variable
that contains a reference to an existing interface instance.
That reference can be moved around dynamically so
that it can point to different interface instances at
different times during the simulation. In practice, classes
that need to talk to interfaces will usually do so via a
variable of "virtual interface" type. This makes it possible
for class objects (and, in particular, a test environment)
to choose *at run time* how they connect to the device
under test. Without virtual interfaces, all the connectivity
is determined statically at elaboration time, and therefore
can't be randomized or reconfigured.

The VMM book has clear descriptions of how
to use "virtual" to access components of an interface
with the help of a clocking block in the interface,
passed through a modport of that interface. It sounds
complicated, but in practice it's easy to use and
works well. It gives you clean isolation between
a class-based testbench, running in a program block,
and a device-under-test and its test harness,
written in modules.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
Davy wrote:
When studying SystemVerilog, some book said 'virtual' is used to get
the reference of the interface. But why the language not use 'ref' to
get interface reference?
I agree that it is a strange choice. However, 'ref' generally means a
pass-by-reference argument. So what would you use for a virtual
interface variable passed by reference, 'ref ref interface'?
 
On 2 Nov 2006 13:06:43 -0800, sharp@cadence.com wrote:

Davy wrote:

When studying SystemVerilog, some book said 'virtual' is used to get
the reference of the interface. But why the language not use 'ref' to
get interface reference?

I agree that it is a strange choice. However, 'ref' generally means a
pass-by-reference argument. So what would you use for a virtual
interface variable passed by reference, 'ref ref interface'?
Yes, exactly so. And I would use typedef to avoid the ugliness,
just as I would do with multiple packed dimensions (for example).

BTW I haven't tried this, but I assume it's OK to do

typedef virtual MyInterface MI_ref;

so that the "virtual" keyword is cordoned-off in
an out-of-the-way place where it can do less visual harm :)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 

Welcome to EDABoard.com

Sponsor

Back
Top