From: James A. Markevitch (jam@magic.com)
Date: Fri Feb 11 2000 - 18:30:18 PST
Some comments. One CORRECTION, three DISCUSSION points, one REQUEST.
Unless anyone else feels strongly or finds flaws with the proposal, I
am inclined to accept Steven's proposal with the following changes:
Implement the CORRECTION.
Implement the REQUEST (use the "cla" example).
Implement the extension described in the third DISCUSSION point (allow
attribute_instance before "endmodule").
By the way, I haven't put these into the yacc yet, but hopefully I can put
them in late tonight.
> PROPOSED IS:
> (* attribute_a, attribute_b *)
> case (foo)
> <rest_of_case_statement>
> or
> (* attribute_a=1, attribute_b=1 *)
> case (foo)
> <rest_of_case_statement>
> or
> (* attribute_a, // no value assigned
> attribute_b=1 *)
> case (foo)
> <rest_of_case_statement>
>
> To attach the attribute_a attribute, but NOT the attribute_b attribute:
>
> (* attribute_a *) // attribute_b not specified
> case (foo)
> <rest_of_case_statement>
> or
> (* attribute_a=1, attribute_b = 0 *)
> case (foo)
> <rest_of_case_statement>
>
> To attach an attribute to a module definition:
>
> (* attribute_c *)
> module mod1 (<port_list>);
> or
> (* attribute_c=1 *)
> module mod1 (* attribute_c=1 *) (<port_list>);
CORRECTION:
Shouldn't this be:
(* attribute_c=1 *)
module mod1 (<port_list>);
> NOTE--Since the above example sets the attribute_c attribute in a module
> definition, any instantiation of the module shall have that attribute,
> unless explicitly overriden by a different value of that attribute on a
> particular module instantiation:
>
> (* attribute_c=0 *)
> mod1 synth1 (<port_list>);
DISCUSSION:
One drawback of this is that attributes can only be attached to all of
the instantiated modules. Thus,
(* attribute_c=0 *)
mod1 synth1 (<port_list1>), synth2 (<port_list2>);
will attach the attribute to both instances, right? This seems slightly
less desirable than:
mod1 (* attr=0 *) synth1 (<port_list1>),
(* attr=1 *) synth2 (<port_list2>);
I.e. prefix the module_instance with an attribute, rather than the
module_instantiation. I note, though, that the language could be extended
to add these at a later time without any harm. So, unless people find
this alternative compelling, I won't push for it.
> To attach an attribute to a reg declaration:
>
> (* attr_d *) reg [7:0] state1;
> (* attr_d=1 *) reg [3:0] state2, state3;
> reg [3:0] reg1; // this reg does NOT have attr_d set
> (* attr_d=0 *) reg [3:0] reg2; // nor does this one
DISCUSSION:
Same comment for declarations as for module instantiations. In the above
example, the state2 and state3 variables both have the attribute attached.
> To attach an attribute to an operator:
>
> always @(posedge clk)
> a = b + (* attr_e = "string" *) c;
>
> This sets the value for the attribute attr_e to be the string string.
REQUEST:
If it's not too late, please use a more realistic example, such as:
To attach an attribute to an operator:
always @(posedge clk)
a = b + (* mode = "cla" *) c;
This sets the value for the attribute mode to be the string cla.
>
> To attach an attribute to a conditional operator:
>
> a = b ? (* attr_f *) c : d;
> 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
DISCUSSION:
The problem with prefixing module_item is that it doesn't properly handle
the (* rtl_translate_on *) and (* rtl_translate_off *) case. The attribute
appears to be connected to the next module_item. Furthermore, the attribute
cannot be the last part of the module; i.e. there is no way to do the
following:
module mymod;
...
(* rtl_translate_off *)
always @(posedge clk) // attribute is attached to this
debugflag1 <= 1'b1;
always @(posedge clk) // but the vendor/user also wants it attached
debugflag2 <= 1'b1; // to this as well.
(* rtl_translate_on *) // can't do this since it isn't attached
endmodule
Do we just punt and say this is a semantic issue, even though the syntax
strongly implies that the attribute is attached to only the first item.
I am tempted to say yes to this, even though it seems ugly.
For the rtl_translate_on, do we allow an attribute instance before an
endmodule, just because this is a likely to be a commonly desired idiom?
I would vote for this extension if the rest of Steven's proposal is taken.
> block_item_declaration
> ordered_port_connection
> named_port_connection
> port_definition
> statement
> statement_or_null
> function_statement
> function_statement_or_null
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.