From: Steven Sharp (sharp@cadence.com)
Date: Tue Jan 22 2002 - 20:16:53 PST
Precedence: bulk
>I've been thinking about attributes and how they should
>be propagated during the design elaboration process.
>
>This is a topic that does not appear to be discussed at
>all in 1364-2001.
It was deliberately not discussed. Before the final version,
there was a statement about propagating attributes between
module declarations and module instantiations. This was
explicitly removed as undesirable.
It is not desirable for the language to define some kind of
automatic propagation of attribute values for all attributes.
Different tools/applications with different attributes may want
to define their own rules for such propagation, depending on the
intended semantics of the attribute. If the language defines any
kind of automatic propagation, this could prevent a tool from doing
the kind of propagation that it wants.
The idea is that the tool is given access to the raw data that
the user provided. Any attempt to digest that data by overriding
an attribute with a value from elsewhere could lose information
that a tool might have wanted. As long as the language provides
access to exactly what the user provided, that can't happen.
It is up to the tool to use that information in any way it sees
fit. If it wants to have an attribute on a module definition
act as a default, with an equivalent attribute on an instantiation
overriding it, it can do so. It has access to both pieces of
information and can process them as it sees fit. If it wants to
have an attribute on a module definition mean an inherent property
of this module that can't be overridden from elsewhere, it can do
that instead. The same or a different tool can use different rules
for different attributes, or for the same attribute under different
command line options, or any other combination that it needs.
I expect that a few combinations will actually get used. It should
be possible to write re-usable PLI routines that implement some set
of propagation rules and use them to determine the "propagated" value
of a given attribute. If the number of combinations is small enough,
there will always be people complaining that their rules were not
built in to the language. But it is still a lot better than if we
had built in the _wrong_ rules, since there would be no way for a
tool to fix it.
There are some other potential drawbacks. Developers may consider
having to roll their own "propagation" implementation as too much
work, resulting in more primitive semantics. Or different developers
may use different rules for arbitrary reasons, resulting in annoying
inconsistencies between applications that should work similarly.
Since nobody could foresee everything that attributes would be used
for, we felt it was better to leave them as general and flexible as
possible.
>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.
>2. Port Attributes
>------------------
>
> According to the BNF in 1364-2001, attributes can be attached to
> port declarations, i.e. "input", "inout" and "output" declarations.
>
> "input", "inout" and "output" declarations correspond directly with
> "IODECL" objects in the VPI interface.
>
> QUESTION 1: The VPI object diagram for attributes in section 26.6.42
> of 1364-2001 does not show "IODECL" objects as having a one-to-many
> relationship with "ATTRIBUTE" objects. Should "IODECL" be included
> in section 26.6.2?
>
> QUESTION 2: The VPI object diagram for attributes does show "PORT"
> objects as having a one-to-many relationship with "ATTRIBUTE"
> objects. Should attributes attached to port declarations be
> attached to "PORT" objects?
>
> Consider a module containing a port defined as a concatenation:
>
> module concat(.a({x,y,z}));
> (* input_x *) input x;
> (* input_y *) input y;
> (* input_z *) input z;
> endmodule
>
> QUESTION 3: Are each of the three attributes "input_x", "input_y" and
> "input_z" attached to port "a"?
>
> QUESTION 4: Should the BNF allow attributes to be attached to
> port references (i.e. BNF rule "port")? This would permit:
>
> module concat((* port_attribute *) .a({x,y,z}));
> ...
> endmodule
>
> NOTE: The BNF of 1364-2001 does not allow this currently.
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.
>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
attribute.
>4. DefParam Attributes
>----------------------
>
> According to the BNF in 1364-2001, attributes can be attached to defparam
> statements.
>
> module top;
> (* override *) defparam top.A.a = 123;
> modA 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 defparam?
In keeping with the general philosophy, it would only appear as an attribute
of the defparam.
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();
endmodule
module modA;
parameter a_override_attr = 0;
(* override = a_override_attr; *) parameter a = 1;
endmodule
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.
>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.
>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?
Note that it could be considered legal for an attribute on an instance
inside a generate-for to have a value defined in terms of the genvar, since
a genvar is allowed in constant expressions.
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.