RE: [sv-cc] Proposal for 526: vpiValid for dynamic variables

Doug, Rohit and I have both been doing some thinking
-- and have come to different conclusions so far.
But here is my response to at least some of your comments.

We can make a distinction between a variable that is
a dynamic array, associative array, or queue and the
set of values that are associated with the variable.
The variable itself can be explicitly declared as
static or be implicitly "static" because it's declared
in a static context.  In either of those case, there's
going to be some single place in almost any implementation
that corresponds to the simple name of the array.  Because
of that, a vpiHandle to the object corresponding to the
simple name should be fairly stable.  Even if the array
is reduced to having no elements, the array continues
to exist.

I'll deal later with the problem of what happens when
the simple name is not declared in a static context.

When it comes to the elements of the array, or where
the block of objects that constitute the array is stored
in memory, that's another matter.  The space where the
elements are stored is almost certainly going to move
around in memory as the arrays expand and contract.
And, as you observe, a queue is very likely to be
implemented as a linked list.

Be that as it may, the language requires that one be
able at any time to access the elements of the array
directly via an index value.  Thus, if the space for
the values of a dynamic array foo gets reallocated,
foo[137] still has to refer to something meaningful,
provided 137 < the size of the array.  The language
suggests that this ought to be a fairly efficient
operation, but if it's inefficient in the language,
it's probably for the equivalent access (finding
the new 137th element of foo) to be inefficient
in VPI as well.  The same is true for an element
of a queue.

So let's say that a vpiHandle points to foo[137]
before the array or queue gets resized (or shifted).
If we say that after the change, the vpiHandle still
has to refer to what the language would call foo[137],
then determining the validity of the vpiHandle
would mean checking the bounds of the array or
queue, then doing what the language would to
to find the corresponding element.  Whether or
not you think that's the right thing to do, would
you at least agree that this provides a consistent
and implementable check for the validity of the
handle of an element of a dynamic array or queue?

If the simple name of the array is declared in
a dynamic context, the validity of the handle
representing the simple name will be coterminous
with that of the context -- just as it would
be for a statically sized variable.  So if
we can solve the problem for a statically sized
variable, we can solve for a dynamically sized
one as well -- although getting the elements
of the two arrays has to differ as noted above.

Now about strings.  Again, the validity of the
handle corresponding to the simple name of the
string can be established independently of the
value associated with the string, using the
same argument as before.  That is, there
almost certainly is a place somewhere inside
the simulator that corresponds to the name
of the string (either permanently or for the
duration of the context in which the string is
declared).  So in that case the handle for
the string should be just as stable as the
handle for its context.

But what about the elements of the string?
That's a very good question.  I went to the
document to find out how to extract the
elements of a string in VPI.  I don't actually
know if there's a way to do that -- I presume
some form of vpi_get_value might work, but
I don't know that we've defined vpi_get_value
for strings.  But from the diagrams, I don't
see how you can extract a character from a
particular position in the string (32.14?), or 
extract its var bit (also 32.14?).  One might
possibly iterate over vpiVarSelect (32.15),
but that relationship is missing from 32.14
as well.

So for the nonce, I don't see a way to extract
a handle corresponding to a byte of a string,
so applying vpiValid to it may be moot.

We haven't yet researched the use of automatic
variables in all those other contexts, so I'll
have to stop here for now.  But I would appreciate
anyone's feedback on my thinking about dynamically-
sized arrays and strings.

Regards,
Jim V. 

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Engineering Director                   (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd 
Chelmsford, MA 01824-4179 
"We all work with partial information." 
---------------------------------------------------------- 
  
 

] -----Original Message-----
] From: Warmke, Doug [mailto:doug_warmke@mentorg.com] 
] Sent: Friday, April 08, 2005 2:10 AM
] To: Jim Vellenga; SV-CC
] Cc: Rohit Rana
] Subject: RE: [sv-cc] Proposal for 526: vpiValid for dynamic variables
] 
] Jim,
] 
] The vpiValid scheme seems good in principle.
] I've been trying to think of wording for automatics,
] but I'm not sure about some other more basic things.
] 
] First, implementations might reallocate dynamic objects
] such as dynamic arrays and associative arrays.  This can
] happen due to resizing.
] 
] Other objects, such as queues, are suitable for linked list
] implementation and shouldn't need to be reallocated
] by a simulator as they change in size. Thus one can in theory
] safely keep a reference to an element of a queue and use it
] as long as the element hasn't been explicitly deleted by user code.
] 
] Is a vpi handle to an element of a dynamic object like a
] SystemVerilog reference to an element of a dynamic object?
] If so, then it could be invalidated when the dynamic object
] is moved around in memory.
] 
] Also, strings are dynamic objects.
] They may be moved around in memory as the string changes
] in size.  And strings may be completely deleted by user code.
] Are there issues with handles to string variables?
] If someone gets a handle to a valid string, then SV
] code destroys the string such that it is a NULL variable,
] how would that be reflected in the handle object the user has?
] 
] What about handles to basic dynamic and associative arrays?
] (i.e. not just array elements).  Those can shift around from
] being completely NULL to being objects with valid contents.
] 
] For automatics, remember that in SystemVerilog one can have
] automatic variables in all kinds of scopes, not just tasks
] and functions.  They can exist in named block scopes, straight
] in always/initial blocks, in fork/joins, and probably
] elsewhere I'm not thinking about.
] 
] Talk to you guys tomorrow (early!)
] 
] Regards,
] Doug 
] 
] > -----Original Message-----
] > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org
] <mailto:owner-sv-cc@eda.org> ] On
] > Behalf Of Jim Vellenga
] > Sent: Thursday, April 07, 2005 1:44 PM
] > To: SV-CC
] > Cc: Rohit Rana
] > Subject: [sv-cc] Proposal for 526: vpiValid for dynamic variables
] >
] > We have uploaded a proposal for adding the vpiValid
] > property to variables.  The note says that this property
] > indicates whether or not a non-static variable from
] > within a class or within a dynamic array is still
] > valid, i.e., its memory has not yet been reclaimed.
] >
] > vpiValid also applies to automatic variables in
] > tasks and functions.  Does anyone have some good
] > wording to add to this note for that?
] >
] > Regards,
] > Jim Vellenga
] >
] > ---------------------------------------------------------
] > James H. Vellenga                            978-262-6381
] > Engineering Director                   (FAX) 978-262-6636
] > Cadence Design Systems, Inc.         vellenga@cadence.com
] > 270 Billerica Rd
] > Chelmsford, MA 01824-4179
] > "We all work with partial information."
] > ----------------------------------------------------------
] >  
] >
] > 
] 
] 
]