[sv-cc] SV-CC agenda for 02/13/2008

Our next SV-CC meeting is on 02/13/2008.

The call-in information for this meeting is as follows:

   U.S.               866-807-0627
   International      203-955-5179
   Passcode           399143

Meeting will start at 11:30am EST (4:30pm GMT), and last for 1.5 hours.

AGENDA

1.  Review Patent information

   Go to:
     http://standards.ieee.org/board/pat/pat-slideset.ppt

2.  Review minutes from last meeting (01/30/2008)

3.  Liaisons

   - Chas to report on P1800 meeting
   - Francoise to report on Champion issues
   - Anyone care to make a report?

4.  Consent Agenda

   - Declare Item 0587 a duplicate of Item 572
   - Declare Item 0588 a duplicate of Item 572
   - Declare Item 0589 a duplicate of Item 572
   - Close Item 0559 as Not a Bug - clarification added as NOTE
   - Close Item 0567 as Not a Bug - clarification added as NOTE
   - Close Item 0568 as Not a Bug - clarification added as NOTE
   - Close Item 0579 as Not a Bug - clarification added as NOTE
   - Close Item 0581 as Not a Bug - clarification added as NOTE
   - Close Item 0592 as Not a Bug - clarification added as NOTE
   - Close Item 2144 as Not a Bug - clarification added as NOTE
   - Close Item 2147 as Not a Bug - clarification added as NOTE

5.  New business

   - Putting things onto the Consent Agenda
   - Item 1599 The assertion API and VPI sections need changes as per mantis #805
   - SV-AC issues reported by John Havlicek

6.  Review SV-CC items with proposals:

   - Item 1230 How to represent packed arrays of complex types in VPI
   - Item 2218 Clarify meaning of vpi_compare_objects()
   - Item 2216 Details missing from VPI Generates object diagram
   - Item 2143 How should VPI handle index expressions with side effects?
   - Item 2054 Draft 3A, Section 40 - Deprecate Data Read API
   - Item 2094 Need to extend VPI to handle class specializations
   - Item 1599 The assertion API and VPI sections need changes as per mantis #805
   - Item 2262 Missing definition in vpi_user.h for vpiIsProtected
   - Item 1688 Performance of VPI access to memories and MDAs is inadequate
   - Item 0555 31.1 Introduction not needed in context of the larger document
   - Item 0556 31.2 Beginning of this section not needed in larger context of spec
   - Item 0557 31.3.1 specific references to objects should be removed
   - Item 0558 31.3.3 rename section to "Access availability"
   - Item 0560 31.4.1 & 31.4.2.1 Overloading vpi_handle() is a bad idea
   - Item 0561 31.4.2 vpi_free_object() should be explicitly referenced here
   - Item 0562 31.5 needless restriction on traverse object creation - poor terminology
   - Item 0563 31.5 diagram in figure 31-18 needs to be redrawn
   - Item 0565 31.6 remove first paragraph of this section
   - Item 0570 31.8.1 Need prototype for vpi_load_extension()
   - Item 0571 31.8.1 unnecessary complication added for vpi_close()
   - Item 0572 31.8 make use of the term 'user'
   - Item 0580 31.8.4 section is not necessary and colloquial
   - Item 0583 31.8.4.2 terminology first defined in a footnote?
   - Item 0584 31.8.4.2 implies that vpi_goto() creates new handle
   - Item 0593 31.12 Routines should be in table format
   - Item 2146 Data read API description references wrong header file
   - Item 2148 Unclear statement about error handling after calling vpi_unload()

7.  Review SV-CC items with proposals (Straw poll only):

   - Others?

8.  Review old business:

   - Francoise and Bassam to continue work on assignment patterns.
   - Francoise and Bassam to figure out what should happen when you get the
     size of a string constant.
   - Chas to update Item 1570.
   - Chas to ask the editor about Item 0417.
   - Steve to write a proposal for dealing with the inconsistencies with the
     protection properties.
   - Chas to talk with editor on re-arranging the VPI that is outside of the
     VPI sections.
   - Bassam, JimV, and Lisa Piper to work on issues found in Item 1503.
   - Chas to ask the editor for the framemaker for the Data Read API.
   - Chas to implement a "consent agenda".


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.