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

Just an observation: the new VPI defines a few new callbacks that
have to be supported in SystemVerilog. These include variable creation,
destruction & status change callbacks for dynamic variables. Any implementation
that can support those should be automatically able to cleanup any
existing VPI handles so that they remain valid ...

ie: if I have a VPI handle existing for a dynamic variable 'foo'
(whether this is a full variable or part of a variable is immaterial)
then the implementation must know about this handle and must be able to
internally create the appropriate status change callbacks to update the
handle as necessary, including, when appropriate, marking the handle as
'invalid'.

Right?

João

On Fri, 2005-04-22 at 16:19 -0400, Jim Vellenga wrote:
> 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."
> ] > ----------------------------------------------------------
> ] >  
> ] >
> ] > 
> ] 
> ] 
> ] 
>