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

Indeed, you're right, to be consistent with the rest in sv_vpi_user.h, thx
Jim.

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

-Bassam.

--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
-----Original Message-----
From: Jim Vellenga [mailto:vellenga@cadence.com] 
Sent: Monday, January 17, 2005 12:16 PM
To: bassam@novas.com
Cc: SV-CC
Subject: 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.
] 
] 
]  
] 
] 
] 
]