Hello Stuart,
I'm not sure if you saw my most recent mail on this topic.
I believe it presents a strong case for breaking backward compatability.
In the committee meeting in which we discussed and approved the amended
item 50 (you were present, the roll call shows), it was originally
proposed that "DPI" would be used for the new style arg passing,
and "DPI-SV3.1a" would be used for the old style passing.
It was argued that implementations supporting old style passing
couldn't detect an incorrect use of "DPI", since they don't analyze
the C code to check for matching use of API. That was a good
argument, and we realized we couldn't use "DPI" for new style
arg passing.
The same argument applies to implementations that support new style
arg passing. If a user uses the new style, and forgets to change
their "DPI" to "DPI-C" in the SV source, this error is not something
a tool can check for. The simulation will silently fail, which
is the worst-case scenario.
The only good solution is to completely eliminate "DPI".
This forces users into ackknowledging the issue, and making
a conscientious choice about which style of arg passing
they want to go with.
Regarding your arguments for not using "3.1a", I believe
that "3.1a" is the best choice I have heard to date.
Exactly because it does point folks at the origins of that
argument passing scheme. If vendors want to implement the
deprecated feature in order to compete with other vendors,
isn't it doing them a favor to point them at all possible
information regarding that feature? Doing otherwise would
only put them at a disadvantage, while trying to maintain
the appearance that we are not doing so. I have copies of
the 3.1a LRM which I would be happy to forward to anyone who
is interested at some future date. It won't be hard to find.
I like names that convey maximum information, which I believe
this name does.
If you still disagree, do you have any other suggestions besides
plain "DPI"? We couldn't think of anything better in committee
discussions last week.
Thanks and regards,
Doug
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> Behalf Of Stuart Sutherland
> Sent: Tuesday, December 21, 2004 6:24 PM
> To: 'SV-CC'
> Subject: RE: [sv-cc] item 50 again
>
> Let me clarify the two concerns regarding the string
> "DPI-31a" that I raised
> in the champions meeting today:
>
> First and foremost is backward compatibility with the existing SV 3.1a
> standard, existing implementations, and the few existing DPI
> applications
> that may be out there. The specific concern I raised was not
> that I oppose
> a change that is not backward compatible, but that a change
> that is not
> backward compatible needs to be justified at the P1800
> working group meeting
> where final approval is given. Without justification, there
> is a strong
> likelihood that the proposal would not pass at the working
> group level (most
> of whom were not privy to the working group discussion regarding the
> decision).
>
> >From the e-mails today, it sounds like the CC committee has
> a good reason
> for not being backward compatible (I assumed there was).
> This reason just
> needs to be documented in the data base. I should add,
> however, that my
> personal feeling is that the reasons I've seen in these
> e-mails are not
> sufficiently strong enough to convince me that breaking backward
> compatibility is the right thing to do.
>
> My second concern is that I am uncomfortable with codifying "3.1a", or
> variants thereof, in the P1800 standard. Right, now, we all
> know what 3.1a
> implies. A few years from now, few will know the meaning.
> Worse, the use
> of 3.1a may cause future tool developers to feel that they
> need to find the
> obsolete 3.1a LRM in order to compete with products that are
> supporting
> deprecated features.
>
> Both concerns, and any risk that the P1800 working group
> might insist on
> backward compatibility in this case, could be addressed by
> having the P1800
> standard support the "DPI" string as it was in 3.1a, but with
> a mandatory
> warning that it is a deprecated feature that may not be
> supported in future
> versions of the standard. Unlike the Accellera SV 3.1a
> document, every
> version of the 1800 standard will remain available in the
> IEEE archives.
> Therefore, a future 1800 standard can remove "DPI" and future
> implementers
> can still access its original meaning.
>
> I will try to make the conference call Wednesday morning. I
> have some other
> commitments that morning, but should be able to work around them.
>
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898
>
>
> > -----Original Message-----
> > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> > Behalf Of Francoise Martinolle
> > Sent: Tuesday, December 21, 2004 2:13 PM
> > To: 'SV-CC'
> > Subject: RE: [sv-cc] item 50 again
> >
> >
> > During the champions meeting today, I indicated to Stuart the
> > reasons we had for changing from "DPI" to "DPI-31a" for using
> > the deprecated interface and "DPI-C" for using th standard
> > canonical C interface.
> > I try to summarize below what were these reasons :
> > - the user should know that he is using a deprecated
> > interface and choose
> > to do so by being required to make a minor change in the
> > Verilog code
> > for the dpi string.
> > Otherwise keeping the "DPI" string legal may encourage
> > users to use a deprecated
> > interface.
> > - we did want to be very specific about which DPI was to be
> > used, hence the string "DPI-C" for the C canonical interface
> > and "DPI-31a" for the 3.1a version of the interface. This
> > leads to future extensions such as DPI-C++ etc...
> >
> > francoise
> > '
> >
> > -----Original Message-----
> > From: Andrzej I. Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> > Sent: Tuesday, December 21, 2004 1:44 PM
> > To: fm (Francoise Martinolle)
> > Cc: 'SV-CC'
> > Subject: Re: [sv-cc] item 50 again
> >
> > > We need to discuss again item 50 with regard to the
> > dpi_string_specifier.
> > > Stuart brought up the fact that the "DPI" string is not
> > legal as per
> > > item 50, this will create incompatibility with previous
> legal sv31a
> > > code. He is asking for a rational for why this is not now
> legal and
> > > why the string DPI-sv31a is replacing DPI string.
> >
> > Thank you, Stuart! This is the very same issue that I had
> > raised before.
> > My arguments got ignored and I lost yet another battle for
> > the legacy DPI.
> > Oh, well. I won't be able to attend the meeting tomorrow.
> > I wish everybody a Merry Christmas (or other holidays) and
> > happy New Year!
> >
> >
> > Regards,
> > Andrzej
> >
> >
> > > Stuart is planning to attend the meeting tomorrow.
> > >
> > > Francoise
> > > '
> > >
> > >
> > >
> > > ------=_NextPart_000_001C_01C4E760.A7EA3FC0
> > > Content-Type: text/html;
> > > charset="us-ascii"
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> > > <HTML><HEAD> <META http-equiv=3DContent-Type
> > content=3D"text/html; =
> > > charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2800.1479"
> > > name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial
> > size=3D2><SPAN
> > > class=3D936281718-21122004>We = need to discuss=20 again
> > item 50 with
> > > regard to the = dpi_string_specifier.</SPAN></FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2><SPAN
> > > class=3D936281718-21122004>Stuart = brought up=20 the
> fact that the
> > > "DPI" string is not legal as per item 50, this will=20
> > > create</SPAN></FONT></DIV> <DIV><FONT face=3DArial
> size=3D2><SPAN =
> > > class=3D936281718-21122004>incompatibility with=20 previous legal
> > > sv31a code. He is asking for a rational for why=20
> > > this</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN
> > > class=3D936281718-21122004>is not = now legal and=20 why
> the string
> > > DPI-sv31a is replacing DPI string.</SPAN></FONT></DIV> <DIV><FONT
> > > face=3DArial size=3D2><SPAN=20
> > > class=3D936281718-21122004></SPAN></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2><SPAN
> > > class=3D936281718-21122004>Stuart = is planning=20 to attend the
> > > meeting tomorrow.</SPAN></FONT></DIV> <DIV><FONT face=3DArial
> > > size=3D2><SPAN=20
> > > class=3D936281718-21122004></SPAN></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2><SPAN=20
> > > class=3D936281718-21122004>Francoise</SPAN></FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2><SPAN=20
> > > class=3D936281718-21122004> =20
> > > '</SPAN></FONT></DIV>
> > > <DIV><FONT face=3DArial size=3D2><SPAN=20
> > > class=3D936281718-21122004></SPAN></FONT> </DIV>
> > > <DIV><FONT face=3DArial size=3D2><SPAN=20
> > >
> class=3D936281718-21122004></SPAN></FONT> </DIV></BODY></HTML>
> > >
> > > ------=_NextPart_000_001C_01C4E760.A7EA3FC0--
> > >
> >
> >
> >
> >
>
>
>
Received on Tue Dec 21 18:51:46 2004
This archive was generated by hypermail 2.1.8 : Tue Dec 21 2004 - 18:51:50 PST