Re: PTF 517 - Preliminary Proposal

From: Charles Dawson (chas@cadence.com)
Date: Mon May 03 2004 - 07:02:45 PDT

  • Next message: Charles Dawson: "PTF agenda for 5/3/2004"

    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

    This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 06:43:17 PDT and
    sponsored by Boyd Technology, Inc.