From: Gordon Vreugdenhil (firstname.lastname@example.org)
Date: Thu Feb 27 2003 - 07:56:22 PST
Jayaram Bhasker wrote:
> Precedence: bulk
> A vendor is not likely to implement features in a "working" document, as these are subject to change
> anytime either by VSG or during ballot.
I don't think the above is true. I know that we take ETF/VSG decisions
into implementation asap since we don't want to have inconsistent
implementations out there. I don't think that VCS is the only one
that does that.
> First option is still, in my opinion, a better option.
> If you want a full LRM, the only way is to go to ballot with an updated LRM asap (which I suspect
> would only be bug fixed 2001 LRM).
I disagree. We aren't close enough to dealing with major issues for
a full LRM release and the IEEE process is long enough that the point
is likely moot anyway; vendors that are following the progress and
are implementing features that have changed will have already committed
long before ballot.
I fully support releasing drafts and/or clarifications as we deal with
major issues but pushing an LRM out too early will inevitably leave
significant issues still unresolved.
> - bhasker
> J. Bhasker, eSilicon Corp
> 1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
> email@example.com, 610.439.6831, 610.770.9634(fax)
> -----Original Message-----
> From: Stefen Boyd [mailto:firstname.lastname@example.org]
> Sent: Thursday, February 27, 2003 3:23 AM
> To: Stuart Sutherland
> Cc: email@example.com
> Subject: Re: Ship a revised Verilog-2001
> Precedence: bulk
> There is one more option. We are allowed to distribute
> drafts of the next version in progress without restrictions
> from the IEEE. Why not have the VSG create the document
> mentioned as option 1, but have a full draft that includes
> all fixes. That way it's not a 2003 version with no new stuff
> but no one has to mark up their copy to account for the
> corrections (hey, and they could even be marked with
> At 04:18 PM 2/26/2003 -0800, Stuart Sutherland wrote:
> >Precedence: bulk
> >In a hallway conversation at DVCon, a valid concern from an EDA vendor was
> >brought up. The concern is that they need a version of the 1364-2001 LRM
> >that reflects all of the ETF work has done. This vendor is concerned that
> >if the 1364 committee begins to add enhancements to 1364, they will have
> >to wait much longer for "clean" Verilog-2001 LRM. They are equally
> >concerned that some EDA vendors will use the current 1364-2001 LRM--with
> >all its formatting and other errata--as an excuse to postpone implementing
> >I agree with this vendor. The current LRM being distributed by the IEEE
> >is too difficult to use due to the many formatting errata the IEEE added
> >to the document. The many additional errata/clarifications that have been
> >approved by the ETF make the current LRM even less usable. We should have
> >a clean, up-to-date LRM as a baseline for when we begin to add enhancements.
> >My question to the ETF, then, is how can we publish an updated, cleaned up
> >version of the 1364-2001, before we move on to adding enhancements? My
> >strong preference is that the updated version is still identified as
> >1364-2001, perhaps with a "rev A", or something to indicate it has been
> >I had an opportunity to ask Gabe Moretti this question. His
> >recommendation was:
> >a) publish a compendium that lists all the errata and corrections. No
> >re-balloting would be involved, but the corrections would be a separate
> >document, and not part of the published 1364-2001 LRM.
> >b) Use the current PAR that is due to be approved in March for a
> >1264-2004, to rush through a corrected LRM. A re-ballot would be
> >necessary, but Gabe said if the ballot clearly indicates that the new LRM
> >is correcting typographical errors, the ballot process should be very
> >quick. It would be possible to have an updated LRM balloted and done in
> >time for the 2003 December REVCOM.
> >The first option is simple, but means but user's would have to manually
> >mark corrections in their existing 1264-2001 LRMs (or keeping flipping
> >back and forth between multiple PDF files). I think most, if not all,
> >readers of the LRM would like a clean, revised LRM.
> >The second option, if I understand Gabe correctly, means there would be a
> >1364-2003, that has no new language features from 1364-2001. I am not
> >keen about this, but am willing to live with it, if that is the only way
> >to get a clean Verilog-2001 LRM.
> >I hope to hear some feedback on my thoughts...
> >Stuart Sutherland Sutherland HDL Inc.
> >firstname.lastname@example.org 22805 SW 92nd Place
> >phone: 503-692-0898 Tualatin, OR 97062
> Stefen Boyd Boyd Technology, Inc.
> stefen@BoydTechInc.com (408)739-BOYD
> www.BoydTechInc.com (408)739-1402 (fax)
-- ---------------------------------------------------------------------- Gord Vreugdenhil email@example.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2.1.4
: Thu Feb 27 2003 - 07:57:02 PST
sponsored by Boyd Technology, Inc.