Subject: Re: 1364.1 pragmas
From: Shalom.Bresticker@motorola.com
Date: Thu Aug 29 2002 - 23:11:43 PDT
Another argument for attributes and against comments is that there are cases
where a tool rewrites the code and removes all the comments.
Shalom
On Thu, 29 Aug 2002, Clifford E. Cummings wrote:
> Date: Thu, 29 Aug 2002 15:53:49 -0700
> From: Clifford E. Cummings <cliffc@sunburst-design.com>
> To: vlog-synth@eda.org, etf@boyd.com
> Subject: Re: 1364.1 pragmas
>
> Precedence: bulk
>
> 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 - 23:19:30 PDT