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

Bassam, for #5, while parameter names are optional
in a function prototype, the other function prototypes
that I've looked at all have them, so we should be
consistent.

So perhaps something like

  PLI_INT32 vpi_get_assertion_info (
     vpiHandle assertion, /* handle to assertion */
     p_vpi_assertion_info info /* assertion related information */
     );

would be better.

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 Bassam Tabbara
] Sent: Monday, January 17, 2005 2:21 PM
] To: 'Warmke, Doug'; sv-cc@eda.org; stuart@sutherland-hdl.com
] Subject: 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.
]
]
]
]
]
]
]
Received on Mon Jan 17 12:15:52 2005