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

Stu,

It looks like I was using a IEEE 1364-2001 compliant
version of vpi_user.h, rather than the "new" vpi_user.h.

Do you (or anyone else out there) happen to have a copy
of the latest and greatest vpi_user.h that I should be
testing with?

Thanks,
Doug

> -----Original Message-----
> From: Jim Vellenga [mailto:vellenga@cadence.com]
> Sent: Monday, January 17, 2005 12:43 PM
> To: bassam@novas.com; Warmke, Doug; sv-cc@eda.org;
> stuart@sutherland-hdl.com
> Subject: RE: [sv-cc] Fixes needed for sv_dpi_user.h
>
> (1) The vpiMembers comes from 31.22, and probably should
> have been vpiMember. There's no reason for it not to be.
>
> (2) The second instance of vpiMember comes from the
> read API. Now that I've had my nose rubbed in it, I
> see that the read API has problems that we've already
> addressed in other areas:
>
> (a) It defines numbers for various vpi constants that
> are redundant to those defined in sv_vpi_user.h. That
> includes, of course, vpiMember.
>
> (b) It references deprecated object types "reg array"
> and "net array".
>
> I suppose it's too late to do anything about most of
> those, although I presume we can take out the redundant
> definition of vpiMember from 30.3.2.1.
>
> 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: Bassam Tabbara [mailto:bassam@novas.com]
> ] Sent: Monday, January 17, 2005 3:36 PM
> ] To: Jim Vellenga; 'Warmke, Doug'; sv-cc@eda.org;
> ] stuart@sutherland-hdl.com
> ] Subject: RE: [sv-cc] Fixes needed for sv_dpi_user.h
> ]
> ] Yep, thx Jim for the input. vpiMember (first one) is coming
> ] from var is a
> ] member of a parent struct or union (31.10) I think. So that
> ] explains that.
> ] It can be reused of course, just strike the second as Doug suggests.
> ]
> ] ** What bugs me now is the vpiMembers ... Where did that come
> ] from ? A quick
> ] search of LRM does not give me an immediate clue ...
> ]
> ] 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 Jim
> ] Vellenga
> ] Sent: Monday, January 17, 2005 12:29 PM
> ] To: Warmke, Doug; sv-cc@eda.org; stuart@sutherland-hdl.com
> ] Subject: 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 16:50:11 2005