Subject: Re: 1364.1 pragmas
From: David Bishop (dbishop@server.vhdl.org)
Date: Mon Sep 02 2002 - 12:20:06 PDT
-------- Original Message --------
Date: Thu, 29 Aug 2002 21:20:18 -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
>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
This archive was generated by hypermail 2b28 : Mon Sep 02 2002 - 12:26:18 PDT