In addition, note that Chuck has submitted a nice clean proposal for correcting the missing #define's and colliding numbers in Annex N as part of a new Mantis item 2572. I believe that getting those changes implemented would be easy for Stu to do and would cover all our existing concerns. That would be true, whether or not we get the formal approval of the Working Group, although that certainly wouldn't hurt. Regards, Jim Vellenga ----------------------------------------------------------------------- Jim Vellenga (jvellenga@alum.mit.edu) Senior software engineer for team-based development; skilled at team- building while retaining a detailed technical knowledge of the project itself. Excellent at negotiating clear definitions (standards, interfaces, etc.) across functional and industry boundaries. 781-646-6778 ----------------------------------------------------------------------- Bresticker, Shalom wrote: > As far as I can see, the last P1800 meeting preceded the Annex N > discussions. > > Here is an excerpt from the January 14 SV-CC meeting minutes: > > > * Item 2226 > > Chuck has tried to do some review of Item 2226. John also looked at it > some too, but is concerned that he may miss details. Chuck asked if we > should roll some of the include file issues into comments back to the > editor. Abi pointed out that they were missing from the proposal, so > we cannot blame Stu. John pointed out that common sense wise, we > should ask him to put it in, regardless of where the error came in. > Jim suggested that we pass a motion to ask the P1800 committee to > allow a new proposal to handle the header file issue. Chas thinks > there is no harm in creating such a proposal. Abi and Chuck will work > on such a proposal. John will review and mark as closed or send back > to the editor. Chas will also review. Chuck will look to see if there > is a record of his last review of it. > > * Issues in the sv_vpi_user.h file > > There was a discussion on how to go about verifying the include file. > It is a fairly complicated process. Discussion on what to do with the > range from 800-899. The reader API in 1800-2005 used up to 874. John > suggested that we just excise the term 'Data Read API' from the > include file only. > > Shalom > > ------------------------------------------------------------------------ > *From:* owner-sv-cc@server.eda.org > [mailto:owner-sv-cc@server.eda.org] *On Behalf Of *Stuart Sutherland > *Sent:* Tuesday, January 27, 2009 10:31 AM > *To:* 'Shields, John'; 'SV-CC' > *Subject:* RE: [sv-cc] review of 0226 implementation in draft8 > > All of John's notes below can be made as editorial corrections, > and will be made in the final version of draft 8. > > > > Chas., I forget whether it was decided at the last working group > meeting to correct the numbering in Annex N as editorial changes, > or to flag the errata during the ballot process. Do you remember? > > > > Stu > > ~~~~~~~~~~~~~~ > > *Stuart Sutherland* > > stuart@sutherland-hdl.com > > (503) 692-0898 > > > > *From:* owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] *On > Behalf Of *Shields, John > *Sent:* Monday, January 26, 2009 11:22 PM > *To:* SV-CC > *Subject:* [sv-cc] review of 0226 implementation in draft8 > > > > Hi, > > > > Gosh this was fun! Clause 36, 38, and Annex C and L were > implemented correctly. Clause 37 has some minor cross reference > issues that were not what was documented and one issue with > diagram 37.39 Frames. Annex N has been discussed and concur with > the concerns raised about numbering issues with vpiAllocScheme and > cbEndOfObject. These are editorial issues which should be > corrected. There is also an omission of vpiObjId, as Abi noted a > couple of weeks ago. It was the first implementation of 0226 > changes but not in any subsequent revisions of our Annex N inputs > to the editor. Clearly, I dropped it and we all missed it across > at least 2 reviews. It has always been on the information model > diagram, of course. I don't care how we handle it procedurally, > but it would be just sad to drop the ball on it again if we should > defer it. > > > > Regards, John > > --------------------- > > The details are: > > > > Page 879, 37.3.7 is currently: > > > > Other transient objects include: > > 1) threads (see 37.39). > > 2) outdated and out of scope references made within a thread > > 3) iterators (objects of type *vpiIterator*), which are created by > calls to *vpi_iterate() *(see 37.23). > > 4) a *vpiSchedEvent *created by *vpi_put_value() *(see 37.34) > > 5) callbacks (see 37.36). > > > > and should be: > > > > Other transient objects include: > > 1) threads (see 37.40). > > 2) outdated and out of scope references made within a thread > > 3) iterators (objects of type *vpiIterator*), which are created by > calls to *vpi_iterate() *(see 38.23). > > 4) a *vpiSchedEvent *created by *vpi_put_value() *(see 38.34) > > 5) callbacks (see 38.36). > > > > On page 915, in note 10) of diagram 37.29 Class variables and > class objects, it should be: > > > > 10) For details on class object specific callbacks, see 38.36.1 > > > > In diagram 37.39 Frames, there remains a property: > > -> validity > > /int: vpiValid/ > > / / > > which no longer exists in the information model. I had removed > this from the framemaker version showing "changes only" for this > clause. In the full version of clause 37, this property was still > there. As you all know, it easier for everyone to review a > succinct changes only version and much easier for the editor to > incorporate my integrated version of those changes. This was my > editorial mistake and cleverly hidden, I might add. > > > > I will not repeat the Annex N changes to editor assigned values, > as Charlie documented them adequately in his Mantis note to 0226. > I will emphasize that we must have property vpiObjId in Annex N > with an appropriately assigned value: > > > > #define vpiObjId <editor value> /* Mantis 2226 */ > > > > > > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, > and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, > and is > believed to be clean. > > --------------------------------------------------------------------- > Intel Israel (74) Limited > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 27 07:30:19 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 27 2009 - 07:30:41 PST