Subject: Re: 1364.1 pragmas
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Oct 09 2002 - 15:15:36 PDT
At 01:50 PM 10/9/02 -0700, Paul Graham wrote:
> > My suggestion was to define the syntax
> > of attributes NOT by using comments, but
> > by using a token string which would be
> > read (=ignored) as a comment by tools not
> > equipped to read attributes.
>
>Doesn't using "(* ... *)" match your suggestion? A tool that wishes
>to ignore attributes can easily do so.
>
>Paul
I think I finally understand what John Michael Williams is talking about.
John (John-Michael?) wanted attribute tokens to start with the "//",
whether it is: /// //// //(* //>> //*** or whatever, so that existing
tools, without modification, would completely ignore the attributes as if
they were comments. This way attributes would more-or-less be harmless to
existing tools. Only if a tool had to read an attribute would it have to
parse more than "//" to see if an attribute exists.
This would have almost worked (see multi-line attribute discussion below).
It was never proposed before the 1364.1 synthesis draft was sent out for
ballot and I don't think it was ever proposed for Verilog-2001 even in
ballot comments. The synthesis group used the attributes as defined by
Verilog-2001 because that was a major reason attributes were added to
Verilog-2001 (and because I insisted that we not standardize "// synthesis
..." comment form synthesis directives). Had this suggestion been made
during Verilog-2001 it may have passed but I doubt it. The tradeoff is
asking tools that care about attributes to parse past the "//" to see if
it is really a comment or an attribute, plus, I have seen many lines of
"/////////..." in code and I would not be surprised to find that some user
has used almost every "//(*" "//>>" "//whatever" combination in some
existing model.
For a tool to ignore attributes, the tool simply has to treat (* *) just
like the /* */ comment and ignore everything in between. I anticipate that
there will be multi-line attributes that are well-handled by the four
characters (* *) without the need to handle many more characters such as
//(* which would not work as John has requested for a multi-line attribute,
because now a tool that ignores attributes that start with //(* will fail
when the attribute continues on the next line (since // only denotes a
1-line comment).
Although an interesting "what if," I think this falls under the category of
water under the bridge. I am satisfied with the chosen attribute enhancement.
Regards - Cliff
At 09:48 AM 9/3/02 -0700, John Michael Williams wrote:
...
>I DON'T say that this token (string) must follow
>immediately the token(s) opening a comment.
>This would miss the point.
>
>I say that the lead characters of
>such a token string must be identical to the opening
>comment delimiter in the language under
>consideration. That's all I suggest.
>
>For example, in C++ or verilog,
>"///", or "//(*" would be examples of the kind of
>tokenized string I am trying to describe. In
>VHDL, "--/" or "--(*"; in old C, "/*/" or "/*(*".
>No optional spaces.
...
> John
> jwill@AstraGate.net
> John Michael Williams
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, Synthesis and Verification Training
This archive was generated by hypermail 2b28 : Wed Oct 09 2002 - 15:51:26 PDT