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

OK, now it is time for my own two cents, even if I am still a little
sick.

I also agree that I frequently encounter colleagues that use the LRMs,
often outdated versions unfortunately.

I don't agree that "Accellera and the IEEE 1800 committee have done a
good job of making Verilog and SystemVerilog seem to be two different
standards". I think anyone who has done even a tiny bit of reading about
these should come to the correct conclusion. Even the best and most
explicit statements won't help people with a reading comprehension
problem. More likely, some people heard the name "SystemVerilog" and
nothing further and jumped to some wrong conclusions. But that is not
Accellera's and IEEE's faults. Merging Verilog and SystemVerilog is not
necessarily going to solve that either. People will see that there is an
IEEE Std 1364-1995/2001/2005 called Verilog and an IEEE Std
1800-2005/2008 called SystemVerilog and still come to the conclusion
that they are two different languages. Even 'disappearing' 1364 would
not solve that. In any case, I don't think that such a massive effort
should be undertaken just to solve a problem of simple ignorance.

Stu proposes to give the committees 2 calendar months to review an
initial draft. I think that is terribly optimistic. Most of us do this
committee work as only a sideline. To review a 1000+ page document line
by line thoroughly even if it is split up into parts would take much
more time in my opinion.

Overall, my opinion is close to that of Steven Sharp, I think.

I greatly fear that a large number of new errata will be added by the
merge. This is much more than simple merging of two orthogonal texts.
Every single statement in the 1364 LRM will have to be reviewed and the
question asked, "Is this statement still 100% true and 100% complete in
the context of SystemVerilog?" As an example, the ability to use
variables in place of nets in most places in SystemVerilog (e.g.,
continuous assignments, ports) requires the question "Can variables be
used here?" to be asked everywhere nets are mentioned. It is going to be
far too easy to miss things and thus introduce a new error where one did
not exist before.

Another problem is that there are many places where complete new
formulations of the text are going to be necessary. For example, in
1364-2005, clause 3.5.1 describes all the ways integer constants can be
written. This clause is written in an integrative "holistic" way, that
is, it attempts to describe them in a unified way which covers all of
them. SystemVerilog came and added a few more ways. You can't just glue
them together. The unified holistic description of 1364 is no longer
that when you add in the new SV ways to write them. You have to
reformulate the text.

1364's experience in trying to integrate Verilog-2001 and -2005 changes
into 1364-1995 text shows just how hard that is. It took a lot of time
and a lot of mistakes were made, some existing to this day. Fixes took a
lot of time because it was often difficult to find an accurate
reformulation. It was often difficult to reach consensus. Some cases
were never fixed because we never figured out how to do it and/or no one
had the time to do it. An editor of a 1000+ page document is not going
to have the time to do justice to each sub-clause either.

We're talking about a two-year time frame. It is still not clear what
that means, but two years is not a lot of time, especially if it really
means that the initial ballot draft has to be ready after a year or a
year and a half.

Finally, one more point that bothers me is the modularity or
divide-and-conquer principle. It is true that there are some
disadvantages leaving 1364 as a separate LRM, but it also has
advantages. We currently have two big documents. Verilog is big and not
easy to learn but people like Cliff and Stu have conquered that problem.
Once a person has learned Verilog and has some experience, he can start
learning the SV extensions.
After combining them, there will only be one GIANT document of SV, which
I think is going to be much harder to teach and learn because it is
simply too big to absorb.

Regards,
Shalom



> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> Behalf Of Stuart Sutherland
> Sent: Monday, January 30, 2006 6:35 AM
> To: sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org; sv-cc@eda.org
> Subject: [sv-cc] 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