Beruflich Dokumente
Kultur Dokumente
Search form
Log In (/user/login?destination=forums/systemverilog/why-do-we-need-virtual-interfaces-system-verilog)
Topics
Courses
Forums
Patterns Library
Cookbooks
Events
Register >
More
Home (/) / Forums (/forums) / SystemVerilog (/forums/systemverilog) / Why do we need virtual interfaces in system verilog?
1935 (/forums/systemverilog)
mseyunni
Full
Access
126 posts
Hello,
Can someone tell me why do we need virtual interfaces. It is not very clear to me after reading about
virtual interfaces in number of places in LRM, books etc. Basically I would like to understand what is
that that we can't do with interfaces which we can do with virtual interfaces ?
Can someone explain the background for the introduction of virtual interface in the language?
Thanks,
Madhu
Replies
Order by:
Newest Last
A virtual interface is a pointer to an actual interface in SystemVerilog. It is most often used in classes
Solution
to provide a connection point to allow classes to access the signals in the interface through the virtual
interface pointer.
tfitz
Forum
Moderator
382 posts
You can see some examples of how to use virtual interfaces in the UVM Cookbook
(https://verificationacademy.com/cookbook/connect/virtual_interface).
Good luck,
-Tom
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfaces-
1 of 12
12-Dec-16 9:32 PM
system-verilog#answer-39287)
Solution
Quote:
Can someone tell me why do we need virtual interfaces
ben@SystemVerilog.us
Full
virtual interfaces come into play when using classes to defer at a later stage the definition of the
Access
681 posts
physical interface to the one being worked on in the class.
The other advantage is that a class can be instanced multiple times and connect to different physical
November 19, 2013 at 9:32 am
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-39288)
interfaces.
1800 wrote:
25.9 Virtual interfaces
Virtual interfaces provide a mechanism for separating abstract models and test programs from the
actual signals that make up the design. A virtual interface allows the same subprogram to operate
on different portions of a design and to dynamically control the set of signals associated with the
subprogram. Instead of referring to the actual set of signals directly, users are able to manipulate
a set of virtual signals. Changes to
the underlying design do not require the code using virtual interfaces to be rewritten. By
abstracting the connectivity and functionality of a set of blocks, virtual interfaces promote code
reuse.
kansagaratushar
Full
Access
13 posts
Physical interface in not supported in Object Oriented Programming (OOP) Fundamentals.So, This
virtual interface concept came into the picture to use signals of interface.
mseyunni
Full
Access
126 posts
2 of 12
12-Dec-16 9:32 PM
system-verilog#answer-46713)
In reply to ben@SystemVerilog.us (https://verificationacademy.com/forums/systemverilog/why-do-we-needvirtual-interfaces-system-verilog#reply-39288):
Hi Ben,
Can you please elaborate on what you said above, may be with an example.
Thanks,
mseyunni
Full
Access
126 posts
system-verilog#reply-39287):
Thanks Tom.
November 20, 2013 at 8:25 am
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-46714)
ben@SystemVerilog.us
In reply to mseyunni (https://verificationacademy.com/forums/systemverilog/why-do-we-need-virtual-interfacesFull
Access
system-verilog#reply-46713):
681 posts
Quote:
November 20, 2013 at 10:35 am
Can you please elaborate on what you said above, may be with an example.
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-46715)
3 of 12
Ben wrote:
virtual interfaces come into play when using classes to defer at a later stage the definition of the
physical interface to the one being worked on in the class.
The other advantage is that a class can be instanced multiple times and connect to different
physical interfaces.
As mentioned previously, you cannot refer in a class an actual interface. Consider a system with two
redundant identical buses. Both may be active, thus serving different DUTs, or they may be redundant
for self-checking, where the passive bus has its drivers inactive (i.e., the driver is in monitor/checking
mode). Below is such an example.
12-Dec-16 9:32 PM
virtual
...
extern virtual function void connect_phase(uvm_phase phase);
endclass : mem_agent
function void mem_agent::connect_phase(uvm_phase phase);
//...
this.driver1.vif = this.mem_if_1;
this.driver2.vif = this.mem_if_2;
endfunction : connect_phase
jonnajagadeesh
Full
Access
1 post
Interface signals are static ( Physically available ) & where Class are dynamic and which needed
virtual interface to communicate the actual interface signals
Reuben
Full
Access
159 posts
4 of 12
12-Dec-16 9:32 PM
Hi tfitz,
Does it mean that by declaring the interface as virtual then all classes using that interface will obtain
the same values?
For example, driver will put a value on the virtual interface, then the monitor will get the same value
also.
Is this the reason why virtual is used for the interface?
Thanks.
Regards,
Reuben
bdreku
Full
Access
53 posts
The interface is used to simplify the connection between DUT and Testbench. As the interface can't
be instantiated inside a class or program block, we need a virtual interface to point the physical
interface.
So, the virtual interface is a pointer to the actual interface and using virtual interface, a class can point
to different physical interfaces, dynamically (at run time).
/forums/systemverilog/why-do-
we-need-virtual-interfaces-
system-verilog#reply-49570):
system-verilog#answer-51058)
Quote:
Does it mean that by declaring the interface as virtual then all classes using that interface will
obtain the same values?
For example, driver will put a value on the virtual interface, then the monitor will get the same
value also.
Yes, using virtual interface, it is possible that the data driven by the driver is available to monitor, if the
same instance of an interface is passed to both.
H.Modh (http://stackoverflow.com/users/3840473/h-modh?tab=profile)
mallick1
Full
Access
8 posts
system-verilog#question-31424):
5 of 12
Well, you dont. You can easily connect module ports to class members by dotting into the module.
You could also 'define the module signal in order to get a single place to change when you change
12-Dec-16 9:32 PM
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-52582)
mseyunni
Full
Access
126 posts
system-verilog#reply-52582):
Well, you dont. You can easily connect module ports to class members by dotting into the module.
February 22, 2016 at 10:40 am
You could also 'define the module signal in order to get a single place to change when you change
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfaces-
virtual Interface_Name foo; can save the name for you, which you can use as a generic foo.
system-verilog#answer-52584)
dave_59
Forum
Moderator
4004 posts
system-verilog#reply-52582):
Quote:
February 22, 2016 at 10:45 am
(https://verificationacademy.com
Well, you dont. You can easily connect module ports to class members by dotting into the module.
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-52585)
This is the crux of the issue. If you are putting classes in a package, you can't have hierarchical
references (dotted names) inside a package, and even if not using packages, you should not be
putting in hierarchical reference inside to make your testbench re-usable. A `define won't work if
several instances of the class needs to connect to different places in the design.
mallick1
Full
Access
8 posts
system-verilog#reply-52584):
Responding to seyunni, you can easily drive a module wire from within a task member of a class as
February 22, 2016 at 1:47 pm
follows
(https://verificationacademy.com
6 of 12
task drive();
12-Dec-16 9:32 PM
/forums/systemverilog/why-do-
@(posedge clk)
we-need-virtual-interfaces-
dut.signal <= 1;
system-verilog#answer-52588)
ben@SystemVerilog.us
In reply to mallick1 (https://verificationacademy.com/forums/systemverilog/why-do-we-need-virtual-interfacesFull
Access
system-verilog#reply-52588):
681 posts
I disagree with your statement "you can easily drive a module wire from within a task member of a
February 22, 2016 at 2:10 pm
class as follows
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-52591)
7 of 12
task drive();
@(posedge clk)
dut.signal <= 1;
Below is an example from my SVA book on verifying assertions. See the task is_illegal;
12-Dec-16 9:32 PM
8 of 12
12-Dec-16 9:32 PM
mallick1
Full
Access
8 posts
virtual-interfaces-system-verilog#reply-52591):
The example you are showing has got to do with continuous assign contention and that is true.
/forums/systemverilog/why-do-
we-need-virtual-interfaces-
The question asked here has got to do with the question virtual interface existance in the language, at
system-verilog#answer-52598)
ben@SystemVerilog.us
In reply to mallick1 (https://verificationacademy.com/forums/systemverilog/why-do-we-need-virtual-interfacesFull
Access
system-verilog#reply-52598):
681 posts
Your initial statement was "drive a module wire from within a task"
(https://verificationacademy.com
You clarified by stating "legally driveable, i.e. needs to be an input wire or NOT a wire." What about
/forums/systemverilog/why-do-
driving an inout port of a module when the state is in the input mode?
we-need-virtual-interfaces-
Again, you can't do that from within a task, regardless of where the task is (i.e., in a module or a
system-verilog#answer-52599)
class instance).
SystemVerilog interface do have wires too.
Ben Cohen SystemVerilog.us
mallick1
Full
Access
8 posts
9 of 12
12-Dec-16 9:32 PM
Hi Ben,
You are right.
In my mind, the legally drivable statement covers the wire/reg caveats.
Thanks for your point about inout wire port configured as input.
I am surprised as to why you say this is not drivable from a task. hope you can elaborate
I have been driving inout ports with ff->(reg q)->(inout wire net) all the time.
Soummya
Reuben
Full
Access
159 posts
I like what Dave said regarding the disadvantage of using dotting to drive a signal. I was using that
before in my testcase, test.env.agt.drv.signal <= 1'b1. But now I think I should not since the test will
not become reusable.
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-52603)
ben@SystemVerilog.us
In reply to mallick1 (https://verificationacademy.com/forums/systemverilog/why-do-we-need-virtual-interfacesFull
Access
system-verilog#reply-52600):
681 posts
I can't easily locate where in 1800 those rules are defined. However, with 2 separate simulators, I get
the same errors for the following code:
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfacessystem-verilog#answer-52604)
10 of 12
12-Dec-16 9:32 PM
Ben
ben@SystemVerilog.us
In reply to ben@SystemVerilog.us (https://verificationacademy.com/forums/systemverilog/why-do-we-needFull
Access
virtual-interfaces-system-verilog#reply-52604):
681 posts
The LRM says in many places that A net cannot be procedurally assigned. (6.5 Nets and variables)
(https://verificationacademy.com
/forums/systemverilog/why-dowe-need-virtual-interfaces-
An the LRM says that 23.3.3.2 Port connection rules for variables
system-verilog#answer-52605)
11 of 12
12-Dec-16 9:32 PM
mallick1
Full
Access
8 posts
virtual-interfaces-system-verilog#reply-52605):
ex1: [Net type cannot be used on the left side of this assignment]
/forums/systemverilog/why-do-
we-need-virtual-interfaces-
initial x <= 1;
system-verilog#answer-52628)
12 of 12
Sitemap (/sitemap)
Terms & Conditions (https://verificationacademy.com/terms-and-conditions)
Verification Horizons Blog (http://www.verificationhorizonsblog.com)
LinkedIn Group (http://www.linkedin.com/groups/Verification-Academy-4668056)
12-Dec-16 9:32 PM