From: James A. Markevitch (jam@magic.com)
Date: Mon Jan 17 2000 - 21:46:48 PST
Here are some comments on the Draft 4 BNF.
Section A.2.1.3
In net_declaration there are four different cases where "[ vectored |
scalared ]" appear. Those same cases include "[ range ]". But, other
than those two optional components, the cases are identical to four
other cases. If both the range and vectored|scalared are optional, then
there is no need for the extra four cases. If, however, vectored|scalared
can only apply to a net with a range, then the range should not be shown
as optional.
Section A.2.2.1
The second clause of real_type is
| real_identifier [ dimension { dimension } ]
It seems that the square brackets should be removed, since the dimension
is not optional. The case where it is missing is handled in the first
clause, namely
| real_identifier [ = constant_expression ]
Ditto for register_type
Section A.2.3
list_of_param_assignments is defined as
param_assignment [ range ] { , param_assignment }
Is the range supposed to be here? Compare with
list_of_local_param_assignments which doesn't contain the range.
Section A.4
I think somebody else already pointed this out, but module_instance
refers to list_of_module_connections, whereas list_of_port_connections
is defined in the BNF.
Section A.6.3
function_seq_block doesn't seem right. It is defined as
begin [ : block_identifier ]
[ { block_item_declaration } ] { function_statement } end
Should everything from the colon to the first close curly brace be inside
a pair of square brackets (as in seq_block)? Or was there some other
intent here?
Section A.6.4
In the definition of statement, the following line
| procedural_continuous_assignments ;
conflicts with the definition of procedural_continuous_assignments. Either
the semi-colon should be removed in its use in the definition of statement
or in each of the clauses in procedural_continuous_assignments.
Section A.6.4
conditional_statement does not appear to be one of the clauses in the
definition of statement. Is this an oversight, or is the intent to include
it elsewhere?
Section A.6.6
In the definitions of if_else_if_statement and function_if_else_if_statement,
the "else if" clause should be "at least one". Otherwise, these definitions
should be removed and the optional "else if" clauses put into the
definitions for conditional_statement and function_conditional_statement.
Also, the generate_conditional_statement is handled in a different manner.
For consistency, shouldn't all three cases be handled the same way?
Section A.6.7
In the definition of case_statement, each of the clauses contains
"case_item [ case_item ]" using square brackets. Shouldn't those all
use curly braces instead?
Section A.6.7
In the definition of function_case_statement, each of the clauses contains
"case_item [ function_case_item ]". Shouldn't those all use curly braces
and shouldn't both of these items be function_case_item instead of case_item?
Section A.8.1
constant_multiple_concatenation is defined as
{ constant_expression { constant_expression } }
houldn't it be
{ constant_expression { constant_expression { , constant_expression } } }
with the two outer-most curly braces being in bold and the inner-most curly
braces being in a normal font.
Section A.8.3
In constant_expression, the conditional_expression is explicitly handled
as a separate grammar rule, whereas in the standard expression definition
and in the genvar_expression definition, the conditional is handled
in-line to the definition. Is there a reason for constant_expression to be
different?
James Markevitch
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:10 PDT
and
sponsored by Boyd Technology, Inc.