RE: [sv-cc] SV-CC agenda for 05/23/2007

Abi, what do you mean by "getting" a NULL value?
vpi_get_value() has a void return, so are you
thinking about some field in the s_vpi_value structure?

Regards,
Jim

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Architect                              (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
]Behalf Of Moorhouse, Abigail
]Sent: Tuesday, May 22, 2007 7:17 PM
]To: Charlie Dawson; sv-cc@eda.org
]Subject: RE: [sv-cc] SV-CC agenda for 05/23/2007
]
]hi all,
]I have a question that I would like to put on the agenda for the
]meeting. When vpi_get_value() is called for an object with no real
]value, for example a varselect object where the indices are currently
]out of range, would you expect to get a NULL return, or a 
]pointer to the
]default value for the object? There is a precedent for the default
]value, because that is what $display does. However a NULL value seems
]more informative somehow.
]
]I would like this to be clarified in the LRM, unless it 
]already is and I
]have missed it, in which case I would like to be pointed to the LRM
]section, please.
]
]thanks,
]Abi
]
] 
]
]-----Original Message-----
]From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On
]Behalf Of Charlie Dawson
]Sent: Tuesday, May 22, 2007 2:33 PM
]To: sv-cc@server.eda.org
]Subject: [sv-cc] SV-CC agenda for 05/23/2007
]
]Our next SV-CC meeting is on 05/09/2007.
]
]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 12:00pm EDT (4:00pm GMT), and last for 1 hour.
]
]
]AGENDA
]
]1.  Review Patent information
]
]   Go to:
]     http://standards.ieee.org/board/pat/pat-slideset.ppt
]
]2.  Review minutes from last meeting (05/09/2007)
]
]3.  Liaisons
]
]   - Francoise to report on PASSED SV-BC items
]   - Anyone care to make a report?
]
]4.  New business
]
]   - Action items from Neil on draft 3.
]   - Request to BC committee to consider language in the LRM to require
]     implementations to have a mapping file which will bind names to
]$units
]     objects?
]   - Stu's question on the merged DPI clauses.
]   - Chuck's writeup of the consensus we reached at the face to face on
]     packed arrays (Item 1230).
]
]   - Others?
]
]5.  Review SV-CC items with proposals:
]
]   - Item 1726 Clarify meaning of vpiConstantSelect
]   - Item 1741 1800-2005 Section 27.50 Issues with foreach diagram
]   - Item 1385 Please document compatibility issues between 1364 and
]1800 VPI
]
]6.  Review SV-CC items with proposals (Straw poll only):
]
]   - Others?
]
]7.  Review old business:
]
]   - Francoise and Bassam to continue work on assignment patterns.
]   - Francoise to champion adding support for typed parameters to the
]     typespec diagrams.
]   - Abi to champion adding support for parameterized classes.
]   - Abi/JimV to champion improving the ability to compare objects.
]   - All to verify their Acknowledged Mantis Items.
]   - Steve to send out exact text on referring to a prior version.
]   - Chas to gather a list of all SV-CC approved mantis items 
]which have
]     not been incorporated into draft 2.
]   - Francoise, with Chuck's help, to put few questions together and
]send it
]     to Michael on deprecation of the term memory.
]   - Francoise to inquire from sv-bc on the current thinking regarding
]     deprecation of the term memory.
]   - Francoise to ask Stu from user perspective on need for 
]callbacks in
]the
]     pre and post observed regions.
]   - Michael to provide user perspective on need for callbacks in the
]pre and
]     post observed regions
]
]
]
]--
]This message has been scanned for viruses and dangerous content by
]MailScanner, and is believed to be clean.
]
]
]-- 
]This message has been scanned for viruses and
]dangerous content by MailScanner, and is
]believed to be clean.
]
]
]

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