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>&nbsp;</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>&nbsp;</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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> > '</SPAN></FONT></DIV>
> > <DIV><FONT face=3DArial size=3D2><SPAN=20
> > class=3D936281718-21122004></SPAN></FONT>&nbsp;</DIV>
> > <DIV><FONT face=3DArial size=3D2><SPAN=20
> > class=3D936281718-21122004></SPAN></FONT>&nbsp;</DIV></BODY></HTML>
> >
> > ------=_NextPart_000_001C_01C4E760.A7EA3FC0--
> >
>
>
>
>
Received on Tue Dec 21 18:24:21 2004