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
> 
> 
> 
> 
>   
>