Subject: Fw: 1364.1 pragmas
From: Pat Bryant (pkbryant2@attbi.com)
Date: Tue Sep 03 2002 - 13:09:54 PDT
John:
It seems that if one uses "token-ized" comments, then you
cannot have access to the attribute values via the PLI.
The PLI requires that the simulator/parser be able to recognize
these "token-ized" comments. Therefore, you don't gain anything
by these "token-ized" comments. We should keep the attribute
format currently in Verilog, allowing for modifications
based upon the current discussion concerning the existence of
keywords such as "synthesis" should be required.
Just my opinions.
Pat
---------------------------------------------------------------
Patrick [Pat] Bryant
pkbryant2@attbi.com
file://home.attbi.com/~pkbryant2
----- Original Message -----
From: John Michael Williams <jwill@AstraGate.net>
To: <vlog-synth@server.eda.org>
Sent: Tuesday, September 03, 2002 9:48 AM
Subject: Re: 1364.1 pragmas
> Hi Dave.
>
> You are missing my point entirely: You
> are assuming everything after a line comment
> delimiter must be a lot of "prose" (which
> for well-commented code will be more
> valuable commercially than the code!) or
> a collection of parsable keywords.
>
> I merely suggest NOT using either "comments"
> or "code" for attribute functionality: I
> suggest a token (string) delimiting the text (possibly
> on just one line) of the attribute or comment
> directive (call it what you want).
>
> I DON'T say that this token (string) must follow
> immediately the token(s) opening a comment.
> This would miss the point.
>
> I say that the lead characters of
> such a token string must be identical to the opening
> comment delimiter in the language under
> consideration. That's all I suggest.
>
> For example, in C++ or verilog,
> "///", or "file://(*" would be examples of the kind of
> tokenized string I am trying to describe. In
> VHDL, "--/" or "--(*"; in old C, "/*/" or "/*(*".
> No optional spaces.
>
> All a designer has to do is look up the STANDARD
> format of the synthesis directive, and insert it after
> the tokenized string. The only possible comment-related
> error would be to open a normal comment with the suggested
> tokenized string. Which I think would be highly
> improbable. Less probable than that a competent designer
> would accidentally type "and" instead of "or" somewhere.
>
> Now, with this, any tool such as a simulation compiler,
> will completely ignore the tokenization if it is not
> programmed to parse the content. Tools which are designed
> to use the content can be programmed to parse it,
> just as they parse comment directives or attributes
> at present.
>
> The advantage to this is that every language, even FORTRAN,
> has a comment format, so a tool in any language can
> use the text following the tokenized string the same
> way as any other tool programmed for that functionality.
>
> Thus, except only the leading open-comment chars, all tools
> in all languages would treat synthesis attributes (directives,
> etc. as you wish) the same way. This would fulfill the
> idea of a "standard" for a synthesis-related tool
> feature. Right now, we seem to have a hodge-podge
> of differing language constructs, each trying to get a
> synthesis back-end to do the same thing. So, in
> a sense, we have a back-end standard set of goals, but
> nothing truly standardized for a designer to use.
>
> --
> John
> jwill@AstraGate.net
> John Michael Williams
>
> David Bishop wrote:
> >
> > -------- Original Message --------
> > To: John Michael Williams <jwill@AstraGate.net>
> > cc: vlog-synth@server.eda.org, etf@boyd.com,
Daryl.Stewart@tenisontech.com
> > From: Daryl.Stewart@tenisontech.com
> > Reply-To: Daryl.Stewart@tenisontech.com
> > Subject: Re: 1364.1 pragmas
> >
> > John Michael Williams <jwill@AstraGate.net> wrote:
> > > It doesn't matter whether an attribute is in a "comment" or in the
"Verilog"
> >
> > A few things you can do when you define the SYNTAX OF ATTRIBUTES instead
of
> > using comments:
> >
> > Consider a tool used for editing code. Whether or not it knows about
every
> > attribute used by every tool it can SHOW them as attributes (with
correct
> > object associations) to the user.
> >
> > Consider a tool which has Verilog as both input and output. Unknown
attributes
> > may be preservable to some extent with correct associations to objects
instead
> > of random comments being included.
> >
> > Consider adding an attribute for a new type of tool. It will be a little
> > easier to ensure the new attributes are not already used (someone's
bound to
> > collate a list of "known attributes" somewhere) rather than ensuring it
does
> > not clash with any comment ever written in any piece of verilog.
> > e.g.
> > input fv; // fv is my favourite port name.
> > output syn; // syn is nice too.
> >
> > Wrt the idea of a tool warning about "unknown" // because
> > attributes the above imagined list of known // sometimes
> > attributes would help avoid false positives // I have
> > without wasting the compiler's time reading // lots of
> > every bit of free prose in comments (or do you // irrelevant stuff
> > not comment your code? ;) // to say
> >
> > People are also debating the problems of attributes clashing between
tools.
> > Firstly, any tool which clashes with P1364.1 attributes will not receive
good
> > customer acceptance. Secondly, with attributes (rather than comments) it
is
> > easier to imagine writing some kind of rewriter (preprocessor) (a perl
> > one-liner even) which will translate standard or even user invented
attributes
> > into suitable attributes for a desired tool, if you really want to.
> >
> > Most importantly attributes WILL be used via PLI. I produce C-models of
> > Verilog code interfaced via PLI and reading attributes attached to
components
> > is going to be incredibly useful. Comments are inaccessible to my C.
> >
> > Just because (* *) looks like a comment to you doesn't mean it is (I use
SML
> > which has (* *) as comments too so I'll have to learn to cross my eyes
;)
> > All languages do not use the same syntax for comments (thank goodness..)
> >
> > > My point is that IF attributes are to be inserted as "comments"
> >
> > They're not - they're defined carefully to attach to specific elements
of the
> > language. They cannot just be placed "anywhere" like comments.
> >
> > > Instead, what is needed is a line comment delimiter, in whatever
language,
> > > immediately associated with a TOKEN introducing the remainder of the
line
> > > (or possibly more) as a directive.
> >
> > Which is not very different - substitute (* for your /// and *) for \n
> >
> > Michael McNamara <mac@verisity.com> wrote
> >
> > > More and more I like what I believe was either Paul's or Steve's
> > > suggestion that 1364.1 assert its importance and make a land grab for
> > > the important attributes, like fullcase and parallel case; and then
> > > definitively define what these attributes mean.
> >
> > Absolutely.
> >
> > > A perhaps less ostentatious effort might be to define a very short
> > > prefix: sy_fullcase for these words.
> >
> > This is unimportant if people are willing to preprocess - which let's
face it
> > they always have in the past with no generates in Verilog.
> >
> > cheers
> > Daryl
> >
> > Tenison Technology
> > Hardware and software working together
> >
> > Tel: +44 1223 763596
> > Email: Daryl.Stewart@tenisontech.com
> > Web: www.tenisontech.com
This archive was generated by hypermail 2b28 : Tue Sep 03 2002 - 13:17:36 PDT