From: Steven Sharp (sharp@cadence.com)
Date: Wed Jan 23 2002 - 14:13:11 PST
Precedence: bulk
>> > According to the BNF in 1364-2001, attributes can be attached to both
>> > a module declaration and a module instantiation.
>>
>> VPI provides separate access to the attributes attached to each. That
>> is all it has to do.
>
>But this is not the case.
>
>VPI does *not* provide separate access to the attributes of module
>declarations and module instantiations.
In my ignorance of VPI, I apparently described this wrong. Uma Parvathy
had assured me that it was possible to distinguish the two, and I assumed
that this was through treating them as attributes on separate VPI objects.
After consulting with Charles Dawson, here is what we concluded:
The single list of attributes on a VPI "Module" includes all of the
attributes attached to both the module declaration and the instantiation.
However, if you look at attributes, you will see that there is a boolean
flag vpiDefAttribute that tells you whether the attribute was on a definition.
This can be used to distinguish which one the attribute was attached to.
If an attribute with the same name was attached to both, then you will find
two different attribute items, one with the flag true and the other with it
false.
Note that a user could add their own layer on top that does provide separate
access to the two kinds of attributes, simply by ignoring the kind they
aren't accessing at the moment. As long as they can be distinguished, it
doesn't matter whether they are on different lists or the same list with a
flag. I expect that some underlying implementations will have two separate
lists, and traverse one and then the other to return the combined list.
Also note that this is not the only situation where multiple attributes with
the same name can appear on the same object. We debated what to do if the
same attribute name is attached redundantly (e.g. produce an error, produce
an error only if the values don't match, use the last value seen). We finally
decided not to do anything about that either. There will just be multiple
attributes with the same name. The application can decide what to do about
that. VPI just provides the raw information about what the user attached.
We have elevated being wishy-washy to a design philosophy here :-)
>Yes, it seems the attribute object diagram in section 26.6.42 is missing
>several objects that can hold attributes according to the BNF. Notably,
>
> "IODecl"
> "ContAssign"
> "DefParam"
> "Parameter"
This is unfortunate. I expect implementors will extend the VPI to allow
access to these if it turns out anyone actually has a use for them.
>> And there is presumably a way to access them, independently from any other
>> attribute.
>
>Yes, the port connection information is available via the "Port" object.
>But, "Port" objects provide access to information from other syntactic
>elements as well, several of which can also have attributes attached.
>But, as with "Module" objects, "Port" objects provide access to only
>*one* set of attributes.
If there isn't some way of distinguishing these, then there is a problem.
Can you give me an example of one of these other elements?
>The issue remaining is what happens to any attributes attached to the
>"generate" structure itself?
My guess would be that this was a matter of getting carried away with
attaching attributes to everything in sight, and that such attributes
would be meaningless.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:34 PDT
and
sponsored by Boyd Technology, Inc.