Subject: RE: 1364.1 pragmas
From: Michael McNamara (mac@verisity.com)
Date: Wed Aug 28 2002 - 16:21:02 PDT
The issue is that the existing 1364 pragma definition gives no
hierarchy or structure to pragmas, so (* synthesis, foo *) is no
different than (* width=3, depth=7 *); and there is no guarentee that
a tool will see one before another, or even be able to tell
a = b (* synthesis *) + (* width=7 *) c; (* fullcase *)
from
a = b + c ; (* synthesis,fullcase *) (*width=7*)
Did we not read the same original email? That email essentially
stated that basically if indeed 1364.1 is proposing that (* a,b *)
have special meaning if and only if 'a' is the keyword synthesis, then
this is a radical change to the base language, and one that introduces
a large inconsistancy.
Note that 1364.1 could consider proposing standard definitions:
`define fullcase 1
`define parallelcase 2
`define nolatch 4
and then the following:
(* synthesis = synthesis|fullcase *)
would turn on fullcase, leaving other synthesis directives alone;
and
(* synthesis = fullcase + nolatch *)
would overwrite the previous state of synthesis with a value that
specifies fullcase with nolatches, and so on.
Clifford E. Cummings writes:
> Hi, All -
>
> I have given this more thought and I'm not sure there is a real
> problem here. As Shalom has stated, the IEEE Verilog-2001 Standard
> does not define domains, nor does it define any pragmas for Verilog
> simulation. Perhaps this is an opportunity refine the definition of
> attributes now that we have an idea of how they could be used?
Certainly the opportunity to do this in 1364-2001 has passed us by.
> 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. It also means that after "synthesis" an
> engineer could string a whole set of synthesis attributes without
> the verbosity of pre-pending every synthesis attribute with
> "synthesis_."
I am note sure how this truely works within the IEEE Standards
process, but one interpretation is that 1364.1 can not change 1364;
however it can add syntax and define subsets. The above 'nice thing'
appears to be a change to feature of 1364, which as far as I know, it
can not do.
> We envisioned that a future standard might choose "coverage" for a
> domain and even "simulation" for another domain, and since multiple
> (*...*) (*...*) attribute funny braces can be strung together
> before each keyword, each funny brace could help identify specific
> tools that should pay attention to the attributes.
>
> (* coverage_full, synthesis_fullcase, coverage_conditionals,
> synthesis_parallelcase *)
> - vs -
> (*coverage, full, conditionals*) (*synthesis, fullcase, parallelcase*)
>
> The domain names can also help vendors to do limited syntax checking of
> domain-specific attributes.
>
> (*synthesis, fulcase*) ==> warning, fulcase not a recognized synthesis
> attribute. Synthesis tools could permit initialization files with lists of
> attributes that are likely to be found but that should be ignored
> (attributes from other synthesis vendors).
>
> I could support Mac's proposal, but we actually did put a lot of thought
> into the 1364.1 attribute definitions and I think it is worth considering.
> 1364.1 attributes will not break any Verilog simulations that use
> attributes. The worst that can happen is that a 1364.1 attribute such as
> "fullcase" was also defined to be used differently with an end-user's
> in-house tool.
It is clear to me that your 'worst that can happen' is very
definately something that indeed will 'break any Verilog' that is
using 1364-2001.
The proposal I put forth in the previous email does not require a
change to 1364.
The proposal I put forth above in this email, which also works within
the existing 1364 standard, and more over allows one to selectively
turn off (* sythesis = sythesis &~ fullcase *) or turn on (* sythesis
= sythesis | parallelcase *) particular aspects of the synthesis
attribute while leaving the others unchanged. Further, it also
allows you to turn them all off:
(* synthesis = 0 *)
> Welcome to the world of global name spaces!
I want to go back to the world of standards!!
> Regards - Cliff
>
>
> At 08:22 AM 8/28/02 -0700, Michael McNamara wrote:
> >Precedence: bulk
> >
> >
> >To be succinct, 1364.1 introducing a set of 'known' pragmas, such as:
> >
> >(* synthesis_fullcase *)
> >(* synthesis_parallelcase *)
> >(* synthesis_nolatch *)
> >
> >where 1364.1 reserves the prefix 'synthesis_'
> >and defines today the various suffixes that have useful semantics,
> >and reserves the right to add additional suffixes as needed,
> >would be most useful, and would fit within the 1364-2001 definitions
> >of pragmas.
> >
> >-mac
> >
> >Shalom Bresticker writes:
> > > [1 <text/plain; us-ascii (7bit)>]
> > > During a conference call of the IEEE 1364 ETF (Errata Task Force) on
> > > August 12, 2002,
> > > reservations were expressed about the way 1364.1 is defining pragmas:
> > >
> > > (* synthesis, attribute_list *)
> > >
> > > As far as 1364 is concerned, there is no difference between any of the
> > > following, for example:
> > >
> > > (* synthesis, full_case *)
> > > (* full_case, synthesis *)
> > > (* synthesis *) (* full_case *)
> > > (* full_case *) (* synthesis *)
> > >
> > > The use of the "synthesis" attribute does not define a domain in which
> > > the full_case attribute exists.
> > >
> > > If the following occured,
> > > (* synthesis, full_case *) (* cucu, full_case = 0 *)
> > > then both attribute instances would refer to the same full_case
> > > attribute.
> > >
> > > Similarly, no order of attributes is guaranteed by 1364,
> > > so a tool could understand the preceding as
> > > (* cucu *) (* synthesis *) (* full_case=0 *) (* full_case *)
> > >
> > > Etc.
> > >
> > > I hope I have presented accurately the views which were presented during
> > > the ETF meeting.
> > >
> > > FYI.
> > >
> > > Sincerely,
> > > Shalom Bresticker
> > >
> > > --
> > > Shalom Bresticker Shalom.Bresticker@motorola.com
> > > Design & Reuse Methodology Tel: +972 9 9522268
> > > Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
> > > POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
> > >
> > > "The devil is in the details."
> > >
> > >
> > > [2 <text/html; us-ascii (7bit)>]
> > >
>
> ----------------------------------------------------
> 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 : Wed Aug 28 2002 - 16:29:35 PDT