From: Dennis Marsa (email@example.com)
Date: Wed Jan 23 2002 - 08:31:32 PST
Thanks for taking the time to put together such a detailed reply to my
I have to apologize for not taking the time to search the BTF archives
on the topic of attibutes to read what has been discussed there. In my
defense, at the time I was putting my questions together the BTF search
function was not working (for me at least). However, I could have been
more patient before sending out my questions.
Now that I've read some of the old discussions on attributes and your
reply, I have a better understanding of the motivations behind how
attributes were defined.
> >I am thinking of these issues in terms of extracting attribute
> >information using the VPI interface.
> VPI should give access to the raw attributes attached in the design
> and leave it up to the application to do any further processing.
> If you are the one responsible for implementing the VPI interface,
> this means one less thing you have to worry about implementing.
> >1. Module Declaration and Module Instantiation Attributes
> > 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.
Since VPI is a post-elaboration interface, all module instantiations
have been bound to their module declaration. The VPI interface defines
a "Module" object (defined by section 26.6.1) for each module instanced
in a design. The VPI "Module" object essentially represents both the
module declaration and instantiation.
>From this "Module" object, information from the module declaration is
available, such as its ports, internal signals, logic and behavior. In
additional, information from the module instantiation is also available
from the same "Module" object, such as its port connections, file/line
information and parameter overrides.
But, only *one* set of attributes is available from a VPI "Module"
So, two sets of attributes can be specified in the source, one set at
the module declaration, and another set at the module instantiation, but
only one set is available from VPI.
To resolve this, one would have to either define some rule for combining
the two sets of attributes, or extend VPI to allow independent access to
> During the standardization process, people suggested uses for
> attributes attached to all sorts of things. As a result, they got
> extended to lots of new objects late in the process. The VPI portion
> of the standard may not have stayed in sync with the language portion.
> If I knew more about the VPI stuff, I might be able to answer your
> question, or recognize such an error in the standard. I'll try
> consulting someone who knows more about it.
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,
> >3. Port Connection Attributes
> > According to the BNF in 1364-2001, attributes can be attached to individual
> > port connections in module/udp/primitive instantiations.
> And there is presumably a way to access them, independently from any other
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.
> I don't know whether anyone had a specific purpose in mind for attaching
> attributes to defparams. Note that if somebody wanted to use a defparam
> mechanism to control an attribute attached to a parameter, there is already
> a way to do that without any kind of attribute overrides.
> module top;
> defparam top.A.a = 123;
> defparam top.A.a_override_attr = 1;
> modA A();
> module modA;
> parameter a_override_attr = 0;
> (* override = a_override_attr; *) parameter a = 1;
> Since attribute definitions can be any constant expression, they can
> include parameter values, which can be defparam'ed from elsewhere.
> This effectively allows the Verilog code to define its own "propagation"
> of attribute values via the parameter value propagation mechanisms.
I now agree this is fine. Separate access to attributes attached to the
parameter, and to the defparam are available, so this is not an issue in
my mind anymore.
> >5. Parameter Assign Attributes
> > According to the BNF in 1364-2001, attributes can be attached to parameter
> > assignments in module instantiations.
> > module top;
> > modA #((* override *) 123) A();
> > endmodule
> > module modA;
> > parameter a = 1;
> > endmodule
> > QUESTION 1: Should the attribute "override" be attached to or
> > combined with the attributes of the parameter "a" in instance "A"
> > of module "modA"? Or should "override" only appear as an
> > attribute of the parameter assignment?
> You can undoubtedly predict my answer by now.
As with defparam's, separate access to each set of attributes is
available, so no longer an issue for me.
> >6. Generate Attributes
> > According to the BNF in 1364-2001, attributes can be attached to
> > a "generate-endgenerate" structure, but not to generate items within
> > that structure.
> > QUESTION 1: What happens to the attributes attached generate/endgenerate
> > structure during the design elaboration process? The
> > generate/endgenerate structure will be replaced by its expansion in
> > the elaborated design.
> If VPI does not provide access to the generate/endgenerate structure, then
> there was no point in attaching attributes to it. This may be one of those
> mismatches between the language and VPI sections I mentioned.
> As far as attachment to generate items, can't most of those items already
> have attributes attached? E.g. a module instantiation can have an attribute
> attached to it, whether it is inside a generate or not. Allowing it to have
> an attribute attached to it as a module instantiation and as a generate
> item would create an ambiguous grammar. How could you tell which one the
> attribute is attached to, when the syntax is identical?
Yes, you are right, individual generate items can have attributes
attached. I missed that.
The issue remaining is what happens to any attributes attached to the
"generate" structure itself?
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:34 PDT
sponsored by Boyd Technology, Inc.