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

hi Jim
A zero value in the value union. I understand this would make the
non-pointer union values indistinguishable. This request actually came
in from a customer who wants to be able to distinguish the case of
out-of-bounds. My personal goal is clarification, there are potentially
other ways to do this too, for example in the format field. 
Abi

-----Original Message-----
From: Jim Vellenga [mailto:vellenga@cadence.com] 
Sent: Wednesday, May 23, 2007 7:26 AM
To: Moorhouse, Abigail; Charlie Dawson; sv-cc@eda.org
Subject: 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.