[sv-ec] Opinion on merging of P1364 and P1800

Forwarding email from Mac...


> From: "Michael \(Mac\) McNamara" <mcnamara@cadence.com>
> To: "Steven Sharp" <sharp@cadence.com>, <sv-bc@server.eda.org>,
>         <sv-ac@server.eda.org>, <sv-ec@server.eda.org>,
>         <Brad.Pierce@synopsys.com>
>
> 
> 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
> 
> 

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------