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

Actually, vpiMember is not defined in vpi_user.h, but it
is defined twice in sv_vpi_user.h.

Regards,
Jim V.

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
  
 

] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] Behalf Of Warmke, Doug
] Sent: Friday, January 14, 2005 9: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.
]
]
]
]
]
]
Received on Mon Jan 17 12:29:05 2005