[sv-cc] SV-CC agenda for 03/19/2008

Our next SV-CC meeting is on 03/19/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 EDT (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.  Approval of the agenda

3.  Review minutes from last meeting (03/12/2008)

4.  Liaisons

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

5.  Consent Agenda


6.  Expedited Agenda Items

   - Item 2262 Missing definition in vpi_user.h for vpiIsProtected
   - Item 1688 Performance of VPI access to memories and MDAs is inadequate

7.  New business

   - SV-AC and SV-CC collaboration
   - vpiArray issue in Item 1942
   - Review Item 1465 (per Shalom's request)
   - Questions on our feedback for Item 2182
   - Update on the Dynamic Objects proposal (John?)
   - Others?

8.  Review SV-CC items with proposals:

   - 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 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()

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

   - Others?

10.  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" and an "Expedited Proposals" in agenda.
   - Chas to add an "Agenda Approval" to the agenda.
   - Chas to schedule another Data Read API meeting after DVCon.
   - Bassam to implement the friendly amendment to Item 1599.
   - Chas to ask John Havlicek to join the SV-CC meeting when we discuss SV-AC issues.
   - Chas to ask the SV-AC to fix the #defines in proposal for Item 2005.
   - Francoise to bring up the issues we found with Item 2250 at Champions meeting.
   - Chuck to update proposal for Item 1230 with three friendly amendments.
   - JimV to add friendly amendment to proposal for Item 2216.
   - Chas to enter Mantis Items for Krzysztof Konopko's questions
   - Chas to tell SV-AC that we are okay with Item 2005 provided the move the #define

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