Subject: RE: 1364.1 pragmas
From: Jayaram Bhasker (JBhasker@esilicon.com)
Date: Thu Aug 29 2002 - 08:55:35 PDT
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.
--------------------------From Shalom
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 *)
------------------End from Shalom
Shalom is right that per 1364, the attribute can be written in multiple
ways. In 1364.1, we have
defined only one way which is acceptable for synthesis, which is, (*
synthesis, full_case *).
All other forms that he has mentoned are not 1364.1-compliant and do not
have the same semantics
as (* synthesis, full_case *). Note that 1364.1 is simply imposing
additional semantics on top of 1364
on the attribute form and usage.
- bhasker
-----Original Message-----
From: Clifford E. Cummings [mailto:cliffc@sunburst-design.com]
Sent: Wednesday, August 28, 2002 8:29 PM
To: vlog-synth@eda.org; etf@boyd.com
Subject: RE: 1364.1 pragmas
Precedence: bulk
At 04:21 PM 8/28/02 -0700, you wrote:
>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*)
I agree (except I believe attributes had to precede a keyword or identifier
and not be left dangling after the end of a statement).
>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,
I did read the email and I agree with the interpretation so far.
>then
>this is a radical change to the base language, and one that introduces
>a large inconsistancy.
I'm not sure I agree with this. My take on attributes from Verilog-2001
days was that we were trying to get vendors away from parsing comments (
//synopsys full_case) and provide a mechanism to make Verilog source code
useful to tools other than just simulators (or synthesis tools).
From the Verilog-2001 view, you are right that attributes are non-ordered
and non-domained. From the 1364.1 perspective, we tried to make attributes
useful to synthesis tools. We first considered (* synthesis fullcase *) but
that did violate Verilog-2001 syntax (two attributes with no comma or equal
sign in between). We then settled on (* synthesis, full_case *) and said
that 1364.1 compliant synthesis tools would recognize that the first
attribute implied that following attributes would be interpreted by the
synthesis tool. This does not impose any additional restrictions on a
Verilog-2001 compliant simulator (simulators largely consider attributes to
be funny-comments) and it preserves the near-structure that RTL coders have
become accustomed to ( // synthesis <directive or directives>).
I thought our Verilog-2001 treatment of attributes left a lot of latitude
to other tools so that they could add their hooks into the Verilog source
code. As long as the syntax is legal, I thought the interpretation would be
pretty wide open, recognizing that simulators largely ignore attributes.
>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.
1364.1 did not redefine attributes but it did define what attributes would
be recognized by 1364.1-compliant synthesis tools and that included the
requirement that synthesis tools would only consider attributes where the
first attribute in a list was "synthesis." After recognizing the first
"synthesis" attributes, 1364.1 compliant tools could then perform
reasonable syntax-checking on subsequent attributes, something that is
difficult to impose if synthesis attributes are mixed with other attributes
in any order.
Consider the Synopsys synthesis pragma:
/* synopsys resource r0:
map_to_module = "DW01_inc",
implementation = "cla",
ops = "a1"; */
Synopsys may not only want to require that "synthesis" be the leading
attribute, Synopsys may want to require either "map_to_module" or
"resource" be the second attribute in the list:
(* synthesis, resource = "r0", map_to_module = "DW01_inc", implementation =
"cla", ops = "a1" *)
If the attributes are mixed as follows, will this be difficult for Synopsys
to parse?
(* implementation = "cla", coverage = full, width = 7, resource = "r0",
placement = "A4", map_to_module = "DW01_inc", vera = "off", ops = "a1"
height = 5 *)
Now we could require that all of the map_to_module attributes have a
leading "synthesis_" text but attribute instances are going to become very
verbose if we do so.
1364.1 does not change attributes for simulators, but it does impose
attribute structures for synthesis tools. We may find it useful to modify
1364-2001 attributes to accommodate reasonable usage(?)
> > 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.
If an end user tool requires a fullcase attribute, it will break whether it
is written (* synthesis, fullcase *) (*fullcase, synthesis*) or
(*fullcase*). As you have pointed out, ordering is inconsequential to other
tools.
You have proposed a workable solution, that is, choose an attribute name
that is not as likely to exist in the global-attribute name space, such as
(*synthesis_fullcase*).
> 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!!
Although we did define the syntax and what would happen if an attribute was
redefined, I don't think it was our intention to define how attributes
would be used.
> > Regards - Cliff
I am not necessarily opposed to Mac's attribute proposals, but I did want
to offer an opposing view about whether or not 1364.1 violates 1364-2001.
We did spend months working on 1364.1 attributes and if everyone agrees
that it is the right thing to do, we could always go back and work it
again. If we do rework it, I hope we can draft Mac into championing a new
proposal. I really do not want to pass a 1364.1 ballot a second time only
to find the new proposal still is not good enough.
Regards - Cliff
----------------------------------------------------
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 - 09:03:15 PDT