Subject: Re: 1364.1 pragmas
From: John Michael Williams (jwill@AstraGate.net)
Date: Tue Sep 03 2002 - 09:48:34 PDT
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 "//(*" 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 - 09:53:46 PDT