To Doug's point about using "1800-2009" just in case we introducing some changes after the actual release, it doesn't appear that we currently have any volunteers in the Working Group really interested in making any changes to DPI. I'm not aware of any of them on the SV-CC, for example, although Michael at least has an ongoing interest. The main reason for having the DPI version string in the first place is to allow for incompatible behaviors with the same simulator. Given our past history, I'd guess that we're unlikely to make changes in the 2009 version of the standard that will be incompatible with existing behavior. I.e., we might make additions, but we'd want existing applications to keep running without changes and preferably without even requiring recompilation. When we do introduce incompatible behavior, we should then reconsider changing the version string. Regards, Jim Vellenga --------------------------------------------------------- James H. Vellenga 978-262-6381 Software Architect (FAX) 978-262-6636 Cadence Design Systems, Inc. vellenga@cadence.com 270 Billerica Rd Chelmsford, MA 01824-4179 "We all work with partial information." ---------------------------------------------------------- ________________________________ From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Francoise Martinolle Sent: Monday, August 25, 2008 3:39 PM To: SV-CC Subject: [sv-cc] DPI version I asked a few people their opinion on whether or not to change the DPI version to P1800-2009. Currently it is said: I.10.1.3 Implementation-dependent representation The svDpiVersion() function returns a string indicating which DPI standard is supported by the simulator and in particular which canonical value representation is being provided. For example, a tool that is based on IEEE Std 1800-2005, i.e., the VPI-based canonical value, shall return the string "1800-2005". Simulators implementing to the prior Accellera SV3.1a standards, and thus using the svLogicVec32 value representation, shall return the string "SV3.1a". /* Returns either version string "1800-2005" or "SV3.1a" */ const char* svDpiVersion(); IPersonally I think we should either leave this unchanged or say it return sv3.1a or a string 1800-xxxx where the xxxx number should be any of the standard versions. I append below the email exchange with Ralph and Doug: Doug warmke: I'm OK with either solution. There are a couple advantages to moving to "p1800-2009": 1. In case any errata or late changes do introduce changes, "p1800-2009" will already be in place to help catch them. 2. It is not very "neat and tidy" to have a "p1800-2005" string come out of a 2009-compliant simulator. But this isn't a very big deal either way. Whatever the decision is should be documented in the LRM. Thanks for asking, Doug > -----Original Message----- > From: Francoise Martinolle [mailto:fm@cadence.com <mailto:fm@cadence.com> ] > Sent: Wednesday, July 30, 2008 10:02 AM > To: RDuncan@CloudShield.com; Amit Kohli; Warmke, Doug > Cc: Charlie Dawson > Subject: DPI version string > > Ralph, Doug, Amit, > Since you are the DPI experts, we would like to know you opinion on > this matter. > If the current DPI version has incompatibilities with the p1800-2005 > or is substabtially different from p1800-2005, I guess it would be > worth adding a new version string of p1800-2009 otherwise I would > advise to leave its specification untouched. > > Francoise > ' > Here is an email exchange between Ralph and I. > > > The original intent, of course, was to signal whether an > implementation supported the canonical interface or not. For that > purpose, user code only needs to recognize whether "sv31a" is returned or not. > > There appear to be 3 basic choices -- specify that an implementation > of > svDpiVersion() returns: > > a. "sv31a" for non-canonical or anything else to indicate the > canonical conventions are supported. > b. "sv31a" or whatever is the most recent version of the Spec. > (e.g., "P1800-2008"). > c. "sv31a" or various strings corresponding to Spec. versions that > exist (allow "P1800-2005," "P1800-2008"). > > Choices 'b' and 'c' apparently lead to perpetual revisions. These may > only make sense if the function's return value is used to provide more > information than just the original pre-canonical/canonical distinction. > > Ralph Duncan > CloudShield Technologies > > > -----Original Message----- > *From:* owner-sv-cc@server.eda.org > [mailto:owner-sv-cc@server.eda.org]*On <mailto:owner-sv-cc@server.eda.org]*On> Behalf Of *Francoise > Martinolle > *Sent:* Monday, June 23, 2008 9:44 AM > *To:* SV-CC > *Cc:* Maidment, Matthew R > *Subject:* [sv-cc] mantis item 2099 > > Charles, > mantis item 2099 has a list of review comments, one of which ia > review item for the DPI section: > > I.9.1.3: should this be changed to "P1800-2008"? > > There is a function in DPI which returns the version number.: > P1800-2005 or sv31a > > ------------------------------------- > > > The svDpiVersion() function returns a string indicating which DPI > standard is supported by the simulator > > and in particular which canonical value representation is being > provided. For example, a tool that is based on > > IEEE Std 1800-2005, i.e., the VPI-based canonical value, shall > return the string "1800-2005". Simulators > > implementing to the prior Accellera SV3.1a standards, and thus > using > the svLogicVec32 value representation, > > shall return the string "SV3.1a". > > /* Returns either version string "1800-2005" or "SV3.1a" */ > > const char* svDpiVersion(); > > ----------------------------------------------------- > > > > Do we need to change the version returned from P1800-2005 to > P1800-2009, or add a new version P1800-2009? > > > > If the answer is " no change required, please add a bug note for > mantis 2099, otherwise please file a new mantis item > > and mark it as a child of 2099 to reserve the version #. > > > > Francoise > > > Dou -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Aug 26 05:33:18 2008
This archive was generated by hypermail 2.1.8 : Tue Aug 26 2008 - 05:33:23 PDT