Subject: Re: 1364.1 pragmas
From: Michael McNamara (mac@verisity.com)
Date: Fri Aug 30 2002 - 08:29:24 PDT
Steven Sharp writes:
> Precedence: bulk
>
>
> >From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>
> >My own preference is to bypass the PLI as often as I can. I guess my
> >question to guys like Stu is, do 1364.1 attributes break PLI access?
>
> I avoid the stuff myself, but I think I have a pretty good understanding
> of what it is supposed to be capable of. Those capabilities include
> statically analyzing the design, perhaps completely independent of
> simulation. You could probably use it for a synthesis front-end if
> you wanted to. In practice, this approach would only be used for more
> specialized tools that don't warrant the investment to develop their own
> parser/elaborator.
>
> These tools are examples of what attributes are intended to control.
> I think that a standard attribute mechanism is particularly important
> to such tools. A synthesis tool with its own parser can do whatever
> it wants with things like directives in comments. A tool built on
> top of PLI doesn't have such a luxury. It needs a standard mechanism
> for annotating information onto the source, which it can then access
> through a standard PLI interface.
>
> Once such a mechanism is defined, however, the standalone tools like
> synthesizers might as well use it. And there are good reasons for
> them to follow the exact same rules that a PLI-based tool would have
> to use. It means there are a standard set of rules that a user can
> rely on, independent of what tools the attributes are intended for.
> Also, some PLI-based tools might need to access attributes intended
> for synthesis. If those are written so that there is information
> contained in something that they can't access (like the order of
> attributes), then they can't get that same information.
>
> Here is an illustrative (but not necessarily realistic) example.
> You could write a PLI app that found all of the case statements with
> fullcase synthesis attributes, and put in callbacks that checked
> whether they were ever executed with an unspecified case value during
> simulation. But if the PLI app can't tell whether a fullcase
> attribute appeared after a synthesis attribute and in the same (* *),
> then it can't determine whether the fullcase synthesis directive was
> set under the 1364.1 definition.
>
> I don't think it matters whether anyone actually writes any tools
> that use the PLI interface to attributes. What matters is that the
> interface provides a standard definition of how attributes work, so
> that they can be kept consistent across all tools.
>
> Without the PLI interface and the access model it provides, the standard
> might as well have said "(* and *) are a new kind of comment characters
> that imply that the contents are tool directives instead of human-readable
> comments. You can put them anywhere you want and put anything you want
> into them and tools might do something with them. Consult the manuals
> for your tools." It certainly would have saved a lot of time specifying
> things if nobody is going to follow what did get specified.
>
> >Amusing side note: Cadence (I know, not Steve Sharp) made the attributes
> >proposal for Verilog-2001. We gave Cadence grief for the (* *) syntax and
> >called the tokens the "funny braces." The first time I saw this syntax was
> >before Verilog-2001 efforts when doing mixed Verilog-VHDL simulations with
> >Cadence tools. Cadence tools required the (**) attribute to specify VHDL
> >tool information in the Verilog module header. Every Verilog simulator
> >choked on the attributes except for Cadence simulators. I guess I wasn't
> >too surprised when Cadence proposed (* *) attributes for inclusion in
> >Verilog-2001.
>
> I have an OVI Verilog LRM Version 2.0 dated March 1993 which specifies
> attributes with (* *) syntax. So they were actually standard before
> there was even an IEEE 1364-1995 standard. The OVI version has some
> serious problems that make them impossible to implement fully and way
> too complex. The Cadence tools only implement a subset of the OVI
> attributes. Apparently nobody else even made the effort, or came along
> after the IEEE standard effectively replaced the OVI standard. The
> proposal for the Verilog-2001 attributes is a simplified version that
> is more usable and implementable.
>
> >If the PLI is attribute-broken, I would consider this to be a strong
> >argument. I am not yet convinced that attributes are PLI-broken.
>
> I don't believe that the PLI interface guarantees the order of
> appearance of attributes relative to the source order. And there are
> cases where it would be unclear what the order was, independent of what
> the PLI interface provides.
>
> Consider (* fullcase = 0, synthesis, fullcase = 1 *). The standard
> specifies that the second value of 1 is used for fullcase. But did
> fullcase appear before synthesis or after? The value used was after,
> but it was first specified before.
>
> >From PLI, the attributes specified on a module definition and on an
> instantiation of that module are both made available to a module instance.
> There is a property that allows them to be distinguished, so that the
> PLI app can decide if it wants to treat them differently. But there
> is nothing to specify what order the app will see them in, and there
> is no obvious "source order" between them.
>
> If I understand the proposed 1364.1 mechanism properly, it doesn't even
> work with what is specified in section 2.8 of the standard. As I
> understand it, the idea was to use attributes for specific tool types as
> delimiters for attributes intended for that tool, to prevent name
> collisions. But section 2.8 already specifies what happens with name
> collisions, and it doesn't care about these supposed delimiters. If you
> specify
>
> (* synthesis, fullcase *) (* fv, fullcase=0 *)
> case
>
> then the attribute fullcase is 0. It isn't 1 for synthesis and 0 for
> formal verification; it is just plain 0. So states the last paragraph
> in section 2.8.
>
> Personally I think that the 1364.1 group was overly worried about
> name collisions. If everyone is afraid to define any attributes for
> fear that someone else might use the same name, then we end up without
> any attributes defined or used at all (or really long names with
> prefixes like synthesis_*, or attempts to build some kind of scoping
> mechanism that isn't part of the standard).
>
> Synthesis attributes are likely to be the most commonly used ones,
> and that justifies getting first pick of the names. Just take the
> attribute names you want and put them into the standard. Who is going
> to define fullcase to mean something else anyway? And if they do,
> then let *them* put a prefix on theirs to make it unique. If there
> are some synthesis attribute names that seem likely to be useful in
> different contexts, you can be nice and add a syn_ prefix on them
> (especially if they are not frequently used anyway). Synthesis is the
> 800-pound gorilla in the attribute space; take what you think you need.
>
> I think that there are bigger concerns than the possibility of name
> collisions. Like attributes never getting used at all because you
> made the mechanisms too complicated trying to avoid it. Or working
> differently in each tool because we couldn't settle on an interpretation,
> because it might be too restrictive.
>
> Steven Sharp
> sharp@cadence.com
>
>
I agree completely with everything Steve said.
One elaboration: My recollection is that it was Cadence that requested
that 1364-1995 not include OVI 2.0's attributes, because Cadence had
tried to implement them, and found problems. So rather than blaming
Cadence, we should be thanking them.
--
_
// Michael McNamara, Sr VP Technology <mac@verisity.com>
_ // 650-934-6888, 408-930-6875 Cell <http://www.verisity.com>
\\ // ___ ____ _ ___ _ ___ _ _ ___ ___ __ _ _ _ _
\\// |_ |___)|(___ |' | ` \ / | \ |_ (__ | / _ |\ |
\/ |__ | \ | ___)| | | |__/ |__ __)| \_/ | \|
This archive was generated by hypermail 2b28 : Fri Aug 30 2002 - 08:39:04 PDT