From: Michael McNamara (mac@surefirev.com)
Date: Tue Nov 16 1999 - 06:44:09 PST
James A. Markevitch writes:
> It seems that there are 3 potential issues that need to be addressed by
> the BTF. See more detailed comments later in this e-mail.
>
> 1. "Any_ASCII_Characters_except_new_line" doesn't look like the right
> definition for attr_name in the BNF.
>
> 2. Attributes probably don't belong in the "lexical conventions" section.
>
> 3. UDPs (and other places?) need to have attributes added to them.
>
> I can't answer each of these items, since I am not sure what the intent
> was when attributes were added. Perhaps Steven Sharp or someone else can?
>
> > Here are answers to James' questions about attributes. I don't know if
> > these need clarification in the spec.
> >
> > > > What constraints are placed on the constant_expression assigned to an
> > > > attribute? Are only constants allowed as primaries in the expression?
> > > > What about parameters? What about specparams? What about the values
> > > > of other attributes?
> >
> > The constraints are pretty much the same as any other constant expression.
> > The expression must consist of literal constants and parameters. It happens
> > that specparams work for the OVI attributes in XL and NC, but this is probably
> > an oversight in type-checking. There is no way to access the value of an
> > attribute in any expression, including these. There is no syntax defined to
> > indicate what object's attribute value you wanted, for starters.
> >
> > > > Presumably it is perfectly legal to use what are otherwise reserved words
> > > > as attribute names, since they are in a different name space.
> >
> > Reserved words are not legal identifiers in any context. The point of having
> > reserved words is to avoid context sensitive lexical analysis.
>
> Does this imply that attribute names are just normal identifiers, as far
> as lexical analysis is concerned? The BNF specifies attr_name to be
> "Any_ASCII_Characters_except_new_line".
>
> All of the above comments basically mean that attributes are part of the
> language syntax, not lexicography. Attributes can be parsed in the
> main Verilog grammar with the simple addition of the tokens "(*"
> and "*)".
Amen. That is what we should have. Anything else is wrong (IMHO).
> Attributes probably don't belong in section 2.8, then. Any suggestions
> for a better section?
>
> > > > Also, is it legal for the same attribute to be specified more than once
> > > > in a single attribute instance? For example,
> > > > (* attra=1, attra=0, attra=2 *)
> > > > Is this legal? Does this assign the value 2 to attra? Is this tool-
> > > > dependent, so that the tool might actually see all three specifications?
> >
> > No, it is not legal. These are declarations, not assignment statements.
> > This was more obvious with the OVI syntax, since the declaration included
> > the word "const" and a type.
> >
> > I don't see any of the questions that were mentioned about other places
> > where attributes might be useful. I did determine that OVI attributes
> > can be attached to UDP declarations or instantiations. They cannot be
> > attached to parameters or specparams. Were there any other places that
> > seemed useful?
>
> The original comment was:
>
> 85. page 736, Annex A.5
> No attribute_instance is shown for a udp_instantiation. Is this an
> omission or is it not allowed?
>
> It sounds like the BNF should be updated. Other than UDPs are there
> other places where the attributes are missing from the BNF?
>
> James Markevitch
> jam@magic.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:31 PDT
and
sponsored by Boyd Technology, Inc.