Subject: Re: 1364.1 pragmas
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Tue Sep 03 2002 - 16:37:45 PDT
At 06:48 PM 9/3/02 -0400, Steven Sharp wrote:
> >Maybe the PLI can't distinguish but it seems other tools could recognize:
> >
> >synthesis, <list of synthesis attributes>, coverage (different recognized
> >domain thus ending synthesis domain), <list of coverage attributes>, etc
>
>What does it do when it is scanning a list of synthesis attributes and
>finds an unrecognized attribute? Does it assume that it is a misspelled
>synthesis attribute or a new "domain" that it hasn't heard of?
Of course, all of the following is not part of the standard, but yes, I
would assume the tool would assume a new unrecognized "domain" is a
misspelled attribute.
>In the
>first case, it will spew errors any time someone adds an attribute that
>the tool-writer hadn't heard of.
True. For the most part, I believe few attributes will be added to any RTL
models. I believe most attributes will be required for certain tools. For
those cases where a user has defined attributes, it may not be unreasonable
for the tool to require that the user prefix the user-attribute list with
the "user" domain attribute and the tool could be setup to ignore "user"
attributes. Since the user has to ignore non-user attributes, a few extra
stray "user" attributes is a smaller price to pay over bracketing all other
attributes with an "end_attribute" attribute.
>In the second case, it will be unable
>to provide warnings about misspelled attributes, because it will assume
>it is just the start of a new "domain".
Agreed. Which is why I do not favor this approach.
>If you want the tool to check your synthesis attributes for you, you will
>have to give it a clear indication of which ones are synthesis attributes.
>That requires marking the end of the list so it knows when to stop.
That is one solution. The other that I expounded earlier is to notify the
tool of other domains to be ignored, such as coverage, layout, placement,
fv, and now possibly the semi-generic "user." The tradeoff is:
(* synthesis, att1, endsynthesis *) (* fv, att2, endfv *) (* coverage,
att3, end coverage *) (* att4 *) // att4 is a user attribute
-VS-
(* synthesis, att1 *) (* fv, att2 *) (* coverage, att3 *) (* user, att4 *)
And if only one attribute is added to any statement (probably the most
common usage), requiring the end_attribute increases the number of
attributes needed by 50%.
One could now argue that requiring the leading domain attribute for the
same set of 1-attribute instances increases typing by 100%, which is true,
but I believe it offers more control over attribute name collisions for
tools that are not reading their attributes through the PLI. It also
closely mirrors common directive usage today. If you look at the 1364.1
attribute requirements, you will see that they are very close to what
engineers already do with directive-comments.
A couple of people have suggested that the 1364.1 Standard take control of
its favorite attribute names right now and let other tools avoid the
synthesis attribute names in the future. I think it risks significant
future name collision myself but I could support this proposal if it is the
will of the majority.
>Incidentally, a synthesis attribute lint-checker would be a prime candidate
>for a PLI-based tool. Even if the 1364.1 standard didn't specify any
>"bracketing" attributes, or your synthesis tool didn't check your attributes,
>you could build your own checker. Just put your own personal favorite
>bracketing attributes around the synthesis attributes. Then write a PLI
>app that scans your design and checks all attributes between your bracketing
>ones against a list of legal synthesis attributes.
Do most lint tools use the PLI? Mac?
I would think that most linting tools have their own parsers for speed
reasons. Mac?
> >I don't think "end" keywords will make much difference to the PLI. Consider:
> >
> >(* synthesis, fullcase=2, parallelcase, endsynthesis, fv, foo, fullcase=0,
> >endfv *)
> >
> >I think we still only have one fullcase as far as the PLI is concerned. As
> >I have stated in a couple of email messages now, I think formal
> >verification tools would also read synthesis attributes and not duplicate
> >them.
>
>That is correct. As I said, the domain idea doesn't work. And that isn't
>just for PLI; it goes for any implementation that complies with the standard.
>
>The marking was just a way of doing the syntax checks you were asking for,
>and it works for that.
>
> >On the other hand, tools that bypass the PLI and just search for the
> >required attributes enclosed within a set of funny braces with their
> >preferred domain attribute listed first, will have no problem picking out
> >the foo attribute of their choice, no matter what the Verilog simulator and
> >PLI assign to the foo attribute.
>
>Only if the tool is not IEEE Std 1364-2001 compliant. The standard specifies
>the value of the attribute, period. It doesn't just specify it for a
>simulator or PLI.
For most synthesis tools, the value of the attribute is either specified
(2001-compliant, I believe) or the existence of the non-zero attribute is
sufficient in itself (full_case, full_case=1, full_case="on" I believe are
all equivalent roughly equivalent to the synthesis tool and the synthesis
tool doesn't much care - full_case=0 would turn it off but nobody turns off
full_case in synthesis).
I still do not see where 1364.1 violates 1364-2001. 1364.1 merely says
which attributes will be defined for all 1364.1 compliant synthesis tools.
>Steven Sharp
>sharp@cadence.com
I can live with other proposals for 1364.1 attributes. I just want to make
sure people understand what we were thinking when we defined attribute
usage in 1364.1 the way we did. I further think the defined 1364.1 usage
complies with 1364-2001. I also believe the other proposed solutions
introduce and equal number of problems, so I am trying to understand their
advantages before jumping on the bandwagon.
I believe Paul Graham asked about actual synthesis directive usage in real
designs. I estimate (a real guess on my part) that large ASIC designs up to
1M gates will use 5-15 different synthesis attributes with a frequency of
once each in a design to up to 50 times each in a design. Rarely are
directives grouped on the same statement. Semi-common directives include:
synopsys full_case parallel_case (two directives - should only be used for
onehot FSMs)
synopsys infer_mux ((one directive, could be used frequently)
synopsys async_set_reset = "rst_n" (one directive with a value - could be
used frequently)
synopsys sync_set_reset = "rst_n" (ditto)
synopsys translate_off (one directive - used sparingly, mostly for
debugging - deprecated in 1364.1 in favor of `ifdef SYNTHESIS)
synopsys translate_on (ditto)
/* synopsys resource ... map_to_module ... label ... */ (used infrequently
but has multiple attributes that are interrelated)
Hope this helps.
Regards - Cliff
----------------------------------------------------
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 : Tue Sep 03 2002 - 16:48:09 PDT