Subject: Re: 1364.1 pragmas
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri Aug 30 2002 - 15:51:00 PDT
At 05:53 PM 8/30/02 -0400, you wrote:
>Precedence: bulk
>
> >True, but I hate tools that give boat-loads of warnings without an
> >efficient way to suppress them. The 1st attribute domain style greatly
> >simplified the task that a user might have of turning off warnings for
> >legal but irrelevant attributes. One could turn off all warnings but then
> >we lose the attribute-checking capability.
>
> >From what Stu has said about PLI, it is reasonable to have the order of
>attributes be meaningful. I am not sure it is a good idea, but it would
>allow this kind of checking. It would still not allow the same name to
>be used for two different things.
>
>Note that there is no way for PLI to distinguish whether the attribute list
>was all inside one (* *) pair or multiple ones. They are all just attached
>in order. So you can't use that as an end delimiter. If you want to bracket
>the synthesis attributes somehow, you would need a second attribute to use
>as an end delimiter, e.g. endsynthesis. This was another problem with the
>1364.1 concept, from the PLI viewpoint.
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
Any tool that used the PLI to extract attributes could decide whether or
not to worry about domains and whether an attribute fell within a specific
domain.
Most tools that use the PLI are probably going to ignore attributes. Any
PLI-based tool that uses attributes can decide if it wants to syntax-check
attributes or just tally a list.
This reminds me of the Verilog-vs-VHDL argument surrounding case
statements. Verilog requires begin-end for groups of statements associated
with a single case item while VHDL does not. Verilog requires the begin-end
because case items can be arbitrary expressions and determining where the
expression could start is difficult if not preceded by "end" (for a group
of case-item-statements) or by ";" (for a single case-item-statement). I
think tools could automatically determine the end of their attribute-domain
without an end statement.
>With order being meaningful, and a pair of bracketing directives, you can
>then specify which attributes are intended for synthesis. Just do
>(* synthesis, fullcase, parallelcase, endsynthesis, fv, foo, endfv *)
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.
No matter what we do with attributes, if three different tools decide that
they need the "foo" attribute, where foo means something different to each
tool, unless the tools are permitted to impose (* domain1, foo *) (*
domain2, foo="all" *) (* domain3, foo = 2 *), the current PLI is not going
to help (this is why I think we may have done a little too much defining of
attributes for Verilog-2001).
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.
For the most part, simulators are not going to do anything with attributes.
>Then the synthesis tool can check everything between the two bracketing
>attributes to make sure it is recognized. It could refuse to accept
>anything outside the bracketing, or accept it but not do checking, or
>whatever. Formal verification could recognize the stuff intended for
>synthesis, possibly checking it, and use whatever it wants out of it.
>It can also check inside its own bracketing.
*** key statement!! ***
>What it can't do is reuse
>the same name without affecting the synthesis.
*** endkey statement!! ***
> You also can't use the
>synthesis/endsynthesis bracketing to define two separated groupings, since
>one attribute will replace the other. Nor can you nest them in any way,
>for the same reason.
Maybe we could give the following a second chance! ;-)
>BTW, when we discussed the behavior of duplicate attributes before the
>standard, I proposed that we just keep the raw attribute list that the
>user specified, duplicates and all. The PLI would provide the exact list
>that the user had specified, including duplicates. The idea was to provide
>maximum flexibility for the tool to decide what to do with duplicates.
>Nobody else liked this idea.
>
>Now I want to point out that this would have allowed the kind of "domains"
>that 1364.1 is trying to use (if you added a second attribute to mark the
>end, as described above).
>
>So let me just say "I told you so!"
Yeah, yeah! Unfortunately when you presented it before, you did not have
this good reason to back the proposal. I have had many proposals fail
because I had not presented them well enough for people to grasp the value
of the proposal. I proposed implicit 1-bit regs for Verilog-2001 but was
voted down. Then I gave a conference paper on the same subject with
multiple examples and multiple slides with graphics and many of the same
people who voted against the proposal for Verilog-2001 came up and said,
"oh, now I see!"
I think you would find a much more receptive audience now to keeping the
raw attribute list (if it gives me domains, I will second the proposal
now ;-)
>Steven Sharp
>sharp@cadence.com
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 : Fri Aug 30 2002 - 16:08:06 PDT