From: James A. Markevitch (jam@magic.com)
Date: Fri Feb 11 2000 - 21:03:51 PST
I put the proposal into yacc and have the following comments.
> The BNF also needs to be modified to match. I believe that the only places
> that attributes will be needed will be at the start of these:
> module_declaration
> module_item
> block_item_declaration
> ordered_port_connection
> named_port_connection
> port_definition
> statement
> statement_or_null
> function_statement
> function_statement_or_null
>
> at the end of these:
> function_call
> system_function_call
> or equivalent places in primary,
>
> and at the appropriate places (which already exist) in
> expression
> to cover unary_operator, binary_operator and conditional operators.
>
> I think these are sufficient to get them everywhere desired through various
> productions. However, if I appear to have missed any or put them on
> anything inappropriate, let me know.
CHANGE:
The attributes cannot be at the end of function_call and system_function_call,
since those can be the end of an expression which can be the end of a delay
which can precede a statement:
#const_func(3) (* attr *) q = d;
does attr apply to the const_func or the blocking assignment?
I would like to amend the proposal to disallow attributes in system function
calls and to place them in function calls as follows:
function_call ::= hier_func_ident attr_inst ( expr { , expr } )
In other words, place it after the identifier. This is completely safe.
ADDITIONAL PLACES?
I think there are some inadvertent omissions in where attributes can be
attached. These are related to functions, tasks, and generate blocks.
1. Declarations, module instantiations, etc. may be inside generate blocks
and seem like they need attribute instances as well. Should there be
an optional attribute instance in the following place?
generate_item ::= ...
| [ attr_inst ] module_or_generate_item
2. Tasks also have inputs and outputs. Do they need attributes attached to
their declarations? If so, then something like:
task_item_delaration ::= block_item_declaration
| [ attr_inst ] input_declaration
| [ attr_inst ] output_declaration
| [ attr_inst ] inout_declaration
and
task_port_item ::= [ attr_inst ] input_declaration
| [ attr_inst ] output_declaration
| [ attr_inst ] inout_declaration
3. What about UDP input, output, and reg definitions? If so, then each of
these need to be prefixed with an optional attribute_instance.
udp_input_declaration
udp_output_declaration
udp_reg_declaration
4. What about function input port definitions? If so, then the following
should be done:
function_port_list ::= [ attr_inst ] input_declaration
{ , [ attr_inst ] input_declaration }
5. What about prefixing udp_declaration, since module_declaration is prefixed?
Note that I have put all 5 of these into yacc and don't get any extra
conflicts.
FOLLOWUP:
> You could allow it on an endmodule itself as a special case. That would
> make access from PLI awkward, since an endmodule isn't an object.
Other than the PLI aspect is this problematic? As mentioned in an earlier
e-mail, this is likely to be highly desirable for users.
James Markevitch
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:12 PDT
and
sponsored by Boyd Technology, Inc.