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

Hi Dave.

Thanks for the pointer to outdated elements.  I hadn't seen
that before.

My understanding is that the reference inside the subroutine
to the element that was passed by reference is called
a "ref obj" in VPI.  Does this mean we ought to think
about validity checking for ref objs?

The purpose of validity checking as we saw it among our
own engineers was twofold:

(1) Has the object gone away in some sense meaningful to
the software user?  For example, if they're tracking a
packet in the form of a class object through a network
made up of class variables, is there some point at which
no class variable points to the packet any longer?

(2) Can we give the application developer a tool so
that when they seek a property, relationship, or value
of a dynamic object, the application doesn't crash?

For the latter purpose, one could treat the outdated
object as valid because the simulator dare not free
the related storage until the subroutine gives up
its references to it.  But what are the implications
of purpose 1 for the validity of an outdated object?

Will all implementations make the necessary distinctions
that allow us to track the differences?

By the way, I observe that the same problem can
occur if one passes a non-static data member of a
class object by reference to a task or function.
The class object could "disappear" while the task
or function is still referencing the data member.

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." 
---------------------------------------------------------- 
  
 

] -----Original Message-----
] From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
] Sent: Friday, April 22, 2005 6:04 PM
] To: Jim Vellenga; Warmke, Doug; SV-CC
] Cc: Rohit Rana
] Subject: RE: [sv-cc] Proposal for 526: vpiValid for dynamic variables
] 
] Hi Jim,
] 
] Just wanted to put in my $.02
] 
] An element of a dynamic array can have three states: valid, 
] invalid, or
] outdated. Refer to section 11.4.2. I think the VPI handles 
] should mimic
] pass by reference semantics to elements of dynamic arrays.
] 
] Dave
]  
] 
] > -----Original Message-----
] > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of
] Jim
] > Vellenga
] > Sent: Friday, April 22, 2005 1:19 PM
] > To: Warmke, Doug; SV-CC
] > Cc: Rohit Rana
] > Subject: 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."
] > ] > ----------------------------------------------------------
] > ] >
] > ] >
] > ] >
] > ]
] > ]
] > ]
] 
] 
]