[sv-cc] VPI handles for class (dynamic objects) discussion

All-
As a first installment of my "succinct written description" of the
issues, I would like to kick-off an email discussion of the
following assertion I feel strongly should motivate us here.
[ Conversation notes from minutes excerpted below- thanks Jim. ]

Initial Assertion:
=> VPI should support "decompilability" of the HDL design (disregarding
   encryption/protection issues for purposes of this discussion); 

Implications:
   - VPI handles must *always* be create-able for HDL variable instances
     specifically appearing in the design (by way of scans on
     simulation-invariant HDL constructs, e.g. vpiLhs and vpiRhs from
     vpiStmts, etc.).
   - Simulation-invariant properties and relations should be available
     for access from VPI handles so-derived from such variables at *any*
     time (post-elaboration), i.e. regardless of whether they are
     vpiValidTrue or not. [ I contend that the note for vpiValid in
27.14
     should explicitly say this (the sentence for vpiValidFalse seems to
     suggest the opposite) ! ]

Secondary Hunches/Questions:
  - While the vpiName (& vpiDecompile) properties seem essential for all
    VPI handles created by way of perusing design constructs described
    above, vpiFullName does NOT seem so.  Given it could depend on
validity
    of dynamic scope bindings (polymorphism etc notwithstanding), should
it
    be legal for vpiValidFalse variables ??
  - Similar issue for vpi_handle_by_name access.  Should it allow a
handle
    to be created- even an "inactive" one- for an object that is
vpiValidFalse
    (for the same reasons) ?

It does NOT seem that "decompilability" is precluded by DISALLOWING the
above vpiFullName property *and* vpi_handle_by_name access to invalid
dynamic
variables- even though "invalid" VPI handles to them *could* exist
(created
by means previously described).

I would appreciate all your thoughts on the above before I formalize
this
any further !
Thanks,
Chuck

------------ Excerpt from 1/31/07 Meeting ----------

   - Full name for class objects (Chuck).

Chuck proposed extending the vpiFullName property so that it applies to 
class variables and their data members.
Jim: 1800 17.14 detail y prohibits the vpiFullName property only for 
nonstatic data members, but seems to allow it on class variables.
Abi: Such objects have an existence in the elaborated design even when 
they don't actually point to an underlying simulation object.
Chuck: Yes, the scope of the thing referred to can change but the way 
to refer to it does not.  VPI must provide a way of connecting the two.
Amit: How can you reference a class variable that is itself declared in 
a class scope?
Chuck: The important thing is to track the expression object, even if 
it involves nested class variables.
Michael: Can the full name of a class variable change from time to time 
if it's embedded in a class?
Chuck: Not if it's embedded in a static context.
Francoise: Originally, vpiFullName was intended to allow an object to 
be retrieved again via vpi_handle_by_name().  But this does not work 
with automatic scopes.  And what about unnamed scopes such as unnamed 
blocks?
Jim: 1800 27.9 says that unnamed scopes shall have tool-dependent 
names.
Chuck: Is there a connection between when an application can obtain a 
vpiFullName and whether or not the handle is valid (vpiValid == TRUE)?
Francoise and Abi:  The two are unrelated.
Steve: We need to separate out the following three issues clearly:
  -- location -- What is the underlying simulation object?
  -- alias -- How are we referring to the object?
  -- time -- How are the location and alias related over time?
Jim: This applies even in old Verilog, as array[i] and array[0] can be 
aliases referring to the same location at times when i has the value 0.
Chuck: If we allow vpi_handle_by_name() to accept a full name of a 
nonstatic member of a class variable, does that object exist even if 
the class variable points to NULL?
Abi and Chuck: Yes, but the application must be aware that it may not 
point to an underlying simulation object and should test vpiValid.
Francoise: A handle does not disappear just because vpiValid becomes 
false.
Jim: 1800 27.22 detail g says that vpi_handle_by_name must accept a 
full name of a nonstatic data member of a class variable.  It does not 
indicate that the underlying simulation object must exist.
Abi; The elaboration name doesn't change along the time line, but what 
it points to does.
Chuck: Suppose that a nonstatic data member of a class variable is 
referred to as the left-hand side of an assignment, and one obtains a 
handle to it via the vpiLhs relation.
Francoise: The vpiLhs relation should definitely return a handle that 
represents the expression, even if it is not currently valid.
Chuck: We need to clarify what properties and relations of a handle can 
be accessed when it is not valid.
Jim: There are two ways in which a handle can become invalid.
-- for class_var.data_member, the handle does not go away even when it 
no longer points to an underlying simulation object.  One may still 
obtain certain properties.  And the handle can once again point to a 
simulation object when the class variable gets reassigned.
-- for a data member obtained relative to a class obj scope, the handle 
will have no further use once the class obj ceases to exist.
Francoise: It's still not clear that these are really different.
Francoise: We need to see the issues described succinctly in writing.
Steve: In particular, we should consider
-- What aliases exist?
-- What do they refer to?
-- What do they point to at any given time?
Action item: Chuck will produce a succinct written description of the 
issues.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.