RE: [sv-cc] Minor update to Names proposal (#1593)

hi Chuck,
We have deliberately avoided tackling source code versus
post-elaboration analysis issues in the dynamic objects discussion.
Unfortunately I think that the vpiName, vpiFullName and vpiDecompile
discussion has similar problems. I'd rather do what John has forced us
to do with dynamic objects, and take it back to first principles, than
make changes we will regret.

Here are some of my first principles, but they aren't fully shaken out
yet. This is just to demonstrate why I think there is a lot more to this
discussion still to have.

1. vpiFullName is the post-elaboration authoritative name for any
run-time object that has it. For any object that doesn't have a
post-elaboration authoritative name, there is no vpiFullName.
vpiFullName may include generated syntactical elements, which may or may
not be tool-dependent (i.e. elements that are not present in or
necessarily deducible from the source file). Among other things,
vpiFullName can be a property of types, type subcomponents, scopes,
objects that have value, and subcomponents of objects that have value.
2. For non-dynamic objects, vpiName is the post-elaboration name which
can uniquely identify an object within the local scope hierarchy. For
objects that also have a vpiFullName, vpiName may be used to find the
object using vpi_handle_by_name within the local scope, no other
vpi_handle_by_name behavior is guaranteed. vpiName may include generated
syntactical elements, that may or may not be tool-dependent. There are
objects that have a vpiName but not a vpiFullName, such as subcomponents
of class objects. These objects can never be accessed using
vpi_handle_by_name.
3. Because they are post-elaboration objects, vpiNames and vpiFullNames
with indices always contain fully-resolved indices that represent index
values at the time the property is requested.
4. vpiDecompile is the source-code syntax (or an equivalent
representation thereof) by which the object was reached, if it was
reached from a source code relation. It retains variable index
expression information. Many objects reached from post-elaboration
relations may not have a vpiDecompile, or it may be impossible to
determine it. 
5. Anything that is a class object or is derived from a class object has
NO vpiDecompile and NO vpiFullName. Class object sub-objects have a
vpiName that is the name from the class definition that identifies the
property.

I do not have fundamental principles for thread and frame variables yet.
But I would rather state some principles like these than go with an
operational definition, sorry.

Abi 

-----Original Message-----
From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On
Behalf Of Chuck Berking
Sent: Tuesday, March 25, 2008 3:17 PM
To: sv-cc@server.eda.org
Subject: [sv-cc] Minor update to Names proposal (#1593)

FYI-
I just uploaded a minor update to this proposal for "nested" prefix
cases, plus an additional example for each section.  Copy of uploaded
proposal is attached, FYC.
Regards,
Chuck

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