Hi Jim,
We had a good discussion about this today, as you know, though not all
your points. One big bucket result is that we recognize that this
proposal was aimed at the post elaboration information model.
As such, the focus was on objects that have been instantiated and have
value. They may be static or transient objects with limited
lifetimes. We agreed that there is a need to unify this with the "src
code" information model. (That might also come to be known as the uninstantiated
or post-analysis information model.) We recognized that it is
impractical to analyze this thoroughly in the time remaining. The goal
we set was to attempt to identify a minimal answer to the same
questions:
How do we classify the memory allocation scheme for a src object?
vpiAllocScheme property either isn't available or has a value for these
objects and we have to decide that.
What does the vpiAutomatic property mean for "src code" objects? Same
considerations as above.
Beyond that, we might aspire to distinguish other aspects of src code
objects. The problem is that "pulling on that string" may unravel for
a while. To decide what properties give us adequate information about
a src code object implies you appreciate when you get one, what you can
do with it, and how it interacts with the runtime. Getting a src code
object that is an expression, yet saying that the object will produce a
value in a runtime context begs a lot of shared understanding. Is it
really the same object or did you just navigate to it the same way at a
different point in time and get 2 different objects? If you can
evaluate it for a value, what are the properties of the vpi evaluator?
How safe must it be? Note, I am only demonstrating pulling on
the string, not expressing or implying anything I believe about
this.
We agreed that a principle for getting closure for this round of the
LRM was that we may remain silent about some aspects, rather than make
a step in a controversial direction in a hasty manner. The spec
remains worse than a work in progress and we gain time and experience
with the new revised information model.
Regards, John
(further comments below)
Jim Vellenga wrote:
John and all,
I can see some merit in the proposed
vpiAllocScheme property. It seems
that we are using it to define the default
allocation scheme for scopes
and actual allocation scheme for objects. Is that correct?
If so, some thoughts:
-- Would it be good to tie it in
explicitly to the new proposed section
"36.3.6 Lifetimes of objects"? One could even define the new property
here and cross reference it from the
details, rather than cross
referencing the various details to the
fairly sketchy detail in the
section on variables.
Yes it would. I did not want to re-organize the information
initially. Keeps the principle of
least astonishment for
the reviewer. I kept the change aligned to where we have the property
vpiAutomatic today, so we could review as a extension of that concept.
It is much better to describe it once and refer to it. I'd prefer it.
-- The proposed 36.9 detail 9 needs to be
rewritten. I don't think we
really mean that vpiAllocScheme indicates
how the instance itself is
allocated in memory, do we?
Correct. This was a bit hasty of a cut and paste. I meant it to
indicate how the objects within an instance, by default, would be
allocated. In retrospect, it is unecessary at the level of the
instance to do so. The fact is, vpiAutomatic and the type of the
instance directly answers the question without requiring navigation to
some other object.
-- I see that we've never put the
vpiAutomatic property on tasks or
functions in the first place, even though,
with SystemVerilog, then can
have an automatic or static default scope. Should we add vpiAutomatic?
Should we
add vpiAllocScheme?
After our discussion, I want to think about it. My gut is that
vpiAutomatic should be there and have the same meaning as it has for an
instance. vpiAllocScheme is probably not that useful. The central
writeup of these properties will help unify it and answer the
question. I'll get back to you.
-- Things get more ambiguous, of course,
with a task or function
(method) declared in a class.
Consider the following, for example:
module top;
class C;
static
function automatic int f (int x);
return
-x;
endfunction
endclass
endmodule
Notice that the method 'f' has a static
lifetime but an automatic
default lifetime for its variables. Should we use vpiAutomatic for the
method's default variable lifetime, and
reserve vpiAllocScheme for the
function's own lifetime?
No, I don't think so right now. vpiAutomatic should reflect the
default for locals of the function as it does for an instance. The
other aspect of the function, in my mind, is a new property that we do
not need with any high priority. I think it would require a different
tag. I will think about it a bit more.
-- If an automatic variable is obtained
from a function declaration
(syntactically) it really has a lifetime
that is independent of
simulation, even though it has been
declared with the keyword
'automatic'. But
if we obtain the corresponding variable from a frame,
then the vpiAllocScheme is unambiguously
vpiAutomaticScheme. What
should the vpiAllocScheme be for the
variable obtained from the
syntactic context?
Given my comments at the top of the email, I am leaning toward a new
enumerated value, vpiUninstantiatedScheme. I know it is a long name,
but it is precise enough. If we wanted short,
vpiSrcScheme would be a possibility. BTW, it is tempting to say, from a
purely orthoganal perspective that the existing vpiStaticScheme is
adequate, if you know that the object is a src code object. That leads
us to "pull on the string" again. I expect we need to know in the
information model that really unifies the "src code" view, but we could
only be silent about it for now. If so, it is cleaner to define a new
enumerated value. What do you think?
Regards,
Jim Vellenga
---------------------------------------------------------
James H. Vellenga 978-262-6381
Software Architect (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
Hi,
This is detailed proposal
of the information model for dynamic objects. There are changes to
clause 36 and 37 in 2 documents.
Regards, John Shields
Mentor Graphics, Inc.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Thu Mar 20 11:33:30 2008