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.