Re: Ship a revised Verilog-2001

From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Thu Feb 27 2003 - 07:56:22 PST

  • Next message: Michael McNamara: "Re: Ship a revised Verilog-2001"

    Precedence: bulk

    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.

    Gord.

    >
    > - bhasker
    >
    > ------
    > J. Bhasker, eSilicon Corp
    > 1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
    > jbhasker@esilicon.com, 610.439.6831, 610.770.9634(fax)
    >
    > -----Original Message-----
    > From: Stefen Boyd [mailto:stefen@boyd.com]
    > Sent: Thursday, February 27, 2003 3:23 AM
    > To: Stuart Sutherland
    > Cc: etf@boyd.com
    > Subject: Re: Ship a revised Verilog-2001
    >
    > Precedence: bulk
    >
    > Stu,
    >
    > 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
    > changebars!).
    >
    > Stefen
    >
    > At 04:18 PM 2/26/2003 -0800, Stuart Sutherland wrote:
    > >Precedence: bulk
    > >
    > >All,
    > >
    > >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
    > >Verilog-2001.
    > >
    > >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
    > >updated.
    > >
    > >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...
    > >
    > >Stu
    > >
    > >
    > >
    > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > >Stuart Sutherland Sutherland HDL Inc.
    > >stuart@sutherland-hdl.com 22805 SW 92nd Place
    > >phone: 503-692-0898 Tualatin, OR 97062
    > >www.sutherland-hdl.com
    > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    >
    > --------------------
    > Stefen Boyd Boyd Technology, Inc.
    > stefen@BoydTechInc.com (408)739-BOYD
    > www.BoydTechInc.com (408)739-1402 (fax) 

    -- 
----------------------------------------------------------------------
Gord Vreugdenhil                                 gvreugde@synopsys.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 and
    sponsored by Boyd Technology, Inc.