Subject: Re: 1364.1 pragmas
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Aug 30 2002 - 13:07:11 PDT
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 - 13:18:17 PDT