Re: PTF 517 - Preliminary Proposal

From: Shalom Bresticker (Shalom.Bresticker@freescale.com)
Date: Mon May 03 2004 - 09:11:27 PDT

  • Next message: Steven J. Dovich: "errata/578: -ptf/286:"

    Do you people have any problem with sending your mails to ptf-bugs@boyd.com with
    subject "errata/517: " ?

    Shalom

    Charles Dawson wrote:
    >
    > Hi Jim,
    >
    > Although I agree that none of the routines have a really good description
    > of what happens in erroneous situations, I think vpi_get_value() is more
    > likely to be called in certain corner case situations. In these situations
    > it would be good to have a more explicit description of how the routine
    > should function. To me the most interesting ones are:
    >
    > - When simulation has not yet begun, what is the value of an object that
    > you would otherwise normally be able to get a value for?
    > - Similarly, when simulation has completed?
    > - If you have a handle to a bit or part select that is out of range, what
    > is it's value?
    >
    > I think your second proposal should be added to all the routines to cover
    > the remaining situations, so people know how to handle errors.
    >
    > -Chas
    >
    > Garnett, Jim wrote:
    > > All,
    > >
    > > I wanted to provide a preliminary proposal as a first attempt to present
    > > a proposal to an open PTF errata.
    > >
    > > PTF Errata 517
    > >
    > > Synopsis : 27.14: No discussion on what to return if there is no value
    > > for an object
    > >
    > >
    > > Description : vpi_get_value() has no description of what happens if
    > > there is no value
    > > at any point for an object passed to it. For example,
    > > what happens if
    > > you pass it a handle to something that does not have a
    > > value such as a
    > > vpiModule object? What if simulation has not started
    > > yet. What is the
    > > value of a net at that point? After simulation has finished?
    > >
    > > Discussion : In looking into this issue, it seems that there are other
    > > vpi_get_... functions
    > > (vpi_get_systf_info, vpi_get_delays, and vpi_get_cb_info)
    > > that don't provide
    > > any information on what is returned if the "obj" passed to
    > > it is invalid. These
    > > other functions are not quite as unique as vpi_get_value
    > > in that its data
    > > structure (s_vpi_value) has a union with a wide variety of
    > > types. This wide
    > > variety of types is what would make it difficult to pass a
    > > known "invalid" value
    > > back. But in general, all the functions must allocate the
    > > data structure that is
    > > used for passing data and none of the functions explicitly
    > > describe what is
    > > returned when an invalid obj is passed in.
    > >
    > > Proposal : I see two possible proposals (that could and maybe should
    > > apply to all vpi_get...
    > > functions mentioned above);
    > >
    > > Proposal 1 : Basically change nothing. This is based on the premise
    > > that the only way to know
    > > for sure if the vpi_get_value function returned a valid
    > > value or not is to check
    > > to see if an error occurred with vpi_chk_error(). This
    > > would assume that the user
    > > looking at the documentation would know that
    > > vpi_chk_error existed and why/how
    > > to use the function.
    > >
    > > Proposal 2 : Add text to the vpi_get_value description that states
    > > that the user needs to check
    > > vpi_chk_error to ensure that the prior call was
    > > successful and thus the data
    > > structure is valid. The text could be as follows:
    > > To ensure that a valid s_vpi_value structure
    > > exists and an error did not occur,
    > > the vpi_chk_error routine should subsequently be
    > > called.
    > >
    > > and appended to the end of the first paragraph of the
    > > vpi_get_value description.
    > >
    > > Any feedback is appceciated.
    > >
    > > -- Jim Garnett
    > >
    > >
    > >
    > >
    > >
    >
    > --
    > Charles Dawson
    > Senior Engineering Manager
    > NC-Verilog Team
    > Cadence Design Systems, Inc.
    > 270 Billerica Road
    > Chelmsford, MA 01824
    > (978) 262 - 6273
    > chas@cadence.com 

    -- 
Shalom Bresticker                         Shalom.Bresticker @freescale.com
Design & Reuse Methodology                            Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                  Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                      Cell: +972 50 5441478

    [ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary

    This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 08:52:01 PDT and
    sponsored by Boyd Technology, Inc.