Subject: Re: 1364.1 pragmas
From: David Bishop (dbishop@server.vhdl.org)
Date: Mon Sep 02 2002 - 13:03:02 PDT
-------- Original Message --------
Date: Sun, 01 Sep 2002 14:50:34 +0100
To: Steven Sharp <sharp@cadence.com>
From: Peter Flake <flake@co-design.com>
Subject: Re: 1364.1 pragmas
Cc: vlog-synth@server.eda.org, etf@boyd.com
In-Reply-To: <200208302153.g7ULrf427062@quicksand.cadence.com>
Hi Steven,
Could we not consider alternative syntax?
(* synthesis = "fullcase, parallelcase", fv = "foo" *)
Peter.
At 05:53 PM 8/30/02 -0400, Steven Sharp 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.
>
>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 - 13:08:40 PDT