For class variables, if they are truly static then they are always present, whether any class instances exist or not and are therefore frame independent. All other variables are automatic and have to come into existance with the creation of a frame to hold them. Frames are the only means the simulator has to record variables (or at least, the only defined mechanism). As to parts of variables: you“re right, a part variable might become invalid without a frame disappearing. But luckily, in those cases you“ll get a type change callback. In all cases I can imagine (which might not be all cases; given how wierd SV has become my imagination is starting to feel limited) there should be an already definied callback that has to fire whenever a variable is created, changed and/or destroyed. It is mostly a matter of clearly spelling out how all this happens. Joao -------------- Original message -------------- > Always? That would be true for automatic variables. But > what about non-static variables that are embedded in > class instances? Don't those get allocated by a "new" > and freed when no class variable points to the parent > instance any longer? > > Similarly, while a dynamic variable itself does come > and go with the existence of its parent (such as a frame), > a VPI "variable" which is an element of the dynamic variable > can come or go when the variable is resized. And that > happens during the execution of a frame or thread, not > at the beginning or end. > > Is this correct? > > Regards, > Jim > > --------------------------------------------------------- > 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: jgeada@comcast.net [mailto:jgeada@comcast.net] > ] Sent: Monday, April 25, 2005 6:05 PM > ] To: Jim Vellenga > ] Subject: RE: [sv-cc] Proposal for 526: vpiValid for dynamic variables > ] > ] Jim: > ] variable creations are always associated with cbStartOfFrame events > ] and variable destruction is always associated with > ] cbEndOfFrame events... > ] > ] > ] -------------- Original message -------------- > ] > ] > OK, here are the lines that I've found from sv_vpi_user.h: > ] >t; > ] > /**************************** CALLBACK REASONS > ] ****************************/ > ] > #define cbStartOfThread 600 /* callback on thread creation */ > ] > #define cbEndOfThread 601 /* callback on thread > ] termination */ > ] > #define cbEnterThread 602 /* callback on re-entering > ] thread */ > ] > #define cbStartOfFrame 603 /* callback on frame creation */ > ] > #define cbEndOfFrame 604 /* callback on frame exit */ > ] > #define cbTypeChange 605 /* callback on variable > ] type/size change */ > ] > > ] > plus a bunch of assertion callbacks. I can see that > ] > cbTypeChange could apply when a dynamically allocated > ] > array changes size. But I couldn't find one that obviously > ] > applies to variable creation and destruction. Is the! re > ] > another section of callbacks somewhere? > ] > > ] > Regards, > ] > Jim V. > ] > > ] > --------------------------------------------------------- > ] > James H. Vellenga 978-262-6381 > ] > Engineering Directoor (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 5:04 PM > ] > ] To: Jim Vellenga > ] > ] Subject: RE: [sv-cc] Proposal for 526: vpiValid for > ] dynamic variables > ] > ] > ] > ] Sorry, I don't have the standard in front of me > ] here, so can't > ] > ] give you an exact reference. Best place to look > ] would be in the > ] > ] vpi header file itself. > ] > ] > ] >! ] On Fri, 2005-04-22 at 16:52 -0400, Jim Vellenga wrote: > ] > ] > 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 > ] > ] > Enginneering 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 commments. > ] > ] > ] > > ] > ] > ] > 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 t! hat 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 in! efficient 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 ag! ree 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 pproblem 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 t! hat -- 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 > ] > ] &! gt; ] > 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 > ] > ] >t; ] > 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@mentor! g.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 r! > ] eallocated > ] > ] > ] > ] 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 ge! ts 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 (ear! ly!) > ] > ] > ] > ] > ] > ] > ] > ] Regards, > ] > ] > ] > ] Doug > ] > ] > ] > ] > ] > ] > ] > ] > -----Original Message----- > ] > ] > ] > ] > From: 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 > ] >t; ] > ] > ] > 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." > ] > ] > ] > ] >! > ] ---------------------------------------------------------- > ] > ] > ] > ] > > ] > ] > ] > ] > > ] >t; ] > ] > ] > > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > > ] > ] > ] > ] > ] > ] > ] > ]Received on Tue Apr 26 06:43:59 2005
This archive was generated by hypermail 2.1.8 : Tue Apr 26 2005 - 06:45:09 PDT