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

Shalom,

Thank you for your well thought out comments.  I would like to counter a
couple of the thoughts you expressed.

You mention you have colleagues that use the LRMs, but have you asked them
whether they would prefer working with a single LRM or having to refer to
two different LRMs for the same language?

You note that there are many sub clauses in the 1364 LRM that would need
modification to allow for the extended data types in SV.  ISN'T THAT THE
POINT OF WHY MERGING THE LRMs IS NEEDED?  As it stands now, the SV LRM
refers back to the 1364 LRM for base language concepts, but the 1364 LRM has
the wrong syntax and semantic rules for the extensions.

You mention that the merged LRM would be over 1000 pages.  I have two points
to make on that.  First, I think the resultant document would be a bit less
than 1000 pages, but even if 1000 pages, that would be a significant
reduction from the combined total of 1246 pages that we have now.
Eliminating 200 to 300 redundant pages is a good reason to merge the LRM as
soon as possible!  Second, Karen did not provide the committees my full
proposal on merging the documents that I presented to the 1800 working
group.  That proposal stated that the merged document should be split into
multiple volumes.  At a minimum, the APIs (including the VPI) should be a
separate volume.  Further partition is possible, such as making assertions a
separate volume, but these topics would probably be too small as stand-alone
volumes.  By making the APIs a separate volume, the merged LRM that is of
interest to most users would be about the size of just one of the two LRMs
users now have to work with.

You argue that the LRMs should not be merged because "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."  I counter that this is
exactly why it is so important to merge the two LRMs right away!.  Both
user's and committee members are forced to look at both LRMs for each and
every language constructs, and try to decide when Verilog rules are correct,
and when to throw pieces of the rules out the window and mentally merge
pieces of SV rules into the Verilog rules.  Everyone needs one language,
with one set of rules.

You state that merging the documents will introduce "new errata".  I
STRONGLY DISAGREE!  Merging the documents won't introduce new errata, it
will be highlight existing problems of where 1364 says something works one
way, and 1800 says it works differently.  As two separate standards, those
existing problems may are not readily apparent, and even if found, it may
not be possible to fix them.  As two separate standards, often the only fix
to existing conflicts between the standards is add even more text to 1800
that says, in effect, "forget what is in 1364, SV changes it".  Merging the
standards is the only way to truly have a unified syntax and semantics
instead of what is currently a base language and an extensive set of
extensions that changes the rules of the base standard.

You say that 2 months is not enough time for committees to completely review
a merged draft.  If, and only if, the merging is put off to the end of the
next revision cycle, then I would agree that 2 months is not enough time to
find every possible subtle wording problem.  However, if the merging is done
right away, as I proposed, then the purpose of the 2-month review would be
to look for major problems with the merge, and to answer questions the
editor is sure to come up with during the merge process.  There may, or may
not, be subtle wording problems, such as was "net" used in a sentence when
"net or variable" would be more correct.  That type of cleanup can be found
and corrected over the course of the remainder of the two year revision
cycle.  Will every subtle problem be found?  Probably not in any of our
lifetimes.  BUT, those problems already exist in the split standards,
because, as you noted, 1364 and 1800 have different syntax and semantic
rules.   I submit that a lot more of the subtle wording problems between the
documents will be found and fixed in a merged document than will be found in
the current separate standards.

I disagree with several other statements in your message, but I think my
comments above capture the key reasons why merging the two standards ASAP is
best for both on-going committee work and for end users of the
Verilog/SystemVerilog standard.

Respectfully,

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
> Behalf Of Bresticker, Shalom
> Sent: Friday, February 03, 2006 12:29 AM
> To: sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org; sv-cc@eda.org
> Subject: [sv-cc] 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
> 
>