Bassam, others,
The problem is that it's not possible for an implementation to detect
that a warning is needed. The same reasoning applies to using "DPI"
for the deprecated way as was applied to using "DPI" for the new way.
The tool can only infer user intent by analyzing the SV source code.
SystemVerilog tools do not look at the C source code to determine
what style of API is used on the other side.
Thus, it is quite likely that whichever way we choose to have the
old "DPI" work, some users will get it wrong, and the tools will
not be able to detect this, and users will experience silent and
serious errors.
I believe that this is a major motivation for moving from
"DPI" to "DPI-3.1a" and "DPI-C".
I agree with Ralph's, Francoise's, and Steven J. Dovich's points, too.
Regards,
Doug
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> Behalf Of Bassam Tabbara
> Sent: Tuesday, December 21, 2004 4:20 PM
> To: 'Steven J. Dovich'; 'Francoise Martinolle'
> Cc: 'SV-CC'
> Subject: RE: [sv-cc] item 50 again
>
> Well the alternative does not necessarily have to be
> "silent", that's what
> warning/info messages are for. Both takes have their
> well-framed reasoning I
> think ... It is not necessary to break users' code (from day
> 1) to inform
> them of deprecation. It wouldn't be "deprecation" if you do,
> now would it ?
>
> Thx.
> -Bassam.
>
> --
> Dr. Bassam Tabbara
> Architect, R&D
> Novas Software, Inc.
> (408) 467-7893
>
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> Behalf Of Steven
> J. Dovich
> Sent: Tuesday, December 21, 2004 2:54 PM
> To: Francoise Martinolle
> Cc: 'SV-CC'
> Subject: Re: [sv-cc] item 50 again
>
> Another implication of this particular change is that the
> users must take an
> action which acknowledges the deprecated nature of the API.
> The alternative is for this change in status to be "silent"
> which leads to
> future problems.
>
> Also note that because "DPI" is no longer specified by the
> standard, it is
> available for vendor-specific extension which allows those who are
> supporting an existing customer base to do so without disruption.
> The use of "DPI" would not be portable to other
> implementations without the
> above mentioned acknowledgement of the deprecation.
>
> /sjd
>
>
>
> > 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--
> > >
> >
> >
> >
>
> /sjd
>
>
>
Received on Tue Dec 21 16:59:42 2004
This archive was generated by hypermail 2.1.8 : Tue Dec 21 2004 - 16:59:51 PST