Subject: Re: 1364.1 pragmas
From: John Michael Williams (jwill@AstraGate.net)
Date: Wed Oct 09 2002 - 13:06:44 PDT
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
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 : Wed Oct 09 2002 - 13:36:36 PDT