DPI API functions we need in SCE-MI 2.0

From: Per Bojsen <bojsen_at_.....>
Date: Thu Mar 16 2006 - 21:43:56 PST
Hi,

we talked briefly at the meeting today (3/16/06) about the DPI
API functions that we need to support in SCE-MI 2.0.  Of course,
this is only an issue when implementing SCE-MI 2.0 for a platform
that is not a SystemVerilog simulator.  In the following I am
assuming the target is not such a simulator.

I took a look at the IEEE 1800-2005 standard and extracted the
following lists.  The first list is the scope related functions
that I think we definitely should support:

  svScope svGetScope(void)
  svScope svSetScope(const svScope scope)
  int svPutUserData(const svScope scope, void *userKey, void *userData)
  void *svGetUserData(const svScope scope, void *userKey)

Jason's proposal for enhancing the pipe API also requires the
following:

  const char *svGetNameFromScope(const svScope scope)
  svScope svGetScopeFromName(const char *scopeName)

This one is debatable, although one could create support trivially
by always returning FALSE.  This may sound silly but it would
allow applications that uses this to at least compile and run:

  int svGetCallerInfo(char **fileName, int *lineNumber)

I think we need this function as well since application code
might be calling it (it is trivial to implement):

  const char *svDpiVersion(void)

The question is what do we return?

John was mentioning the DPI API functions that enable bit manipulation
of svBitVecVal arrays.  We definitely need those.  They are:

  svBit svGetBitselBit(const svBitVecVal *s, int i)
  void svPutBitselBit(svBitVecVal *d, int i, svBit s)
  void svGetPartselBit(svBitVecVal *d, const svBitVecVal *s, int i, int
w)
  void svPutPartselBit(svBitVecVal *d, const svBitVecVal s, int i, int
w)

Note, these support accessing individual bits of an svBitVecVal array
as well as bit fields (part selects) up to 32 bits wide.

BTW, the number of sv API functions seems to be in the 70 range.
That is quite a lot of functions for an API-less interface :-)

We also need some type definitions:

  svScope
  svBit
  svBitVecVal

1800-2005 states on p. 590 that all simulators shall use the same
svdpi.h file.  Should we specify a subset of this file that all
SCE-MI 2.0 implementations must use?  It does not quite make sense
to use the svdpi.h from 1800-2005 since there are features we do
not support such as svLogic, svLogicVecVal, and open arrays.  It
would not harm to have those definitions in the include file but
it would be potentially misleading to users.  We are not implementing
DPI anyway, only a SCE-MI 2.0 compatible subset.

Having said that, I think we also need the sv_0 and sv_1 #defines.
Again, they could occur in application code and they are trivial
to support.  Then there are the SV_PACKED_DATA_NELEMS(), SV_MASK(),
SV_GET_UNSIGNED_BITS(), and SV_GET_SIGNED_BITS() macros.  I think
these are required as well for the same reasons.

Brian, can we open a new IM for this topic?

Per
Received on Thu Mar 16 21:44:02 2006

This archive was generated by hypermail 2.1.8 : Thu Mar 16 2006 - 21:44:08 PST