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? PerReceived 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