Subject: Re: 1364.1 pragmas
From: David Bishop (dbishop@server.vhdl.org)
Date: Wed Sep 04 2002 - 04:34:42 PDT
-------- 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
In-reply-to: Your message of "Fri, 30 Aug 2002 16:22:08 PDT."
<3D6FFE20.954F6BF2@AstraGate.net>
Date: Tue, 03 Sep 2002 11:32:32 +0100
Sender: Daryl.Stewart@cl.cam.ac.uk
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 Sep 04 2002 - 04:44:06 PDT