Subject: Re: 1364.1 pragmas
From: Michael McNamara (mac@verisity.com)
Date: Wed Oct 09 2002 - 15:51:18 PDT
John Michael Williams writes:
> Hi Dave.
>
> It would be nice if readers would actually read the suggestion, and
> not just pop back with stereotyped criticism, based on someone
> elses suggestion, possibly made and rejected years ago.
>
> My suggestion was to define the syntax of attributes NOT by using
> comments, but by using a token string which would be read
> (=ignored) as a comment by tools not equipped to read attributes.
>
> Please reply to the suggestion!
>
> --
> John
> jwill@AstraGate.net
> John Michael Williams
>
OK, but your first email on this:
| From: John Michael Williams <jwill@AstraGate.net>
| Sender: owner-vlog-synth@eda.org
| To: vlog-synth@eda.org
| Subject: Re: 1364.1 pragmas
| Date: Thu, 29 Aug 2002 07:47:57 -0700
|
| Hi Cliff.
|
| Clifford E. Cummings wrote:
| >
| > At 04:21 PM 8/28/02 -0700, you wrote:
| > ... 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).
| > ...
|
| WHY are you "trying to get vendors away from parsing comments?"
|
| Comments are the only syntactic commonality guaranteed to be shared
| among all simulation or synthesis tools, including Verilog, VHDL,
| SystemC, C, and even Pascal. Actually, the 1364.1 attribute
| construct is in the form of a Pascal comment!
|
| By embedding synthesis directives in comments, the directives, if
| nothing else, are totally portable. By being strict about the exact
| format of an embedded directive, accidental reading of a real
| comment as a directive can be minimized.
|
| I'm not saying the goal of shifting synthesis directives to
| language-specific constructs is wrong, but I don't see any good
| reason for it, and there seems to be at least one serious
| disadvantage (nonportability).
| --
| John
| jwill@AstraGate.net
| John Michael Williams
This email pretty clearly appears to state your position as being that
you felt that having synthesis directives in comments (which we all
know is the status quo) is perfectly fine.
The 1364-2001 introduction of attributes, which while they may look
like Pascal comments, are very definately not comments; instead they
have quite rigorously defined sematics. This seems to be what you now
want, from your most recent email.
This new attribute contruct was introduced by the 1364 committee to
get away from status quo, where an innocuous comment in code may be
interpreted incorrectly as a directive by some other tool many years
after the comment was written.
The attributes in 1364 ARE NOT COMMENTS!
They are defined in such a way that a tool that sees '(*' can happily
read until it sees '*)' throwing everything away, and still be
1364-2001 compliant.
1364 imposes no requirement that a tool do anything with attributes;
except that it accept them. Tools are free to assign semantic value
to attributes. Derivative standards are free to define semantic value
of attributes, and 1364.1 is the first to do so.
Your apparent position from your first email was that "Introduction of
attributes to Verilog is solving a non problem, and that parsing
comments is all we need." is a valid position to have, and many of us
interpreted your email to be your taking this position. Many of us
happen to disagree with this position.
However, taking your series of emails together, it appears possible
that you thought that (* ... *) either already is a comment structure
in Verilog, or that was introduced as a comment structure in
1364-2001, and your position is that with (* ... *) as a comment, it
is unreasonable for 1364.1 to define semantices for what happens
inside the deliminators??
It seems that part of your position is that a very valuable thing
about attributes would be the ability for tools that don't care to
easily ignore them. This is a very valid point, and is a position
that I share with you.
--
_
// Michael McNamara, Sr VP Technology <mac@verisity.com>
_ // 650-934-6888, 408-930-6875 Cell <http://www.verisity.com>
\\ // ___ ____ _ ___ _ ___ _ _ ___ ___ __ _ _ _ _
\\// |_ |___)|(___ |' | ` \ / | \ |_ (__ | / _ |\ |
\/ |__ | \ | ___)| | | |__/ |__ __)| \_/ | \|
This archive was generated by hypermail 2b28 : Wed Oct 09 2002 - 16:21:59 PDT