Re: BTF Attribute proposal

From: James A. Markevitch (jam@magic.com)
Date: Sat Feb 12 2000 - 08:24:23 PST


> After a bit more consideration, I see a possible problem with not allowing
> a statement attribute to appear after the delay_or_event_control. There
> are a surprising (to me anyway) number of Verilog users who believe that in
> a construct like
>
> always @(posedge clk)
> q = d;
>
> the event control is an intrinsic part of the always, instead of realizing
> that it is attached to the assignment statement. Grammatically they are
> incorrect, but they will find it unnatural to put an attribute for the
> assignment before the event control. I don't know if this is serious enough
> to want to allow attributes to appear after the event control.
>
> I really dislike putting attributes in the middle of function calls, and it
> doesn't work for system functions without arguments. Another alternative
> would be to switch port connections to use a suffix, and function calls and
> operators to use a prefix. That choice was rather arbitrary anyway. It
> would fix this particular problem, but would feel rather like "drunkenly
> (or at least tiredly) sloshing the attributes around like buckets of paint"
> in an attempt to fix the problem, to repeat a recent analogy. I am fairly
> sure that it fixes it, but not as sure as my original version that assumed
> statement attributes would appear before any delay or event controls.

Here are some arguments in favor of putting the attributes in the middle of
function calls, instead of at the end. I.e. support:

        z = func_name (* mode="hardmacro" *) (arg1, arg2);

1. This attaches the attribute to the "operator" just as for unary, binary,
and conditional operators. In this case, the "operator" is the function
itself. This also keeps the attribute close to the function name which
probably makes intuitive sense to the user.

2. Pragmatic: this solves the problem and avoids a lot of the "drunkenly
sloshing paint" that we might otherwise need to do.

3. System calls can be extended in a later version of the language and/or
by vendors. By simply allowing an empty parenthesized list after a system
function call, attributes can be extended to those. Thus, the following
would all be legal:

        then = $time;
        now = $time();
        soon = $time (* attr_name *) ();

It's probably too late to do this for Verilog 2000. But I think we lose
very little by disallowing the attribute on a system function call, and
there is a simple way to extend the language to support them in the future.

By the way, I tried adding empty parens to the yacc grammar for system
function calls and they don't seem to present a problem.

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.