Subject: Re: 1364.1 pragmas
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Aug 29 2002 - 15:53:49 PDT
Hi, All -
The debate about 1364.1 attributes is a good one. I wish we had had all of
these discussions while we were working on the 1364.1 standard. That having
been said, what is the next step? Do we rework 1364.1 attributes or do we
keep them as is?
I am beginning to wonder if we were too restrictive in defining attributes
for the Verilog-2001 Standard. I would like to keep the attributes as
defined in the 1364.1 standard but I am willing to consider alternative
proposals. Mac has made a proposal and Steve Sharp is close to making a
proposal.
What say ye?
More thoughts and comments below.
Regards - Cliff
At 02:34 PM 8/29/02 -0400, Steven Sharp wrote:
> >Well that may be fine for tools which use PLI, i.e., simulators,
> >but all the other tools in the world don't use PLI.
>
> If PLI were complete, any other tool could be implemented as a PLI app.
> One of its uses is as a platform for building other tools, which are not
> necessarily related to simulation. It effectively creates a front-end
> parser and elaborator for Verilog, based on any compliant simulator.
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?
> The point is: how can the standard specify what information a tool is
> supposed to be able to extract from attributes?
>
> One answer is: by specifying a complete interface for extracting that
> information, to act as an example.
>
> The PLI provides just such an interface. I always assumed it would be
> interpreted as the specification for what information attributes provide,
> even in tools that don't use that particular interface to do it. Without
> that assumption to provide a specification of how attributes are supposed
> to work, attributes don't provide significant benefit over directives in
> comments. I wouldn't have worked to keep them in the standard.
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.
> Obviously, others did not interpret the standard the same way. I think
> that my interpretation of the standard provides a well-defined framework
> for how attributes are supposed to behave, independent of specific tools.
> I propose that we make this interpretation official, before too many
> other interpretations get made and render attributes as inconsistent as
> directives in comments.
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.
> Steven Sharp
> sharp@cadence.com
At 08:55 AM 8/29/02 -0700, Jayaram Bhasker wrote:
> First of all, the form for the pragmas have been discussed sufficiently in
> the 1364.1 WG.
>
> The question raised by Shalom/ETF is whether the form of pragmas that 1364.1
> is using is in violation of 1364.
>
> Not in my opinion based on what is in the 1364-2001 standard. The form and
> semantics of attributes have been pretty much left open by 1364 for a
user to
> use it in any form they choose.
>
> The question that Shalom raised is a tool issue, not a language issue, IMHO.
Having worked hard on 1364.1 attributes, I lean towards supporting this
position.
At 11:52 AM 8/29/02 +0300, Shalom Bresticker wrote:
> So it is just the same as in comments.
> In comments, too, tools detect whether the comment is a directive for them
> by looking at the beginning.
>
> I do have a reservation about the synthesis "keyword" in that it seems to
> reserve the following attributes just for synthesis tools.
>
> One of the problems today is that each tool has its own directives
> and we find that we want tools to be able to read directives intended
for other
> tools.
>
> We want formal verification tools to read fullcase directives, also, for
instance.
>
> I would not want to have to repeat myself:
> (* synthesis, fullcase *)
> (* fv, fullcase *)
This is a really good point. One interesting approach would be for another
group to standardize a set of formal verification-specific pragmas and also
standardize a set of synthesis pragmas that should also be read by formal
verification tools. FV tools would have to read both (* fv, ... *) and (*
synthesis, ... *) pragmas.
> > So why restrict them by a misleading domain name which implies that they
> are used only by tools in that domain?
Indeed the domain may be misleading, or the argument could be made that FV
tools need to monitor synthesis directives since they impact formal
verification. Today, FV tools read the // synopsys ... directives.
> Shalom
>
>
> Paul Graham wrote:
> > The nice thing about (* synthesis, <other attributes> *) is that
> > "synthesis" now does become a domain keyword and the 1364.1 Standard
> > requires that it be listed first, which helps synthesis tools to quickly
> > identify and read only attributes that are intended for that tool.
>
> Why is it necessary to give a synthesis tool additional aid in quickly
> identifying and reading synthesis attributes? Right now a synthesis tool
> must scan every comment in the input rtl to check for pragmas. Replacing
> comment pragmas by attributes will reduce the search from typically
hundreds
> or thousands of comments per design to probably tens of attributes. Even
> so, comment parsing is such an infinitesimally small part of a synthesis
> tool, in terms of lines of code and total run-time, that there's no need to
> try to make it easier on the tool.
>
> Paul
And Paul makes a good point. This really isn't that hard for a tool to
parse the information just once when a design is compiled (however I gave a
pretty scary map_to_module example mixed with other pragmas in an earlier
email message).
On the other hand, I see no reason to make it arbitrarily difficult for the
tool just because some tool coders are very talented.
Perhaps the better point is that it may be easier for an engineer reviewing
code to recognize what is happening if synthesis attributes are separated
from coverage and placement attributes. It's sort of like taking three
completely unrelated large combinational always blocks and combining them
into a single always block. The huge mixed sensitivity list with
arbitrarily arranged assignment statements are no problem for a simulation
or synthesis tool but for the engineer reviewing the code, understanding
what logic is being inferred may be very difficult to do.
> --
> Shalom Bresticker
At 11:44 AM 8/29/02 +0300, Shalom Bresticker wrote:
> Well that may be fine for tools which use PLI, i.e., simulators,
> but all the other tools in the world don't use PLI.
>
> Also, the 1364.1 proposal does not "throwing away the few
> things about them that were actually specified in the standard."
> It just adds something else.
>
> Just like tool directives in comments.
>
> Shalom
>
>
> Steven Sharp wrote:
> >As long as the syntax is legal, I thought the interpretation would be
> >pretty wide open, recognizing that simulators largely ignore attributes.
>
> I disagree. The meaning of a particular attribute attached to an object
> is wide open. What a tool chooses to do with the attributes after it
> determines their values is up to the tool. But that doesn't mean the
> standard doesn't specify any of the semantics.
>
> Some of the semantics are specified in the section on attributes, like
> how the value is determined. More detailed semantics are provided by
> the PLI interface to attributes. In my opinion, the PLI interface to
> attributes should be taken as the definition of what a tool can extract
> about the attributes. It is supposed to provide a completely generic
> interface to attributes, and thus defines the semantics of what can be
> determined about them. Yes, a tool with its own parser could use
> information like the order the attributes appeared (or how many spaces
> appeared between them). But if that were supposed to be meaningful,
> then the PLI interface would have provided a way of accessing it.
>
> The point of putting them into the standard was to provide some kind
> of consistency across tools. There is plenty of flexibility for tools
> to interpret the meaning of attributes, without throwing away the few
> things about them that were actually specified in the standard.
>
> Steven Sharp
> sharp@cadence.com
>
> --
> Shalom Bresticker
----------------------------------------------------
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 : Thu Aug 29 2002 - 16:01:36 PDT