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

Joao,

What are the names of the new callbacks?  I did a string
search for "cb" and didn't see any obvious ones.  I
did see starts and ends of frames and threads, but
nothing for the variables themselves.

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: Joao Geada [mailto:jgeada@comcast.net] 
] Sent: Friday, April 22, 2005 4:28 PM
] To: Jim Vellenga
] Cc: Warmke, Doug; SV-CC; Rohit Rana
] Subject: 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."
] > ] > ----------------------------------------------------------
] > ] >  
] > ] >
] > ] > 
] > ] 
] > ] 
] > ] 
] > 
] 
] 
]