From: Steven Sharp (sharp@cadence.com)
Date: Fri Feb 11 2000 - 22:26:22 PST
>> I put the proposal into yacc and have the following comments.
Thanks!
> 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?
Actually, the problem is with the definition of statement. I never intended
to allow the attribute to appear after the delay_or_event_control. I failed
to notice the appearance of procedural_timing_control_statement in the
productions for statement. Here is my proposed fix, which leaves attributes
where they are in function calls:
Redefine statement using
tatement ::= [attr_inst] statement_body
statement_body ::= <old definition of statement>
procedural_timing_control_statement ::=
delay_or_event_control_statement statement_body |
delay_or_event_control_statement ;
or remove procedural_timing_control_statement and redefine statement with
tatement ::= [attr_inst] {delay_or_event_control} undelayed_statement |
[attr_inst] {delay_or_event_control} ;
undelayed_statement ::= <old definition of statement except for
procedural_timing_control_statement>
or any number of other variations that only allow zero or one (or more if
somebody wants) attr_inst, followed by zero or more delay_or_event_control
and an actual statement, or one or more delay_or_event_control and a semicolon.
It would be less messy if null statements didn't require at least one
delay_or_event_control to be legal in some contexts.
This should not cause a problem in function_statement, since those can't
have delay_or_event_control in them. There may be some other circularities
in the BNF that would need fixing also.
> 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?
These all look like reasonable places that I missed. I guess another approach
would be to find all of the individual *_declaration definitions and add the
attributes to those. That has the advantage of indicating more directly what
the attributes are attached to, without having to follow down from the more
general productions.
> 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.
I am hesitant to ignore the PLI aspect. I can imagine that some add-on tools
that want to use attributes won't want to implement their own Verilog parsers
and elaborators. They have the option of using PLI in an existing simulator
to traverse the design. Losing access to this attribute could be a problem.
For example, a lint-checker looking for unsynthesizable constructs needs to
know where synthesis was explicitly turned off.
I don't think this is a parsing problem, though it is semantically odd when
compared to the other attributes. I agree that this is very desirable because
of the historical approach to synthesis_on/off directives. Perhaps there is
some way around the PLI problem, e.g. by attaching it to some dummy item.
Any PLI experts reading this?
I appreciate the testing and feedback you are providing.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:12 PDT
and
sponsored by Boyd Technology, Inc.