RE: [sv-cc] Fixes needed for sv_dpi_user.h

Sorry for the delay in responding ... I added the "Bassam input" below :-)!
Thx Doug, how come we did not find these in previous runs (just a few weeks
back) ? Strange ... Anyway thx a lot for testing!

5. Should be: PLI_INT32 vpi_get_assertion_info (vpiHandle,
p_vpi_assertion_info);

6. You mean the "new" vpi_user.h ? It's not in current vpi_user.h in EDA
sims ... If it's there sure we can reuse ...

7a. OK, the routines were written with "currently in the market" vpi_user.h
with PROTO_PARAMS in mind. I guess we can take out if that's the new way if
needed ...

7b. Yes this is an oversight, it means to put the vpiType of the handle
(i.e. vpi_get(vpiType, handle)) ... so this correction would be to have:
PLI_INT32 /* vpiType */

** Section 30.12 in section 30 with the prototypes would need this same
change as well. But may be this is not a major issue there we can mark for
future fix. It's pseudocode at that place anyway ...

Thx.
-Bassam.

--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Warmke,
Doug
Sent: Friday, January 14, 2005 6:19 PM
To: sv-cc@eda.org; stuart@sutherland-hdl.com
Subject: [sv-cc] Fixes needed for sv_dpi_user.h
Hello Stu and SV-CC,
I put together a small testcase in which I included sv_vpi_user.h and tried
to get things to compile using gcc 3.2 on Linux.
There are a number of issues, as I mentioned previously.
Note that none of these problems appear to be introduced by the LRM editor.
I think all of them were there in the SV 3.1a draft, but went undetected.
In this report I do make suggestions for solutions on a number of issues,
but there are others for which I think others are better qualified to make
suggestions.
Bassam is a likely candidate for this :^) .
I filed Mantis #353 to track these issues.
A decision needs to be made about getting #353 through the process to the WG
and eventually onto the draft ballot.  Or perhaps postponed.
Thanks and regards,
Doug
1.  On line 29, we should use " " include file syntax to induce
    normal header file search rules.  The line should be changed to:
    #include "vpi_user.h"
2.  On line 34 there is a stray '}' character.  Delete the line.
3.  On lines 154 and 155, the following appear:
    #define vpiLhs                    711
    #define vpiRhs                    712
    These are already defined in vpi_user.h on lines 188
    and 193, respectively.  Should not be redefined here.
    Either new constants should be defined, or we should
    remove these definitions and simply make use of the
    ones in vpi_user.h.
4.  On lines 250 and 251, the following appear:
    #define vpiValid                  646
    #define vpiActive                 647
    These are already defined in vpi_user.h on lines 477
    and 457, respectively.  Should not be redefined here.
    Either new constants should be defined, or we should
    remove these definitions and simply make use of the
    ones in vpi_user.h.
5.  On line 424 the following appears:
    PLI_INT32 vpi_get_assertion_info (assert_handle, p_vpi_assertion_info);
    This is not a legitimate prototype, since type names
    are missing for the function's formal arguments.
    Type names need to be added.  Can someone propose the correct types?
6.  On line 464 the following appears:
    #define vpiMember               840 /* Member of a collection */
    This is already defined in vpi_user.h on line 216.
    A new constant should be defined, or we should delete this
    one and rely on the definition from vpi_user.h.
    On this one, and the other redundant constant definitions,
    we will introduce "holes" in the numbering system by doing
    deletions.  Should we compress the following constants into
    the holes?  I would suggest "yes", since it's not possible
    that anyone actually implemented this file yet, else we would
    surely have seen plenty of emails about the problems in here.
7.  There is a set of functions related to the data reader API
    between lines 486 and 514.  There are two types of problem
    in these functions.
     /* load extension form for the reader extension */
     PLI_INT32 vpi_load_extension PROTO_PARAMS((PLI_BYTE8 *extension_name,
                                                PLI_BYTE8 *name,
                                                vpiType mode, ...))
     
     PLI_INT32 vpi_close PROTO_PARAMS((PLI_INT32 tool,
                                       vpiType prop,
                                       PLI_BYTE8* name));
     
     PLI_INT32 vpi_load_init PROTO_PARAMS((vpiHandle objCollection,
                                           vpiHandle scope,
                                           PLI_INT32 level));
     
     PLI_INT32 vpi_load PROTO_PARAMS((vpiHandle h));
     
     PLI_INT32 vpi_unload PROTO_PARAMS((vpiHandle h));
     
     vpiHandle vpi_create PROTO_PARAMS((vpiType prop,
                                        vpiHandle h,
                                        vpiHandle obj));
     
     vpiHandle vpi_goto PROTO_PARAMS((vpiType prop,
                                      vpiHandle obj,
                                      p_vpi_time time_p,
                                      PLI_INT32 *ret_code));
7a. There is no definition for PROTO_PARAMS in sv_vpi_user.h.
    (Recall, vpi_user.h cleans up after itself).  We should
    simply remove the PROTO_PARAMS() construct from around
    these argument lists.  This construct is no longer needed
    for any compilers in current use by the EDA community,
    and this would be consistent with svdpi.h as well.
7b. The routines vpi_load_extension(), vpi_close(),
    vpi_create(), vpi_goto() all have a formal argument
    declared with type "vpiType".  However, vpiType is
    a simple integer constant (vpi_user.h, line 236):
     #define vpiType              1   /* type of object */
    A proper type should be used in these prototypes rather
    than vpiType.  I noticed that the same problem exists
    in various places in Section 30 of the 3.1a LRM.
    I don't know what kind of type to suggest.