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

From: Michael \(Mac\) McNamara <mcnamara_at_.....>
Date: Wed Feb 01 2006 - 07:04:57 PST
At least two dozen merges of these two documents are going on right now,
outside of the committee. 

Each implementor of each tool (simulation, sythesis, et cetera) is doing
their own merge, and they do not have even the insight of Stuart.

Absent leadersip from the committee, those ill-informed merges will take
precedence over anything we do months or years from now.

If it was easy, they would not have us on the job.


Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven Sharp
Sent: Tuesday, January 31, 2006 5:10 PM
To: sv-bc@eda.org; sv-ac@eda.org; sv-ec@eda.org;
Brad.Pierce@synopsys.com
Subject: Re: [sv-bc] Re: Opinion on merging of P1364 and P1800


>From: "Brad Pierce" <Brad.Pierce@synopsys.com>

>The draft merge could be constructed in parallel with other work of the
>subcommittees, but the detailed review of that draft cannot.

I agree with Brad on this.

Merging these two documents will require considerable rewording of
the text.  If it isn't reworded, there will be various problems.
Some text will change meaning as its context changes if it isn't
reworded.  If the terminology isn't made consistent, the text will
be difficult to follow, and the reader may infer that two different
terms for the same thing are referring to different things, which
will change the meaning.

But of course, any rewording of existing text could directly change
the meaning.  Note that this is a much worse problem when the original
text is unclear or ambiguous.  The editor could unconsciously change
the text to match how they interpret the original, which may not match
how the committee would interpret the original.

This means that the draft merge would need a lot of review.

I don't even think it is realistic to assume that the merge itself can
be done in parallel with the other work.  The editor is bound to run
into decisions that need the input of the committees and affect a lot
of text.  If they make a guess and proceed, they risk a lot of rework
after it is reviewed.  Alternately, the committee may accept things
they didn't want, because otherwise there would be too much rework.

>Merging the LRMs will either result in fewer interpretations and errata
>fixes or an increase in the hours worked by SV-BC.  There's always a
>tradeoff.

With so much implementation work going on right now, interpretations
will be urgently needed.  With so much implementation work going on
right now, by SV-BC members, it will be hard to increase the hours
of SV-BC work.  The same may also apply to members who are users
busy trying to build new methodologies based on SV.

Steven Sharp
sharp@cadence.com
Received on Wed Feb 1 07:05:04 2006

This archive was generated by hypermail 2.1.8 : Wed Feb 01 2006 - 07:05:43 PST