[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.

 
Received on Fri Jan 14 18:19:59 2005