Subject: Re: 1364.1 pragmas
From: David Bishop (dbishop@server.vhdl.org)
Date: Mon Sep 02 2002 - 12:39:09 PDT
-------- Original Message --------
Date: Fri, 30 Aug 2002 17:53:41 -0400 (EDT)
From: Steven Sharp <sharp@cadence.com>
Reply-To: Steven Sharp <sharp@cadence.com>
Subject: Re: 1364.1 pragmas
To: vlog-synth@server.eda.org, etf@boyd.com
>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.
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 *)
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. What it can't do is reuse
the same name without affecting the synthesis. 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.
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!"
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Mon Sep 02 2002 - 12:45:24 PDT