RE: [sv-cc] Callbacks on virtual interface var - proposal

Francoise,Jim,
Thanks for Your answers
Of course there are are objects without value which can be used in
cbValueChange like vpiNamedEvent, but is it correct solution? 
My proposal was based on cbReclaimObj to do not multiply callback reasons
but maybe  new callback reason should be provide - callback on prefix change
(vpiPrefix - 2012 feature) ?
I appeal to the community SV-CC, as the more experienced, to choose the best
solution,
 
Regards,
Radek
 
  _____  

From: Jim Vellenga [mailto:vellenga@cadence.com] 
Sent: Tuesday, September 03, 2013 2:47 PM
To: Francoise Martinolle; Radoslaw Nawrot; 'Bresticker, Shalom';
sv-cc@eda.org
Subject: RE: [sv-cc] Callbacks on virtual interface var - proposal



A drawback of Shalom's proposal for using cbCreateObj and cbReclaimObj is
that it doesn't cleanly identify the "object" associated with the virtual
interface variable.  Presumably the interface being pointed to doesn't go in
and out of existence as a class obj does.

 

Also, the fact that a class obj or interface object does not have a value
doesn't prevent us from using a cbValueChange callback.  As noted in the
description of the cbValueChange callback, the format field can also be set
to vpiSuppressVal if "value information is not needed."  So I think that
would be a more natural way of dealing with changes in valueless objects
such as class objects and targets for virtual interface variables.

 

Regards,
Jim V. 

 

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
Francoise Martinolle
Sent: Monday, September 02, 2013 3:08 PM
To: Radoslaw Nawrot; 'Bresticker, Shalom'; sv-cc@eda.org
Subject: RE: [sv-cc] Callbacks on virtual interface var - proposal

 

Hi Radoslaw,

 

I agree that we need to detect when a virtual interface variable  gets
assigned a different interface instance or a virtual interface variable. 

This is a simulation event that we should be able to track.

This is a little difficult since a value for a virtual interface variable is
either an instance or another virtual interface. What is the value for an
interface instance? VPI standard says that virtual interface variables and
class variables do not have values. The detection of an event on a class
variables is done with the callbacks you mentioned cbCreateObj and
cbReclaimObj., but these callbacks to not apply very well to a virtual
interface variable. A virtual interface variable is not a dynamic object, it
will either be null or point to an instance of an interface that always
exists. The virtual interface variable is statically elaborated (unless it
is an automatic variable) so it will always have a defined value.

I think that the value needs to be defined by the VPI standard and that
value needs somehow to represent an interface instance. Using value change
callbacks should then be giving you what you need.

 

Francoise

        '

 

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Radoslaw
Nawrot
Sent: Monday, September 02, 2013 3:34 AM
To: 'Bresticker, Shalom'; sv-cc@eda.org
Subject: RE: [sv-cc] Callbacks on virtual interface var - proposal

 

Thank you very much,

 

Radek

  _____  

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Monday, September 02, 2013 9:28 AM
To: Radoslaw Nawrot; sv-cc@eda.org
Subject: RE: [sv-cc] Callbacks on virtual interface var - proposal

I submitted this as Mantis 4733.

 

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Radoslaw
Nawrot
Sent: Thursday, August 29, 2013 14:26
To: sv-cc@eda.org
Subject: [sv-cc] Callbacks on virtual interface var - proposal

 

Hi All,

From 1800-2012 virtual interface is availble via VPI, but standard do not
define any mechanizm to detect and handle initialization and disconnection
of it 

 

Is:
cbCreateObj After the class constructor call has completed and the internal
state of a class object 

has been initialized, or for shallow copy, after the copy operation has
completed.

 

cbReclaimObj Before the class object has been reclaimed by the automatic
memory
management, when it has been marked as no longer being used. When control is
returned from this callback, any handles to this class object, its
properties or their
subelements, and any associated callbacks should be considered invalid.

 

proposal:

 


cbCreateObj After the class constructor call has completed and the internal
state of a class 

object has been initialized, or for shallow copy, after the copy operation
has  completed or 

virtual interface has been initialized.

 

cbReclaimObj Before the class object has been reclaimed by the automatic
memory
management, when it has been marked as no longer being used or virtual
interface var

has been disconnected by null constant  or other interface instance. When
control is 

returned from this callback, any handles to this class object or virtual
interface var ,

their properties or their subelements, and any associated callbacks should
be considered invalid.

 

Regards,

Radek

 


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

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
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  <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.