From: Dennis Marsa (drm@xilinx.com)
Date: Wed Jan 23 2002 - 14:59:18 PST
Precedence: bulk
Steven Sharp wrote:
>
> 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.
Ahh, I see. I noticed the vpiDefAttribute property, but I did not make the
connection to this as there is no description of it anywhere. Now it seems
fairly obvious. That diagram could use a note describing that property, perhaps
using the module declaration vs. module instantiation example to illustrate.
> 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.
Agreed.
> 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.
Are you sure? :-) Section 2.8, page 14, last paragraph, states:
"If the same attribute name is defined more than once for the same language
element, the last attribute value shall be used ..."
> >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.
Perhaps an errata is appropriate?
> >> 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?
I was thinking of attributes attached to input/inout/output declarations
as in my example with a port defined as a concatenation of three inputs
in my original mail.
If we agree that "IODecl" should be included in the diagram of section 26.6.42,
then perhaps my issue is resolved.
Without "IODecl" in section 26.6.42, I had interpreted that to mean that
attributes on input/inout/output declarations must propagate to the
corresponding VPI "Port" object. But, if "IODecl" object can contain
attributes, then that leaves only attributes port connection attributes
associated with VPI "Port" objects.
> >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.
Should this be an errata as well?
Thanks,
Dennis Marsa
Xilinx, Inc.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:34 PDT
and
sponsored by Boyd Technology, Inc.