Jim, Thank you for clarification of this construction. My reading was similar but now I have certainty that others read it likewise, Radek _____ From: Jim Vellenga [mailto:vellenga@cadence.com] Sent: Friday, October 11, 2013 5:13 PM To: Radoslaw Nawrot; sv-cc@eda.org Cc: Przemek Cichon Subject: RE: [sv-cc] Name of t/f vpiRefObj Radek, I don't know if you got an answer on this or not. I am writing to you from my own reading of the standard, so what I'm saying does not represent the agreed-on understanding of the committee. In "37.15 Reference objects", detail 2 says "A ref obj may be obtained . when traversing an expression that is a use of such ref obj, or when accessing the io decl of an instance or task or function." It appears to me that the argument "x" to the user-defined task $vpi() is a "use of such ref obj," and therefore should be treated as a vpiRefObj just as the argument to the function "tsk" is. And from detail 3, "The name of ref obj can be different at every instance level it is being declared. The vpiActual relationship always returns the actual instantiated object if the ref obj is bound to an actual object at the time of the query." In the context, it looks like the vpiActual is reserved for the object at the end of the vpiRefObj chain -- that is, the "vpiVariable from the top layer," as you said. Jim Vellenga From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Radoslaw Nawrot Sent: Wednesday, April 24, 2013 3:07 AM To: sv-cc@eda.org Cc: Przemek Cichon Subject: [sv-cc] Name of t/f vpiRefObj Hello, I have problem with LRM interpretation. SV example: module top; bit b; task automatic tsk(ref x); $vpi(x); endtask initial tsk(b); endmodule From $vpi argument: vpiType == vpiRefObj vpiName == x vpiDefName == b And vpiActual relation gives be : vpiBitVar with vpiName == b Am I right? Or maybe if $vpi argument should be vpiName ==b , vpiType ==vpiBitVar? And 2nd question: If I pass variables via few ref's vpiActual should return the near vpiRefObj or vpiVariable from top layer ? Regards, Radek -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, 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 Mon, 14 Oct 2013 08:39:46 +0200
This archive was generated by hypermail 2.1.8 : Sun Oct 13 2013 - 23:42:05 PDT