From: Michael McNamara (email@example.com)
Date: Thu Feb 27 2003 - 11:57:34 PST
I like this suggestion; and further those EDA vendors that actively
participate are given somewhat of an inside track, further
facilitating our getting much needed additional help.
Stefen Boyd writes:
> 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)
This archive was generated by hypermail 2.1.4
: Thu Feb 27 2003 - 11:58:31 PST
sponsored by Boyd Technology, Inc.