From: Steven Sharp (sharp@cadence.com)
Date: Fri Feb 11 2000 - 19:26:55 PST
> CORRECTION:
> Shouldn't this be:
> (* attribute_c=1 *)
> module mod1 (<port_list>);
Oops, yes it should.
> 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.
This is something I debated myself before deciding. Note that the existing
definition (i.e. OVI attributes) puts the attribute before the first
module_instance. I had assumed that this allowed separate attributes for
each instance, but it turns out that it still applied it to both. Here is
how I decided to move it in front of the entire declaration:
CON: It requires using separate declarations to get different attributes.
CON: It isn't backward compatible with the existing position. If we
attach it to the module_instance, any pre-existing code with only
one module_instance on the declaration will still work.
PRO: It isn't backward compatible with the existing position. If we
attach it to the module_instance, any pre-existing code with multiple
module_instance's on the declaration will silently stop working.
PRO: It maintains maximum consistency.
PRO: It required less writing to describe. This was the deciding factor :-)
> > 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.
Same response. Note that in the original example, the state2 and state3
variables both have the attribute attached, it just isn't obvious.
I am willing to support putting the attribute before each item in a
declaration list if people prefer that.
> 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.
I considered trying to put realistic attributes in, but wasn't sure I could
come up with them for all examples. If we do this one, then we should
switch the case statements to "parallel_case" and "full_case", and so forth.
Any suggestions for the others?
> > 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.
I recognized this also, but don't see a good solution. The attachment of
the attribute to the first item shouldn't be a problem. Any tool that wants
to treat these as regions just has to track the last setting that it saw
as it scans the items. It can't check individual items without scanning.
The inability to put one after the last item is more of a problem. The
question is how to avoid it without running into the same ambiguity problem
that came up for statements.
You can't make an attribute be a module_item, or you get the exact same
ambiguity. You can't allow an attribute as a suffix to a module_item, or
you can't tell a suffix from a prefix on the next. You could put the
attribute after the endmodule, and let it get attached to the next module,
but you would still have a problem for the last module in the source.
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.
Note that the same problem could occur when putting such an attribute at
the very end of a sequential block, where there is no statement following.
This is just a fundamental problem with trying to use attributes to mark
regions instead of items. I don't see a good solution.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:12 PDT
and
sponsored by Boyd Technology, Inc.