Hi John, First thanks for addressing my feedback and in particular the "autoflush Christmas present". I am pretty sure that also our users will appreciate this reduced in verbosity in the term. John, Per, Jason indicated that both of you raised some reservations (in the last meeting during my absence) wrt to my proposed naming conventions in section 5.6.6 of the new body (I suppose Context and non-context DPI Utility Functions) with the argument that these terms have not been defined in the SV LRM. I am open to changing that, but now in the "context of our convergence process", please propose the wording changes that you would like to see in this paragraph (as I did when reviewing John's documents). Here is the relevant section you want modified (ignoring the index). 1.1.1 DPI utility function supported by SCE-MI 2 [Per's email; missing IM] DPI defines a small set of functions to help programmers work with DPI context tasks and functions. The term scope is used in the task or function names for consistency with other SystemVerilog terminology. The terms scope and context are equivalent for DPI tasks and functions. There are functions that allow the user to retrieve and manipulate the current operational scope. There are also functions to associate an opaque user data pointer with an HDL scope. This pointer can then later be retrieved when an imported DPI function is called from that scope. SCE-MI 2 supports two types of DPI Utility functions, those that must be invoked from a context imported functions (to be called Context DPI Utility Functions) and those whose invocation is unrestricted (to be called non-Context DPI Utility Functions). The Context DPI Utility functions are: svScope svGetScope(void) svScope svSetScope(const svScope scope) int svPutUserData(const svScope scope, void *userKey, void *userData) void *svGetUserData(const svScope scope, void *userKey) const char *svGetNameFromScope(const svScope scope) svScope svGetScopeFromName(const char *scopeName) The non-Context DPI Utility functions are: int svGetCallerInfo(char **fileName, int *lineNumber) const char *svDpiVersion(void) 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) How would like to change this? Shabtay >-----Original Message----- >From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of John >Stickley >Sent: Tuesday, November 28, 2006 4:19 PM >To: 'itc@eda.org' >Subject: SCE-MI 2 pipes section - revision 1.20 > >Greetings ITC Techies, > >I have incorporated feedback from Shabtay's document, > > Chapter_5_Formal_Pipes_061012_cdn3.doc > >Here is a summary of the changes: > >- Did not change font to informative in section 4.1 since this > was an overview already. > >- A Christmas present for Shabtay - changed all instances of > "automatic flush-on-eom" to "autoflush". :-) > >- Added new wording requested by Shabtay describing behavior of > non-blocking send operations on pipes enabled for autoflush. > >- Rewording of 1st paragraph of seciton 4.4. > >All changes since revision 1.19 are indicated with change bars. >I've also updated the TOC. > >I'll send the document itself separately for Brian to post on the >web. > >-- johnS > >This email may contain material that is confidential, privileged >and/or attorney work product for the sole use of the intended >recipient. Any review, reliance or distribution by others or >forwarding without express permission /\ >is strictly prohibited. If you are /\ | \ >not the intended recipient please | \ / | >contact the sender and delete / \ \ >all copies. /\_/ K2 \_ \_ >______________________________/\/ \ \ >John Stickley \ \ \ >Mgr., Acceleration Methodologies \ \________________ >Mentor Graphics - MED \_ >17 E. Cedar Place \ john_stickley@mentor.com >Ramsey, NJ 07446 \ Phone: (201) 818-2585 >________________________________________________________________Received on Wed Dec 13 13:24:08 2006
This archive was generated by hypermail 2.1.8 : Wed Dec 13 2006 - 13:24:16 PST