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