| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 517
|
| Notify-List |
|
| Category | errata
|
| Synopsis | 27.14: No discussion on what to return if there is no value for an object
|
| State | open
|
| Class | errata-ptf
|
| Arrival-Date | Dec 12 2003
|
| Originator | Charles Dawson
|
| Release |
|
| Environment |
|
| Description |
27.14: 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? |
| Fix |
Unknown |
| Audit-Trail |
From: Shalom.Bresticker@freescale.com To: ptf-bugs@boyd.com Cc: Subject: Re: errata/517: No discussion on what to return if there is no value for an object Date: Tue, 4 May 2004 17:31:27 +0300 (IDT) ---------- Forwarded message ---------- Date: Mon, 03 May 2004 10:02:45 -0400 From: Charles Dawson <chas@cadence.com> To: "Garnett, Jim" <jimg@model.com> Cc: PTF <ptf@boyd.com> Subject: Re: PTF 517 - Preliminary Proposal 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 |
| Unformatted |
|
Hosted by Boyd Technology