RE: [sv-cc] vpiVirtualInterfaceVar and vpiClassVar as vpiRefObj

From: Jim Vellenga <vellenga@cadence.com>
Date: Tue Dec 17 2013 - 05:25:30 PST
Oh, and by the way, as of 1800-2012, a virtual interface variable is no longer a vpiRefObj, and neither are its selected members or elements.  See "37.27 Virtual interface" in IEEE Std 1800-2012.

Regards,
Jim Vellenga

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Radoslaw Nawrot
Sent: Tuesday, December 17, 2013 4:33 AM
To: sv-cc@eda.org
Subject: [sv-cc] vpiVirtualInterfaceVar and vpiClassVar as vpiRefObj

Hi All,
I was thinking about part of LRM:

"A ref obj represents a declared object or subelement of that object that is a reference to an actual instantiated object.

A ref obj exists for ports with ref direction, for an interface port, a modport port, or for formal task function ref

arguments. The specific cases for a ref obj are as follows:

- A variable, named event, named event array that is the lowconn of a ref port

- Any subelement expression of the above

- A local declaration of an interface or modport passed through a port or any net, variable, named event, named

event array of those

- A ref formal argument of a task or function, or subelement expression of it

"
I have an example:


module top;
 class C;
  int i;
 endclass
 function automatic void afct(ref C c);
  $vpiF(c.i);
 endfunction

 C x=new;

 initial #2 afct(x);

endmodule

Is "c.i" really a ref object ? "i" is a part of vpiClassObj not vpiClassVar.
Should LRM exclude from being ref object class and virtual interface member's ?

Regards,
Radek


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Dec 17 05:26:05 2013

This archive was generated by hypermail 2.1.8 : Tue Dec 17 2013 - 05:26:07 PST