Verilog 2000 attributes

From: James A. Markevitch (jam@magic.com)
Date: Wed Feb 09 2000 - 15:46:02 PST

Adam,

Some issues related to attributes came up during the BTF telecon this
morning. These are all related to the Annex A draft of 2/7/2000.

1. The first issue is related to attributes being attached to system function
calls. If the system function takes no arguments, such as $time, $realtime,
$stime, and $random, then the BNF is ambiguous. For example, in the
following:

        modname newmod($time (* myattr *) );

the attribute may apply to the $time function or to the port on the module.
This is also true for a few cases where a delay is followed by an attribute,
such as in net declarations.

The root cause of this is that an expression can end in an optional
attribute instance, due to the system function call, and in some places
the syntax allows expressions to be followed by an attribute instance.
Since the system function call appears to be the only way that an
expression can end in an attribute instance, then deleting the attribute
instance from the system function call should eliminate these problems.

The BTF seems inclined to remove the attribute from system function calls.

2. There are many (sixteen or so?) places in the latest BNF which result
in an optional attribute instance being followed by a statement. Since
a statement is allowed to be an attribute instance, there is an ambiguity
in the grammar.

Nobody on the BTF call this morning was knowledgeable about the intent of
the attributes in each place, so it was difficult to propose a solution
to this which was compatible with the intent of attributes. For example, in

        always [ attribute_instance ] statement

would an attribute apply to the always block or be the statement? What is
the meaning of attaching an attribute to an "always" block vs. to the
statement within it?

Further, since a statement can consist of a lone attribute_instance, then
it is possible to write statements with no semi-colons. For example,

        if (cond)
            (* myattr *)
        else
            (* another_attr *)

Such syntax seems problematical from an aesthetic point of view as well
as the fact that it forces parsers to recognize attribute, rather than
silently ignoring them.

A possible solution is to redefine statement to be something like:

tatement ::= attribute_instance statement
                | conditional_statement
                | case_statement
                ...

This would allow zero or more attributes to be prepended to any statement.
Something more strict would be,

tatement ::= [ attribute_instance ] real_statement

real_statement ::= conditional_statement
                | case_statement
                ...

This allows zero or one attribute instance per statement. My preference
would be for the zero or more case, not this one.

Note that this does not allow attachment of an attribute to an always or
initial construct, but does allow one to be attached to any statement
within one of those constructs.

Finally, what about statement_or_null? Should an attribute be allowed for
the null statement?

The following is a list of places where such ambiguity arises:
        always_construct
        initial_construct
        function_seq_block
        par_block
        seq_block
        conditional_statement
        if_else_if_statement
        function_conditional_statement
        function_if_else_if_statement
        case_item (both productions)
        function_case_item (both productions)
        function_loop_statement (forever, repeat, while, for)
        loop_statement (forever, repeat, while, for)

James Markevitch

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:54:11 PDT and
sponsored by Boyd Technology, Inc.