[sv-cc] Item 526 (vpiValid): issues and concerns

Item 526 (vpiValid property) raises several non-trivial issues:

1. Semantics: Reallocation and vpiHandle behavior

     The knowledge that a dynamic variable has had its memory
deallocated has little value in 
     itself.  Presumably, the value lies in knowing whether subsequent
attempts to obtain 
     a value for this variable, using the current vpiHandle, will yield
meaningful results.

     We have dynamic objects that can be 'deallocated' as they are
resized or moved about in
     memory  (strings, dynamic and associative arrays).  To deliver an
accurate vpiValid value 
     with confidence we must know whether resizing invalidates the
vpiHandle or otherwise 
     prevents using it in VPI calls to get new, accurate variable
values.

     Thus, a vpiValid capability needs to specify how
reallocation/resizing affects vpiHandles 
     and would affect the value of vpiValid.

2. Scope (relevant datatypes)
    The current proposal only addresses "non-static variables of class
instance[s] and elements
     of dynamic arrays."  Doug asked if the capability extends to
strings, entire dynamic and 
     associative arrays, and automatic variables.

     A vpiValid capability would need to exhaustively specify which data
types it addresses.

3. Vendor obligation and incompatibilities

    (a) One idea was that vendors who do not want to implement dynamic
memory 
     tracking could make vpiValid return FALSE, regardless of
deallocation status.
    (b) Although the original proposal had vpiValid indicate dynamic
deallocation or its
    absence, a new suggestion has vpiValid always report TRUE for static
variables.

   If both ideas are accepted we have 4 hypothetical possibilities with
vendors implementing checking for
   (a) neither static nor dynamic variables, (b) static variables only,
(c) dynamic only,
   (d) both static and dynamic.

   IMPACTS: If vendors can return FALSE for a kind of variable (static
or dynamic) without
   regard to its actual disposition, then 
   . The only tool behavioral evidence that a vendor actually implements
a check for that 
     kind of variable is a result of vpiValue = TRUE.
   . 'Incompatible' (different) behavior across vendors will always be
possible.

   We need to decide whether vpiValid would be relevant to static
variables and whether vendors can 
   choose any of the 4 scenarios above.

SUMMARY:
This is an attractive capability.  Before adding it, however, we should
address resizing issues,
fully delineate which datatypes are relevant for it and consider vendor
freedom and obligation to 
implement this.  These matters seem too significant to be decided or
specified solely in a note to
the diagrams.