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

Well, if he/she isn't happy with having to make an
extra call, let me suggest one other alternative.  From
the write-up on vpi_get_value():

"The misc field in the s_vpi_value structure shall provide
for alternative value types, which can be implementation-
specific. If this field is utilized, one or more corresponding
format types shall also be provided."

This allow a particular implementation to build in an
additional format specification -- let's call it
vpiBinStrValWithChecking.  The immplementation could
define this to do just what your user is asking for,
rather than modifying the existing behavior of
vpiBinStrVal.  In addition or instead, one could put
flags in the "misc" field to indicate the reason for
the failure.

And if the SV-CC wanted, we could add formats such as
this to the standard as well.

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: Moorhouse, Abigail [mailto:abigailm@model.com] 
]Sent: Wednesday, May 23, 2007 4:10 PM
]To: Jim Vellenga; Charlie Dawson; sv-cc@eda.org
]Subject: RE: [sv-cc] SV-CC agenda for 05/23/2007
]
]hi Jim,
]I think my particular user was unhappy that they could get back a
]default value for an out-of-bounds element that was indistinguishable
]from a valid value, using only the information returned from
]vpi_get_value to make the evaluation. That is, further VPI calls or
]side-information about the indices are necessary, and I think what you
]are suggesting would still require that. Obviously we aren't strictly
]obliged to add yet more annotation to what we return from
]vpi_get_value(), just as $display doesn't, so the clarification I'm
]requesting might boil down to "you're out of luck".
]
]If the necessary information came back in the format field, I don't
]think we can use the OR method since that field is already used to
]define the format of the return value. Generally if the user directly
]requests the integer syntax with vpiIntVal, we don't give them back
]anything in the format field other than vpiIntVal. But arguably we do
]have alternatives even now that would get the message across that
]something odd happened, for example setting vpiSuppressVal in 
]the format
]field, with or without supplying the default value, or even changing it
]to one of the format types that uses a pointer and then setting the
]pointer to 0. We could specify that without any new definitions, though
]of course we would probably find that the existing behavior for any
]given simulator suits some people fine already! Plus it's a bit of an
]after-the-fact shoehorn.
]
]Abi 
]
]-----Original Message-----
]From: Jim Vellenga [mailto:vellenga@cadence.com] 
]Sent: Wednesday, May 23, 2007 11:44 AM
]To: Moorhouse, Abigail; Charlie Dawson; sv-cc@eda.org
]Subject: RE: [sv-cc] SV-CC agenda for 05/23/2007
]
]Perhaps a more general solution might be in order.  We could define a
]vpiNoValue property that could "or" together reasons why the object was
]invalid:
]
]  #define vpiNoValueOutOfRange      1 /* Index out of range */
]  #define vpiNoValueIndexNotInteger 2 /* Index not an integer value */
]  #define vpiNoValueNoInstance      4 /* Automatic variable not
]instantiated */
]  #define vpiNoValueDeletedFrame    8 /* Frame deleted */
]  #define vpiNoValueDeletedInstance 16 /* Class instance deleted */
]
]It's an idea.
]
]Regards,
]Jim Vellenga
]
]--------------------------------------------------------- 
]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: Moorhouse, Abigail [mailto:abigailm@model.com]
]]Sent: Wednesday, May 23, 2007 11:53 AM
]]To: Jim Vellenga; Charlie Dawson; sv-cc@eda.org
]]Subject: 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.