Subject: RE: 1364.1 pragmas
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Aug 28 2002 - 15:51:46 PDT
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?
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_."
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. Welcome to the world of global name spaces!
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:02:04 PDT