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 12:43:37 2005