RE: [sv-ac] Re: [sv-ec] Re: [sv-bc] Opinion on merging of P1364 and P1800

Teams,

I would like to merge the two documents in this
next round of edits.  I am willing to do my share
of editing/review work as needed.

Anyone accepting nominations for an LRM editor?
It might just happen that I have one in mind...

Regards,
Doug Warmke

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Stuart Sutherland
> Sent: Sunday, January 29, 2006 8:35 PM
> To: sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org; sv-cc@eda.org
> Subject: RE: [sv-ac] Re: [sv-ec] Re: [sv-bc] Opinion on 
> merging of P1364 and P1800
> 
> 
> I would like to second two of the comments on this thread, 
> and add some
> additional perspective on a third comment.
> 
> First, in my activities doing training work, I very, VERY, 
> often run unto
> real design/verification engineers that rely heavily on the 
> 1364 LRM.  In
> the past two years, I find engineers frequently referring to 
> the Accellera
> 3.1a SV LRM.  Personally, I would say that anyone from an EDA 
> company who
> thinks only EDA companies do, or can, or should, use the LRMs 
> are taking a
> very limited (or conceited) view of who uses EDA LRMs.
> 
> Second, I have, and continue to, talk to a lot of engineers 
> and engineering
> managers who honestly believe the that Verilog and 
> SystemVerilog are two
> separate languages, wholly independent of each other.  These, 
> or course, are
> the engineers who do not use the LRMs.  Because they feel 
> that SystemVerilog
> is a different language, I often hear comments from companies 
> that they
> cannot look at switching to SystemVerilog, because they are 
> currently locked
> into Verilog design flows.  Accellera and the IEEE 1800 
> committee have done
> a good job of making Verilog and SystemVerilog seem to be two 
> different
> standard, whether they intended to, or not.
> 
> In addition, In Karen's request to the committees, she did 
> not provide the
> proposal that was made at the recent P1800 meeting on the 
> time estimate for
> merging the to two standards.  This estimate was put forth by the last
> editor of the LRMs (me).  I don't know if I will be the 
> editor of the next
> LRM(s) (I haven't been asked), but IF I am the editor, my 
> proposal is 6 man
> weeks for the editor to create a draft of merged LRMs.  That 
> number was not
> pulled out of the air.  I spent a good deal of time looking at all the
> sections of each LRM to determine just how much work would be 
> involved.  If
> done early in the next revision cycle, before there is tons 
> of editing to
> do, those 6 man weeks could be accomplished in 3 calendar 
> months.  ALL of
> the work for this initial draft would be done by the editor, 
> and would not
> have any impact whatsoever on current committee activities.  Once the
> initial merged draft was completed, my proposal was to give 
> the committees 2
> calendar months to review and make comments on the work (and 
> to respond to
> editor questions/comments, if any).  This would be followed 
> by 1 calendar
> month for the editor to integrate feedback from the review. 
> 
> In brief the time impact to committee work would be a brief 
> period of time
> to review all chapters of a merged LRM.  Until a merged LRM 
> is available
> committees would continue to work as they are now.  Even 
> during the two
> month review process, committees can still continue to 
> discuss and specify
> corrections to the exiting LRMs.  Yes, changes specified 
> against the current
> separate LRMs, would pose a little challenge to the editor, 
> who would have
> to map section numbering to a merged document.  That 
> frequently happens,
> anyway, when changes add or delete sections/subsections.
> 
> Karen also asked the committees to comment on WHEN the LRMs 
> should be merged
> (if at all).  My proposal to the 1800 working group was to do 
> the merging
> right away, while the editor is not too busy because the 
> committees have not
> yet specified lots of changes.   I was asked by the 1800 
> working group if my
> estimates would change if the merging was done at the end of 
> the planned 2
> year revision cycle.  I do not think the amount of man weeks 
> would change
> significantly.  But, the number of calendar months would be 
> considerable
> longer, because as the next revisions to the two LRMs 
> progress, the editor
> will be spending more and more time doing editing, and have 
> far less time to
> do integration.  And of course, each change to a 1364 or 1800 
> LRM would also
> have to be duplicated in the work-in-progress merged LRM.
> 
> Just some things to chew on while you committee members 
> contemplate if/when
> the two standards should be merged.
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898
>   
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> > Behalf Of vhdlcohen@aol.com
> > Sent: Saturday, January 28, 2006 10:05 PM
> > To: sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org
> > Subject: [sv-ac] Re: [sv-ec] Re: [sv-bc] Opinion on merging 
> > of P1364 and P1800
> > 
> > I actually ran into someone form a large corporation who 
> thought that 
> > Verilog is not a subset of SystemVerilog,
> >  and was ambivalent about transitioning to SV.
> >  Ben
> > 
> > 
> >  -----Original Message-----
> >  From: Alec Stanculescu <alec@fintronic.com>
> >  To: Brad.Pierce@synopsys.com
> >  Cc: sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org
> >  Sent: Sat, 28 Jan 2006 20:27:04 -0800
> >  Subject: Re: [sv-ec] Re: [sv-bc] Opinion on merging of P1364 
> > and P1800
> > 
> >  Brad,
> > 
> >  I agree with your arguments and share your opinion that 
> there are not
> >  enough resources to mearge the two LRMs.
> > 
> >  However, the main reason for mearging the LRMs is to ensure that
> >  Verilog becomes a subset of SystemVerilog. Since this seems to
> >  everybody such a big task, it follows that Verilog is not 
> a subset of
> >  SystemVerilog.
> > 
> >  A second reason for mearging the LRMs is the fact that the P1800
> >  "promised" to produce one LRM at the next release of the 
> language and
> >  provided a specific date. Of course, the committee is 
> > allowed to change
> >  its mind, but usually it is preferable to keep promises.
> > 
> >  Regards,
> > 
> >  Alec
> > 
> > 
> > 
> > 
> >   
> > 
> 
>