Subject: Re: 1364.1 pragmas
From: John Michael Williams (jwill@AstraGate.net)
Date: Fri Aug 30 2002 - 16:22:08 PDT
Hi Cliff.
You are raising valid points, but you
still are missing the point: It doesn't
matter whether an attribute is in a "comment"
or in the "Verilog"; all possible errors will
occur just as likely either way! All arguments
invoking errors in comments also apply equally
to attributes in the Verilog.
My point is that IF attributes are to be inserted
as "comments", they merely need a Std to require
some kind of standard, distinguishing format.
Then, those apparent comments will become part
of the Verilog during scanning. The flag for
a directive then is an anticomment flag.
For example, suppose the Std required that a comment
directive have the format, first nonwhite chars = "///",
and terminate on the next NL (\n or whatever). Or,
suppose it required starting with "//(*".
The designer then can mispell the attribute words, and
the parser will flag it just as well as in the Verilog
attribute case.
I agree that a careless or beginner designer might
somehow type "//--" or something instead of "///"
(in the first example above), and the attribute will be
missed, but this is a fantastically unlikely event
when the designer knows what the proper format should be.
So, there is no real relevance of spelling ability or
typing ability, at least as I see it.
I suspect that the WG in the past was assuming that a
"comment directive" would have to be a plain comment with
keywords inside. Instead, what is needed is a line comment
delimiter, in whatever language, immediately associated with
a TOKEN introducing the remainder of the line (or possibly
more) as a directive.
I agree that a scanner then would have to
take a little more time to separate comments from
directives; but, with, say, 4 chars per line to check
instead of 2, the penalty in processing time would be
negligible. Also, tools stripping comments then would
merely not strip comment directives (attributes).
--
John
jwill@AstraGate.net
John Michael Williams
Clifford E. Cummings wrote:
>
> Hi, John -
>
> Let me give one more example of where attributes may have value over
> comment-directives. This is from the 1364.1 perspective as opposed to the
> Verilog-2001 perspective. This is something that we considered in 1364.1
> but this advantage may go away based on the current debate on how
> attributes should and should not be used.
>
> One advantage to the (* synthesis, ... *) style of attributes was that
> tools could do a better job of recognizing directive syntax errors. By
> requiring that "synthesis" be the first attribute, tools could keep a
> separate list of legal 1st-attributes and report errors if the 1st
> attribute was not recognized. The 1st-attribute file might look something
> like this for a synthesis tool:
>
> // This File: synthesis.att
> synthesis: read
> synthesis, romstyle: ignore
> fv: ignore
> placement: ignore
> coverage: ignore
>
> This file would inform the synthesis too that all synthesis directives
> should be read, except for the synthesis-romstyle directive, which might
> not be supported by this synthesis tool.
>
> This file further informs the synthesis tool that any attribute list that
> starts with fv (formal verification), placement or coverage are valid
> attributes but that they should be ignored.
>
> Now if an engineer adds one of the following (both words misspelled):
> (* sinthesis, paralel_case *) or // sinthesis paralel_case
>
> The comment is just a comment and will be ignored and the intended onehot
> FSM optimization was ignored and the resultant gate-level implementation is
> now huge. The formal verification tool reports no problem with the
> synthesized design (since there is no parallel_case directive in the code).
> On the other hand, using the attribute with a mechanism similar to what is
> shown above, the synthesis tool first reports that "sinthesis is not a
> recognized attribute" and after correcting "synthesis" the synthesis tool
> now reports that "paralel_case" is an illegal synthesis directive."
>
> Concerning the examples given by Shalom and Stu with (* synthesis,
> full_case *) and (* fv, full_case *), since formal verification tools check
> equivalency between an RTL model (with synthesis directives) and a
> gate-level model, I would assume that FV tools will need to read some of
> the synthesis directives. The attribute file for an FV tool might look
> something like this:
>
> // This file: fv.att
> synthesis: ignore
> synthesis, full_case: read
> synthesis, parallel_case: read
> fv: read
> placement: ignore
> coverage: ignore
>
> And now an engineer does not have to add both (* synthesis, full_case *)
> and (* fv, full_case *). Note that engineers already use // synopsys
> full_case with their synthesis tools, they do not add another // fv
> fulle_case directive, so this seems consistent with current practices.
>
> Using this technique, if a whole new type of tool, such as a behavioral
> compiler with its own set of directives is added to a common tool suite,
> getting your RTL synthesis tool to ignore behavioral compiler directives
> while still doing syntax checking of all other existing attributes may be
> as easy as adding to the synthesis.att file:
>
> behavioral: ignore
>
> This would not be practical with comment-directives. Too many first words
> in a comment to be ignored.
>
> Having given this elaborate example, now I give the disclaimer: none of the
> above has been defined in either the 1364.1 or the Verilog-2001 standards
> and as you have seen in the debates, the 1st-attribute domain style is
> quite objectionable to many of the Verilog-2001 committee and may be
> destined for change, nullifying the cute potential feature described above.
>
> The above is just one of the thoughts that crossed our minds when we
> defined attributes as we did for 1364.1
>
> I still like it but I may be outnumbered.
>
> Regards - Cliff
>
> At 04:37 PM 8/29/02 -0700, John Michael Williams wrote:
> >Hi Cliff.
> >
> >I am not convinced by the reasons you give.
> >...
>
> >But, thanks for the explanation.
> >
> >--
> > 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 : Fri Aug 30 2002 - 16:24:43 PDT